[{"data":1,"prerenderedAt":4943},["ShallowReactive",2],{"/en-us/blog/categories/insights/":3,"navigation-en-us":22,"banner-en-us":434,"footer-en-us":447,"insights-category-page-en-us":659},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":16,"_type":17,"title":9,"_source":18,"_file":19,"_stem":20,"_extension":21},"/en-us/blog/categories/insights","categories",false,"",{"title":9,"description":10},"Insights","Browse articles related to Insights on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":15},"BlogCategory","insights",true,"content:en-us:blog:categories:insights.yml","yaml","content","en-us/blog/categories/insights.yml","en-us/blog/categories/insights","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":430,"_type":17,"title":431,"_source":18,"_file":432,"_stem":433,"_extension":21},"/shared/en-us/main-navigation","en-us",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":376,"minimal":407,"duo":421},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/","gitlab logo","header",{"text":32,"config":33},"Get free trial",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Talk to sales",{"href":39,"dataGaName":40,"dataGaLocation":30},"/sales/","sales",{"text":42,"config":43},"Sign in",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,186,191,297,357],{"text":48,"config":49,"cards":51,"footer":74},"Platform",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"The most comprehensive AI-powered DevSecOps Platform",{"text":55,"config":56},"Explore our Platform",{"href":57,"dataGaName":50,"dataGaLocation":30},"/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":62,"config":63},"Meet GitLab Duo",{"href":64,"dataGaName":65,"dataGaLocation":30},"/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":70,"config":71},"Learn more",{"href":72,"dataGaName":73,"dataGaLocation":30},"/why-gitlab/","why gitlab",{"title":75,"items":76},"Get started with",[77,82,87],{"text":78,"config":79},"Platform Engineering",{"href":80,"dataGaName":81,"dataGaLocation":30},"/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Developer Experience",{"href":85,"dataGaName":86,"dataGaLocation":30},"/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":15,"config":93,"link":95,"lists":99,"footer":168},"Product",{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"View all Solutions",{"href":98,"dataGaName":94,"dataGaLocation":30},"/solutions/",[100,125,147],{"title":101,"description":102,"link":103,"items":108},"Automation","CI/CD and automation to accelerate deployment",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":30},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[109,113,117,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":30,"dataGaName":110},"/solutions/continuous-integration/",{"text":114,"config":115},"AI-Assisted Development",{"href":64,"dataGaLocation":30,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Source Code Management",{"href":120,"dataGaLocation":30,"dataGaName":118},"/solutions/source-code-management/",{"text":122,"config":123},"Automated Software Delivery",{"href":106,"dataGaLocation":30,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Security","Deliver code faster without compromising security",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":30,"icon":132},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,137,142],{"text":135,"config":136},"Security & Compliance",{"href":130,"dataGaLocation":30,"dataGaName":135},{"text":138,"config":139},"Software Supply Chain Security",{"href":140,"dataGaLocation":30,"dataGaName":141},"/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Compliance & Governance",{"href":145,"dataGaLocation":30,"dataGaName":146},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":148,"link":149,"items":154},"Measurement",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":30},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[155,159,163],{"text":156,"config":157},"Visibility & Measurement",{"href":152,"dataGaLocation":30,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Value Stream Management",{"href":162,"dataGaLocation":30,"dataGaName":160},"/solutions/value-stream-management/",{"text":164,"config":165},"Analytics & Insights",{"href":166,"dataGaLocation":30,"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":30,"dataGaName":175},"/enterprise/","enterprise",{"text":177,"config":178},"Small Business",{"href":179,"dataGaLocation":30,"dataGaName":180},"/small-business/","small business",{"text":182,"config":183},"Public Sector",{"href":184,"dataGaLocation":30,"dataGaName":185},"/solutions/public-sector/","public sector",{"text":187,"config":188},"Pricing",{"href":189,"dataGaName":190,"dataGaLocation":30,"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":30},"/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":30},"/install/","install",{"text":209,"config":210},"Quick start guides",{"href":211,"dataGaName":212,"dataGaLocation":30},"/get-started/","quick setup checklists",{"text":214,"config":215},"Learn",{"href":216,"dataGaLocation":30,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Product documentation",{"href":221,"dataGaName":222,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best practice videos",{"href":226,"dataGaName":227,"dataGaLocation":30},"/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrations",{"href":231,"dataGaName":232,"dataGaLocation":30},"/integrations/","integrations",{"title":234,"items":235},"Discover",[236,241,246,251],{"text":237,"config":238},"Customer success stories",{"href":239,"dataGaName":240,"dataGaLocation":30},"/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":30},"/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":252,"config":253},"TeamOps",{"href":254,"dataGaName":255,"dataGaLocation":30},"/teamops/","teamops",{"title":257,"items":258},"Connect",[259,264,269,274,279],{"text":260,"config":261},"GitLab Services",{"href":262,"dataGaName":263,"dataGaLocation":30},"/services/","services",{"text":265,"config":266},"Community",{"href":267,"dataGaName":268,"dataGaLocation":30},"/community/","community",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Events",{"href":277,"dataGaName":278,"dataGaLocation":30},"/events/","events",{"text":280,"config":281},"Partners",{"href":282,"dataGaName":283,"dataGaLocation":30},"/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},"/images/navigation/the-source-promo-card.svg",{"text":293,"config":294},"Read the latest",{"href":295,"dataGaName":296,"dataGaLocation":30},"/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":30},"/company/","about",{"text":310,"config":311,"footerGa":314},"Jobs",{"href":312,"dataGaName":313,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":313},{"text":275,"config":316},{"href":277,"dataGaName":278,"dataGaLocation":30},{"text":318,"config":319},"Leadership",{"href":320,"dataGaName":321,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":323,"config":324},"Team",{"href":325,"dataGaName":326,"dataGaLocation":30},"/company/team/","team",{"text":328,"config":329},"Handbook",{"href":330,"dataGaName":331,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":333,"config":334},"Investor relations",{"href":335,"dataGaName":336,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":338,"config":339},"Trust Center",{"href":340,"dataGaName":341,"dataGaLocation":30},"/security/","trust center",{"text":343,"config":344},"AI Transparency Center",{"href":345,"dataGaName":346,"dataGaLocation":30},"/ai-transparency-center/","ai transparency center",{"text":348,"config":349},"Newsletter",{"href":350,"dataGaName":351,"dataGaLocation":30},"/company/contact/","newsletter",{"text":353,"config":354},"Press",{"href":355,"dataGaName":356,"dataGaLocation":30},"/press/","press",{"text":358,"config":359,"lists":360},"Contact us",{"dataNavLevelOne":300},[361],{"items":362},[363,366,371],{"text":37,"config":364},{"href":39,"dataGaName":365,"dataGaLocation":30},"talk to sales",{"text":367,"config":368},"Get help",{"href":369,"dataGaName":370,"dataGaLocation":30},"/support/","get help",{"text":372,"config":373},"Customer portal",{"href":374,"dataGaName":375,"dataGaLocation":30},"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":44,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"Suggestions",[388,390,394,396,400,404],{"text":59,"config":389},{"href":64,"dataGaName":59,"dataGaLocation":384},{"text":391,"config":392},"Code Suggestions (AI)",{"href":393,"dataGaName":391,"dataGaLocation":384},"/solutions/code-suggestions/",{"text":110,"config":395},{"href":112,"dataGaName":110,"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":72,"dataGaName":405,"dataGaLocation":384},{"freeTrial":408,"mobileIcon":413,"desktopIcon":418},{"text":409,"config":410},"Start free trial",{"href":411,"dataGaName":35,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"Gitlab Icon",{"src":416,"dataGaName":417,"dataGaLocation":412},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"/images/brand/gitlab-logo-type.svg",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"Learn more about GitLab Duo",{"href":64,"dataGaName":425,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":427},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":429},{"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":435,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":436,"titleMobile":436,"button":437,"config":442,"_id":444,"_type":17,"_source":18,"_file":445,"_stem":446,"_extension":21},"/shared/en-us/banner","GitLab 18 & the next step in intelligent DevSecOps.",{"text":438,"config":439},"Watch now",{"href":440,"dataGaName":441,"dataGaLocation":30},"/eighteen/","gitlab 18 banner",{"layout":443},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":448,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":449,"_id":655,"_type":17,"title":656,"_source":18,"_file":657,"_stem":658,"_extension":21},"/shared/en-us/main-footer",{"text":450,"source":451,"edit":457,"contribute":462,"config":467,"items":472,"minimal":647},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":452,"config":453},"View page source",{"href":454,"dataGaName":455,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":458,"config":459},"Edit this page",{"href":460,"dataGaName":461,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":463,"config":464},"Please contribute",{"href":465,"dataGaName":466,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":468,"facebook":469,"youtube":470,"linkedin":471},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[473,496,553,582,617],{"title":48,"links":474,"subMenu":479},[475],{"text":476,"config":477},"DevSecOps platform",{"href":57,"dataGaName":478,"dataGaLocation":456},"devsecops platform",[480],{"title":187,"links":481},[482,486,491],{"text":483,"config":484},"View plans",{"href":189,"dataGaName":485,"dataGaLocation":456},"view plans",{"text":487,"config":488},"Why Premium?",{"href":489,"dataGaName":490,"dataGaLocation":456},"/pricing/premium/","why premium",{"text":492,"config":493},"Why Ultimate?",{"href":494,"dataGaName":495,"dataGaLocation":456},"/pricing/ultimate/","why ultimate",{"title":497,"links":498},"Solutions",[499,504,507,509,514,519,523,526,530,535,537,540,543,548],{"text":500,"config":501},"Digital transformation",{"href":502,"dataGaName":503,"dataGaLocation":456},"/solutions/digital-transformation/","digital transformation",{"text":135,"config":505},{"href":130,"dataGaName":506,"dataGaLocation":456},"security & compliance",{"text":124,"config":508},{"href":106,"dataGaName":107,"dataGaLocation":456},{"text":510,"config":511},"Agile development",{"href":512,"dataGaName":513,"dataGaLocation":456},"/solutions/agile-delivery/","agile delivery",{"text":515,"config":516},"Cloud transformation",{"href":517,"dataGaName":518,"dataGaLocation":456},"/solutions/cloud-native/","cloud transformation",{"text":520,"config":521},"SCM",{"href":120,"dataGaName":522,"dataGaLocation":456},"source code management",{"text":110,"config":524},{"href":112,"dataGaName":525,"dataGaLocation":456},"continuous integration & delivery",{"text":527,"config":528},"Value stream management",{"href":162,"dataGaName":529,"dataGaLocation":456},"value stream management",{"text":531,"config":532},"GitOps",{"href":533,"dataGaName":534,"dataGaLocation":456},"/solutions/gitops/","gitops",{"text":172,"config":536},{"href":174,"dataGaName":175,"dataGaLocation":456},{"text":538,"config":539},"Small business",{"href":179,"dataGaName":180,"dataGaLocation":456},{"text":541,"config":542},"Public sector",{"href":184,"dataGaName":185,"dataGaLocation":456},{"text":544,"config":545},"Education",{"href":546,"dataGaName":547,"dataGaLocation":456},"/solutions/education/","education",{"text":549,"config":550},"Financial services",{"href":551,"dataGaName":552,"dataGaLocation":456},"/solutions/finance/","financial services",{"title":192,"links":554},[555,557,559,561,564,566,568,570,572,574,576,578,580],{"text":204,"config":556},{"href":206,"dataGaName":207,"dataGaLocation":456},{"text":209,"config":558},{"href":211,"dataGaName":212,"dataGaLocation":456},{"text":214,"config":560},{"href":216,"dataGaName":217,"dataGaLocation":456},{"text":219,"config":562},{"href":221,"dataGaName":563,"dataGaLocation":456},"docs",{"text":242,"config":565},{"href":244,"dataGaName":245,"dataGaLocation":456},{"text":237,"config":567},{"href":239,"dataGaName":240,"dataGaLocation":456},{"text":247,"config":569},{"href":249,"dataGaName":250,"dataGaLocation":456},{"text":260,"config":571},{"href":262,"dataGaName":263,"dataGaLocation":456},{"text":252,"config":573},{"href":254,"dataGaName":255,"dataGaLocation":456},{"text":265,"config":575},{"href":267,"dataGaName":268,"dataGaLocation":456},{"text":270,"config":577},{"href":272,"dataGaName":273,"dataGaLocation":456},{"text":275,"config":579},{"href":277,"dataGaName":278,"dataGaLocation":456},{"text":280,"config":581},{"href":282,"dataGaName":283,"dataGaLocation":456},{"title":298,"links":583},[584,586,588,590,592,594,596,601,606,608,610,612],{"text":305,"config":585},{"href":307,"dataGaName":300,"dataGaLocation":456},{"text":310,"config":587},{"href":312,"dataGaName":313,"dataGaLocation":456},{"text":318,"config":589},{"href":320,"dataGaName":321,"dataGaLocation":456},{"text":323,"config":591},{"href":325,"dataGaName":326,"dataGaLocation":456},{"text":328,"config":593},{"href":330,"dataGaName":331,"dataGaLocation":456},{"text":333,"config":595},{"href":335,"dataGaName":336,"dataGaLocation":456},{"text":597,"config":598},"Environmental, social and governance (ESG)",{"href":599,"dataGaName":600,"dataGaLocation":456},"/environmental-social-governance/","environmental, social and governance",{"text":602,"config":603},"Diversity, inclusion and belonging (DIB)",{"href":604,"dataGaName":605,"dataGaLocation":456},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":338,"config":607},{"href":340,"dataGaName":341,"dataGaLocation":456},{"text":348,"config":609},{"href":350,"dataGaName":351,"dataGaLocation":456},{"text":353,"config":611},{"href":355,"dataGaName":356,"dataGaLocation":456},{"text":613,"config":614},"Modern Slavery Transparency Statement",{"href":615,"dataGaName":616,"dataGaLocation":456},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":618,"links":619},"Contact Us",[620,623,625,627,632,637,642],{"text":621,"config":622},"Contact an expert",{"href":39,"dataGaName":40,"dataGaLocation":456},{"text":367,"config":624},{"href":369,"dataGaName":370,"dataGaLocation":456},{"text":372,"config":626},{"href":374,"dataGaName":375,"dataGaLocation":456},{"text":628,"config":629},"Status",{"href":630,"dataGaName":631,"dataGaLocation":456},"https://status.gitlab.com/","status",{"text":633,"config":634},"Terms of use",{"href":635,"dataGaName":636,"dataGaLocation":456},"/terms/","terms of use",{"text":638,"config":639},"Privacy statement",{"href":640,"dataGaName":641,"dataGaLocation":456},"/privacy/","privacy statement",{"text":643,"config":644},"Cookie preferences",{"dataGaName":645,"dataGaLocation":456,"id":646,"isOneTrustButton":15},"cookie preferences","ot-sdk-btn",{"items":648},[649,651,653],{"text":633,"config":650},{"href":635,"dataGaName":636,"dataGaLocation":456},{"text":638,"config":652},{"href":640,"dataGaName":641,"dataGaLocation":456},{"text":643,"config":654},{"dataGaName":645,"dataGaLocation":456,"id":646,"isOneTrustButton":15},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"featuredPost":660,"allPosts":686,"totalPages":4941,"initialPosts":4942},{"_path":661,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":662,"content":670,"config":679,"_id":682,"_type":17,"title":683,"_source":18,"_file":684,"_stem":685,"_extension":21},"/en-us/blog/navigation-research-blog-post",{"title":663,"description":664,"ogTitle":663,"ogDescription":664,"noIndex":6,"ogImage":665,"ogUrl":666,"ogSiteName":667,"ogType":668,"canonicalUrls":666,"schema":669},"How we overhauled GitLab navigation","Users weren't getting what they needed from our navigation. Here are the steps we took to turn that experience around.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682884/Blog/Hero%20Images/navigation.jpg","https://about.gitlab.com/blog/navigation-research-blog-post","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we overhauled GitLab navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Knobloch\"}],\n        \"datePublished\": \"2023-08-15\",\n      }",{"title":663,"description":664,"authors":671,"heroImage":665,"date":673,"body":674,"category":14,"tags":675},[672],"Ashley Knobloch","2023-08-15","\nGitLab navigation was complex and confusing - that was the message we received from our users through issues and other feedback channels. Initially, to address these concerns, we conducted research around proposed solutions, but quickly found they wouldn't help users achieve their goals well enough to warrant implementing them. In the process of learning what wasn't working and what wouldn't work, we still didn't have clarity around *why* the navigation wasn't working. This article chronicles our journey to finding that clarity and developing navigation that is easier to use and better suited to our users' needs.\n\n## Our approach\nAs a first step, we reviewed past research and user feedback to ensure we had a solid understanding of what we had done and learned already. We found that we still needed more insight into why proposed changes weren’t receiving enough positive feedback to implement them.\n\nOur goals were straightforward:\n- understand what users are doing in GitLab\n- study how they navigate the platform\n- learn why they need certain navigation elements \n\nOur perspective shifted from validating proposed solutions to going back to revalidate the problems that exist with our navigation experience. Our hypothesis was that with a deeper understanding of our users’ behavior and mental models for how they navigate around GitLab, we could develop concepts to better match their needs and improve their overall experience.  \n\nThe scope of features in GitLab and the number of user personas across GitLab made this challenging. We have [16 personas](https://about.gitlab.com/handbook/product/personas/#user-personas) to represent different types of users, all with unique goals and techniques to achieve those goals. We focused our efforts on a subset of those personas that best represented usage across GitLab to ensure a holistic understanding of different user needs. We wanted to learn how navigation among different personas was similar and where it differed, what worked well with the current navigation, and what challenges users faced.\n\n## Studying key persona cohorts\nWe conducted [diary studies](https://about.gitlab.com/handbook/product/ux/ux-research/diary-studies/) with cohorts of our key personas to learn what their primary tasks and workflows were at a deeper level. This provided us with many real-world examples of how they navigate to their tasks and why. We also learned what worked well with their current workflows, what pain points existed, and what workarounds were being used (such as creating browser bookmarks, typing in the URL to pull browser history, or keeping a bunch of browser tabs open) to streamline their tasks in GitLab. \n\nWe learned that for some users, many of their primary tasks don’t require much navigation within GitLab because they use outside tools that link into GitLab through notifications (e.g., Slack and email) or use direct links through other tools. We also learned that often users’ work is quite scoped in GitLab, and they would like easier access to some of their core features without having to wade through all of the other features they don’t use. This illuminated some unmet needs that would improve their workflows, such as having the ability to customize navigation to access things important to them more quickly and streamline their path to relevant projects.\n\nLearning more about our users from a foundational perspective ensured that we had a solid base to build upon when considering changes to the navigation.\n\n## Anchoring to a North Star\nTo anchor the redesign process in user problems more broadly, a review of past feedback was analyzed that revealed three overarching themes with navigation-related feedback. These themes helped to guide the process and to remind us of the key problems we were trying to solve: \n- minimize feeling overwhelmed (ability to customize left sidebar)\n- orient users across the platform (differentiating groups and projects)\n- pick up where you left off (switching contexts)\n\nThe team continually mapped back design concepts to these themes to ensure potential solutions were rooted in user problems. \n\n## Evaluating and iterating\nNext, several navigation design concepts were developed and shared with users for feedback. Multiple rounds of [solution validation testing](https://about.gitlab.com/handbook/product/ux/ux-research/solution-validation-and-methods/) were conducted with our key personas to determine which design concepts to move forward with. The testing revealed how users felt about each design and also how well each design supported users completing core tasks. We identified a final concept that supported mature and new GitLab users with common workflows.\n\n## Understanding mental models for sidebar organization\nWe wanted to revisit our groupings in the left sidebar because we’ve heard over time that the organization can be confusing and unintuitive, especially some categories such as Operations. We needed to understand our users’ mental models for how they would group these items, and why. Learning the thought processes behind their organization was critical for us to know what changes to make that would align with user expectations. \n\nWe ran facilitated [card sort](https://about.gitlab.com/handbook/product/ux/ux-research/mental-modeling/#card-sorting) studies with our key personas to understand how they would group items in the left sidebar, and why. This helped us learn some areas that could benefit from readjusting, such as the Manage and Operate categories. We learned that users most often preferred to have analytics items together, for example, which is reflected in the Analyze tab. This insight, combined with patterns in analytics data, informed changes to the groupings in the left sidebar to better support workflows. \n\n## Launching and learning\nPrior to launching to external users, the new navigation was released to internal team members and we collected [feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/403059) to help iterate and improve the experience. \n\nNext, we launched the new navigation to external users as a toggle that could be turned on optionally. During this initial launch, a [longitudinal study](https://about.gitlab.com/handbook/product/ux/ux-research/longitudinal-studies/) was conducted with a sample of GitLab users to learn how they experienced the change in the context of their real work. Over time, the study would provide insight into adoption among the entire user base.  \n\nWe interviewed users prior to the monthlong study to learn more about their experience with the existing navigation. Then, they began using the new navigation while completing surveys and participating in interviews at checkpoints in the beginning, middle, and end of the month. This enabled us to capture their initial impressions of the new navigation, what they liked/disliked, how the new experience compared to the previous one, and if their sentiment changed over the course of the month as they continued to use the new navigation. \n\nUsers in this study found the new navigation to be an improvement from the previous one, and most preferred its features, including:\n- the ability to pin items streamlined common workflows\n- the new task-based sidebar categories in the sidebar, which they said felt more approachable, especially for newer users\n- the new navigation changes, which they said weren’t too overwhelming and felt familiar\n\nWe also learned about some opportunities to iterate and improve the new experience. For instance, some users pointed out:\n- the inability to pin entire Projects, Groups, or specific pages makes it difficult to streamline other workflows\n- some users unpin items accidentally\n- the overall lack of color can cause some features to blend in or be missed\n- it's not always easy to know what’s new in GitLab  \n\n## What’s next: Iterate, listen, and iterate again\nTo capture large-scale feedback on navigation over time, we launched a new navigation-focused quarterly survey in Q1 (February) of this year. This first quarter data established a baseline of our old navigation, and beginning in Q2 (May), we began collecting data on the new navigation experience. We will monitor this closely, and look for themes to help us learn what is working well and what may need further iteration. \n\nThis survey, along with our longitudinal study feedback and various other user feedback sources, will provide insights to help prioritize iterative improvements to the new navigation experience. Stay tuned for changes, and keep sharing [your navigation feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/409005) with us!\n",[676,677,678],"inside GitLab","UX","research",{"slug":680,"featured":6,"template":681},"navigation-research-blog-post","BlogPost","content:en-us:blog:navigation-research-blog-post.yml","Navigation Research Blog Post","en-us/blog/navigation-research-blog-post.yml","en-us/blog/navigation-research-blog-post",[687,708,731,752,772,792,815,839,859,880,901,921,942,960,981,1002,1022,1042,1062,1083,1102,1122,1141,1161,1180,1201,1222,1242,1262,1281,1300,1319,1339,1357,1376,1395,1414,1433,1454,1473,1493,1512,1531,1549,1568,1586,1605,1625,1645,1664,1683,1702,1721,1740,1759,1778,1798,1818,1837,1858,1878,1897,1917,1936,1955,1975,1996,2015,2034,2053,2072,2090,2111,2130,2148,2167,2185,2204,2223,2241,2261,2280,2300,2319,2338,2357,2376,2396,2415,2434,2453,2472,2491,2510,2529,2548,2568,2587,2606,2624,2643,2663,2682,2700,2721,2740,2759,2778,2797,2816,2837,2856,2875,2894,2913,2933,2952,2971,2990,3010,3029,3047,3066,3085,3103,3122,3141,3160,3179,3198,3217,3237,3255,3276,3295,3314,3333,3352,3370,3389,3407,3425,3442,3461,3480,3499,3518,3537,3556,3575,3594,3614,3633,3652,3671,3688,3707,3726,3745,3764,3782,3801,3820,3839,3858,3876,3894,3913,3933,3952,3971,3990,4010,4029,4048,4068,4086,4104,4122,4140,4158,4176,4194,4212,4231,4249,4267,4285,4303,4321,4340,4359,4378,4396,4414,4432,4450,4469,4487,4505,4524,4543,4561,4579,4598,4617,4636,4654,4671,4689,4707,4726,4743,4761,4780,4799,4818,4836,4854,4871,4889,4906,4924],{"_path":688,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":689,"content":695,"config":702,"_id":704,"_type":17,"title":705,"_source":18,"_file":706,"_stem":707,"_extension":21},"/en-us/blog/beautifying-of-our-ui",{"title":690,"description":691,"ogTitle":690,"ogDescription":691,"noIndex":6,"ogImage":692,"ogUrl":693,"ogSiteName":667,"ogType":668,"canonicalUrls":693,"schema":694},"Beautifying our UI: Giving GitLab build features a fresh look","Get an inside look at how we are improving the usability of GitLab build features with multiple visual design improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682807/Blog/Hero%20Images/beautify.jpg","https://about.gitlab.com/blog/beautifying-of-our-ui","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Beautifying our UI: Giving GitLab build features a fresh look\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2023-07-05\",\n      }",{"title":690,"description":691,"authors":696,"heroImage":692,"date":698,"body":699,"category":14,"tags":700},[697],"Veethika Mishra","2023-07-05","\n\nThe current technical landscape is completely different from what it was this time last year. As the software development industry is busy evolving its understanding of _automating early and often_ in the presence of new AI capabilities, we have been focused on feature work. However, it's equally important to make sure we are adapting our UI to match up to the experience and addressing, where necessary, the misalignment between the two. \n\nIn a scaling product, where issues are competing to be prioritized, it might feel convenient to tackle the next feature issue as opposed to focusing on small visual design improvements. Advocating for the value that a small visual design change in isolation brings to the product is never easy for all the practical reasons, and this is where [the \"Beautifying our UI\" initiative](https://about.gitlab.com/handbook/product/ux/product-design/#beautifying-our-ui) becomes useful at GitLab. It allows a product designer and a frontend engineer to voluntarily pair up, like we did, and make self-directed improvements to the usability of GitLab.\n\nWe collaborated on many pipeline-related features in the past three years. As our responsibilities pulled us in different directions, we had to put many of our aspirational plans for improving the presentation of CI/CD features in GitLab on hold in favor of other more important things.\n\nHowever, once those were addressed, we decided to volunteer for a session of Beautifying our UI in the 16.1 milestone. To make the most of a single milestone, we began preparing a couple months in advance, soliciting ideas from team members and getting the design proposals ready in [an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/394768/). After a quick prioritization exercise to understand which of the suggested improvements would be most meaningful to our users, we made a number of contributions to the product.\n\nHere are some of those contributions:\n\n### Improvement to pipeline detail page\nIn the process of troubleshooting a failing pipeline, users often have to visit their detail page for better insight into what's causing the failure. The top of the page previously had a table with all the metadata around that pipeline. Over the years, a lot of information was added to this table but the layout was never optimized to accommodate that information, which in return impacted the usability of the page. The page headers were also very different from other examples found in GitLab. \n\nBy critically looking at every piece of information displayed on the page, we made informed decisions using the qualitative insights and the usage data at hand to completely redesign the pipeline header.\n\n![image of pipeline detail page before](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-detail-before.png)\nBefore\n{: .note.text-center}\n\n![image of pipeline detail page after making changes](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-detail-after.png)\nAfter\n{: .note.text-center}\n\nThis work was substantial and while we did our best to avoid any negative impact to our users, we realize there might be a few issues. Please share your comments in this [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/414756) about the redesign and we'll prioritize addressing them.\n\nRedesigning the pipeline header came with a few technical challenges because a lot of the code was a mix between HAML and Vue. We had to slowly refactor the pipeline header over to Vue/GraphQL to allow our code to be more performant and maintainable. It’s pretty much like building a completely new feature — we had to get creative with passing data to the Vue app from Rails.\n\n### Harmonizing badges and link styles on pipeline list view\nThe pipeline index page (list view) is one of the most visited pages in GitLab because users need to make sure any failing pipelines are identified quickly for troubleshooting. Since there's a lot going on on this page, it is critical that the UI leads users' attention to the right areas. Previously, almost every link presented in the pipeline column had a different visual treatment, which made the page visually noisy and harmed the usability and scannability of the information. Our goal was to remove anything that isn't required and harmonize the visual language so it is easy for CI/CD users to perform their jobs effectively. \n\n![image of pipeline detail page before](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-index-page-before.png)\nBefore\n{: .note.text-center}\n\n\n![image of pipeline detail page after making changes](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-index-page-after.png)\nAfter\n{: .note.text-center}\n\n### Linking runner number to runner admin page\nTo allow easy management of runners across an instance, we've now provided easy access to the runner admin page right from the job detail page. Previously a static test, now the runner number can directly take users with the runner admin page where they can make changes to the specific runner's configuration.\n\n![image of cancel pipeline label](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/runner-link-from-job-logs.png)\nLinking runner admin page from job logs page\n{: .note.text-center}\n\n### Improving tooltips and button text\nThe tooltips on the jobs list view were using native browser tooltips. We've changed those to use a design-system-compliant tooltip for consistency and better readability.  \n\nWe gathered some useful feedback on the usability of the button labels and took this as an opportunity to improve a few of them. Here's one example where we changed the label text for the button for canceling a running pipeline from **Cancel running** to **Cancel pipeline** and added an appropriate tooltip to clearly communicate the action. \n\n![image of cancel pipeline label](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/cancel-pipeline-label.png)\nButton with new label text\n{: .note.text-center}\n\n## More to come\nWe are not stopping with this list! We will continue our partnership to bring in more visual and usability improvements to the continuous integration area in the coming months. If you are interested in taking a look at the complete list of changes we have made and the ones we still plan to make, [you can find the issue here](https://gitlab.com/gitlab-org/gitlab/-/issues/394768/). \n\n\n",[677,701],"design",{"slug":703,"featured":6,"template":681},"beautifying-of-our-ui","content:en-us:blog:beautifying-of-our-ui.yml","Beautifying Of Our Ui","en-us/blog/beautifying-of-our-ui.yml","en-us/blog/beautifying-of-our-ui",{"_path":709,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":710,"content":716,"config":725,"_id":727,"_type":17,"title":728,"_source":18,"_file":729,"_stem":730,"_extension":21},"/en-us/blog/best-practices-leading-orgs-to-release-software-faster",{"title":711,"description":712,"ogTitle":711,"ogDescription":712,"noIndex":6,"ogImage":713,"ogUrl":714,"ogSiteName":667,"ogType":668,"canonicalUrls":714,"schema":715},"4 best practices leading orgs to release software faster","GitLab's 2023 Global DevSecOps Survey illuminates the strategies that organizations deploying more frequently have in common.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663908/Blog/Hero%20Images/2023-devsecops-report-blog-banner2.png","https://about.gitlab.com/blog/best-practices-leading-orgs-to-release-software-faster","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 best practices leading orgs to release software faster\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kristina Weis\"}],\n        \"datePublished\": \"2023-06-08\",\n      }",{"title":711,"description":712,"authors":717,"heroImage":713,"date":719,"body":720,"category":14,"tags":721},[718],"Kristina Weis","2023-06-08","\nReleasing software faster is one of the biggest goals of many organizations — and for good reason. It helps them keep up with competitors, land and keep more customers, improve employee satisfaction, and much more. But maintaining that velocity requires investment in processes and technologies that help DevSecOps teams deliver, secure, and deploy software faster without compromising quality.\n\nIn our [2023 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2023/) we asked more than 5,000 development, security, and operations professionals about everything from deployment frequency to the practices teams have adopted – all to learn what the most agile and efficient organizations have in common. One respondent, a director of IT security in the retail sector, summed up the challenge as follows: “Software customers are increasingly vocal and demanding, expecting faster releases and greater customizability. Developers will need to keep up with these demands while still maintaining stability and usability.”\n\nSo what’s helping organizations be more productive and efficient? Here are four of the best practices that, according to the survey, help organizations release software faster and deploy more frequently:\n\n## 1. Running applications in the cloud\nOne of the benefits people commonly attribute to deploying to the cloud is increased development speed. As it turns out, this year’s survey shows there’s some serious truth to that. Respondents with at least a quarter of their applications in the cloud were 2.2 times more likely to be releasing software faster than they were a year ago — and respondents with at least half of their applications in the cloud were 4.2 times more likely to deploy to production multiple times per day. \n\nSeveral respondents commented on the value of the cloud while also acknowledging the complexities cloud computing can bring to software development. An IT operations manager in the industrial manufacturing sector shared that “developing software that is designed for the cloud-native environment” is one of the top challenges facing software development this year. Likewise, an IT operations manager in the telecommunications sector said: “With the increase in the use of cloud computing and IoT devices, there is a greater need for secure coding practices to protect sensitive data from cyber attacks.” As organizations move to a cloud-first model for software development, they will need to adopt technologies that allow them to build natively in the cloud while keeping security top of mind throughout the development process.\n\n## 2. BizDevOps\nThough DevOps and DevSecOps mostly steal the show in terms of methodologies, some organizations go a step further and [practice BizDevOps](https://about.gitlab.com/blog/a-snapshot-of-modern-devops-practices-today/) — that is, incorporating business teams alongside development, security, and operations teams. An IT operations manager in the software sector emphasized the importance of collaboration with the business, sharing that “as software projects become larger and more complex, developers will need to work closely with other team members, including designers, testers, project managers, and business stakeholders.” This approach appears to be paying off for some: Respondents whose organizations practice BizDevOps were 1.4 times more likely to be releasing software faster than they were a year ago.\n\n## 3. CI/CD\nIt’s not surprising that automating the software development lifecycle with [CI/CD](https://docs.gitlab.com/ee/ci/) would help teams release software faster and more efficiently; however, it’s nice to see confirmation and put some numbers to the difference it can make. The survey shows that respondents [practicing CI/CD](https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices/) were twice as likely to deploy multiple times per day and 1.2 times more likely to release software faster than they did a year ago.\n\nDespite the value of CI/CD for driving efficiency, respondents also identified challenges. For instance, an IT operations associate in the aerospace/defense sector pointed to “management that doesn't understand CI/CD at all” as a blocker to more efficient software development. Meanwhile, a software development intern in the biotech sector shared that “tools to automate CI/CD, together with code editors, APM software, and defect trackers, can help with a faster and quality development cycle,” but “companies are hesitant to spend on tools that can help increase their developers’ productivity.” These responses underscore the value of investing in tools that unify CI/CD with other DevSecOps practices — such as incorporating security early in the development process and creating tighter feedback loops — to help organizations break down development silos.\n\n## 4. DORA and other metrics\nOrganizations that [make a conscious effort to track key development metrics](https://about.gitlab.com/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too/) are more likely to improve them, according to the survey. This makes sense because by virtue of an organization choosing to track a metric, they’re signaling to their teams that it’s important, likely reminding them of whether the metric is improving (or not) periodically, and quite possibly prioritizing initiatives aimed at improving those metrics. We found that respondents whose organizations track their [DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html) and other similar metrics were 1.4 times more likely to deploy multiple times per day.\n\n## A deeper dive on productivity and efficiency\n\nFor a deeper look into release velocity and deployment frequency, and all the practices that made respondents more likely to release software faster and deploy multiple times per day, check out our [2023 DevSecOps Report: Productivity & Efficiency Within Reach](https://about.gitlab.com/developer-survey/).\n\nThe report also digs into two other key factors that can have a big impact on productivity and efficiency: how long it takes to onboard new developers and how difficult or easy it is for organizations to attract, hire, and retain developers. We’ll show you where things stand and the practices that made respondents more likely to be successful.\n\n_[Read the highlights from “Security Without Sacrifices,” the first report in our 2023 Global DevSecOps Report series.](/blog/gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops/)_\n",[722,110,723,724],"developer survey","cloud native","DevSecOps",{"slug":726,"featured":6,"template":681},"best-practices-leading-orgs-to-release-software-faster","content:en-us:blog:best-practices-leading-orgs-to-release-software-faster.yml","Best Practices Leading Orgs To Release Software Faster","en-us/blog/best-practices-leading-orgs-to-release-software-faster.yml","en-us/blog/best-practices-leading-orgs-to-release-software-faster",{"_path":732,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":733,"content":739,"config":746,"_id":748,"_type":17,"title":749,"_source":18,"_file":750,"_stem":751,"_extension":21},"/en-us/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms",{"title":734,"description":735,"ogTitle":734,"ogDescription":735,"noIndex":6,"ogImage":736,"ogUrl":737,"ogSiteName":667,"ogType":668,"canonicalUrls":737,"schema":738},"GitLab named a Leader in the 2023 Gartner Magic Quadrant for DevOps Platforms","In the first Gartner® Magic Quadrant™ for this category, GitLab is positioned highest on the Ability to Execute axis.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663830/Blog/Hero%20Images/gartner-report-blog-asset.jpg","https://about.gitlab.com/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named a Leader in the 2023 Gartner Magic Quadrant for DevOps Platforms\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2023-06-07\",\n      }",{"title":734,"description":735,"authors":740,"heroImage":736,"date":742,"body":743,"category":14,"tags":744},[741],"Ashley Kramer","2023-06-07","\nToday marks an important milestone for DevOps and for GitLab. \n\nGartner® recognized GitLab as a Leader in the 2023 Gartner® Magic Quadrant™ for DevOps Platforms – the first Magic Quadrant for the category – positioned highest on the Ability to Execute axis. According to Gartner, Leaders execute well against their current vision and are well-positioned for tomorrow. \n\nSince our founding, we have been focused on delivering the most comprehensive suite of solutions for every use case – and for every stakeholder - in developing and deploying software. These solutions come together as a comprehensive platform that eliminates point solution tool sprawl and a ‘Do it Yourself’ DevOps approach. GitLab brings together everyone involved in the software development lifecycles – development teams, security teams, operations teams – to collaborate together on the same platform. \n\nWe believe Gartner naming GitLab a Leader in the Magic Quadrant for DevOps Platforms is a recognition of our success in both creating a comprehensive software development and delivery platform, and our role in helping mature the DevOps Platform category so that it is ready for mainstream technology adoption. \n\n![2023 Gartner® Magic Quadrant™ for DevOps Platforms](https://about.gitlab.com/images/blogimages/gartnermqfigure1.png){: .shadow}\n\nGitLab’s goal is to help our customers deliver software faster. We do this by improving developer productivity, increasing operational efficiency, securing the software supply chain, and accelerating their digital transformation. Today, GitLab is the most comprehensive AI-powered DevSecOps platform. \n\n> Download the [2023 Gartner Magic Quadrant for DevOps Platforms](http://about.gitlab.com/gartner-magic-quadrant).\n\n### Reducing complexity and increasing operational efficiency \nWe focus on reducing production risks through automation. With a best-in-class CI/CD solution, GitLab empowers teams to build and test every change as well as create scalable and repeatable software delivery processes. Our platform eliminates the complexity of sprawling toolchains, preventing context switching, reducing cognitive load, improving developer satisfaction, and driving operational efficiencies across organizations. \n\n### Shifting left with embedded security \nGitLab helps organizations meet [the need for speed and security](/the-source/ai/velocity-with-guardrails-ai-automation/) throughout the software supply chain because security is embedded within the software development lifecycle rather than bolted on as an afterthought. GitLab enables teams to automate policy enforcement, compliance frameworks, and security testing, which frees up resources. We continue to innovate in security. In the last quarter alone, we’ve introduced capabilities that support centralized policy management; expand our compliance reports, controls, and dashboards; and support default [SLSA Level 3 attestations](/direction/supply-chain/#frameworks).\n\n### Driving action with insights and metrics \nGitLab helps customers understand and analyze every aspect of the software delivery process. We are innovating on [value stream management](/solutions/value-stream-management/) through a unified data store, [tracking of DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html), value stream dashboards, and value stream analytics – all designed to give stakeholders a unique and useful view into the end-to-end software delivery value stream. Organizations can now visualize and manage DevSecOps workflows – from ideation to delivery – to gain insight into how digital transformation and technology investments are delivering value and driving business results.\n\n### Embedding AI throughout the software development lifecycle\nGitLab is an [AI-powered DevSecOps platform](/solutions/ai/). We adopt a privacy-first approach, ensuring that organizations can be confident their intellectual property is safe within our infrastructure. We integrate AI throughout the software development lifecycle to improve cycle time, from code creation and testing to security and deployment.\n\n### Empowering innovation with open core \nGitLab is built on an open core model, enabling us to be on the leading edge of innovation. Every year, our customers and the community at-large contribute hundreds of new capabilities to our DevSecOps platform. Through our feedback issues and publicly available roadmaps, we continue to stay close to our community and invite everyone to help improve our platform. \n\nOn behalf of the GitLab team, we are honored to be named a Leader by Gartner in the 2023 Gartner Magic Quadrant for DevOps Platforms. We will continue to innovate every day to make DevSecOps even more effective for our customers and to achieve our mission to make it so [everyone can contribute](/company/mission/). \n\n> Download the [2023 Gartner Magic Quadrant for DevOps Platforms](http://about.gitlab.com/gartner-magic-quadrant).\n\n*Gartner, Magic Quadrant for DevOps Platforms, Manjunath Bhat, Thomas Murphy, Joachim Herschmann, Daniel Betts, Chris Saunderson, Hassan Ennaciri, Bill Holz, Peter Hyde, 05 June 2023* \n\n*GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.*\n\n*Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.*\n\n*This graphic was published by Gartner Inc. as part of a larger report and should be evaluated in the context of the entire document. The Gartner document is available upon request from Gartner B.V.*\n",[745,678,476],"news",{"slug":747,"featured":6,"template":681},"gitlab-leader-gartner-magic-quadrant-devops-platforms","content:en-us:blog:gitlab-leader-gartner-magic-quadrant-devops-platforms.yml","Gitlab Leader Gartner Magic Quadrant Devops Platforms","en-us/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms.yml","en-us/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms",{"_path":753,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":754,"content":760,"config":766,"_id":768,"_type":17,"title":769,"_source":18,"_file":770,"_stem":771,"_extension":21},"/en-us/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms",{"title":755,"description":756,"ogTitle":755,"ogDescription":756,"noIndex":6,"ogImage":757,"ogUrl":758,"ogSiteName":667,"ogType":668,"canonicalUrls":758,"schema":759},"GitLab named Leader in The Forrester Wave Integrated Software Delivery Platforms 2023","The Forrester report recognized GitLab for its roadmap, which includes supply chain security, enhanced UI, granular security and compliance controls, and pipeline security.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682752/Blog/Hero%20Images/Forrestercoverimage.png","https://about.gitlab.com/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named Leader in The Forrester Wave Integrated Software Delivery Platforms 2023\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2023-06-06\",\n      }",{"title":755,"description":756,"authors":761,"heroImage":757,"date":763,"body":764,"category":14,"tags":765},[762],"GitLab","2023-06-06","\n\nDemand for a platform approach to software delivery is increasing as organizations realize the inefficiencies and costs of stitched-together solutions for software delivery, siloed visibility, broken feedback loops, and increased risk of cyberattacks. We recognized the value of the platform approach early on — and we believe that GitLab's single-application DevSecOps Platform is the best way for organizations to improve developer productivity, build high-performing teams, secure the software supply chain, and implement cloud transformations. \n\n## GitLab’s DevSecOps Platform recognized\n![Your image alt text](https://about.gitlab.com/images/blogimages/forresterwave2.png){: .shadow.small.left.wrap-text} In its evaluation, and in the first year of this report, Forrester has named GitLab as the only **Leader** in **The Forrester WaveTM: Integrated Software Delivery Platforms, Q2 2023**. The report evaluated 13 integrated software delivery platform (ISDP) vendors across 26 criteria based on current offering, strategy, and market presence. GitLab scored the highest possible in the criteria of platform-incorporated security tools test automation, roadmap, community, and pricing flexibility and transparency.\n\nWe are excited to see the market mature and recognize the value of an integrated software delivery platform — a strategy GitLab has followed from the start. Our DevSecOps platform is offered as a single application with a unified data store, increasing efficiency and collaboration and providing value unmatched by traditional vendors and complex toolchains. It provides essential automation needed by various teams in the software delivery lifecycle, along with security and governance needed by security professionals. We also integrate artificial intelligence (AI) throughout the SDLC by incorporating it into our comprehensive enterprise DevSecOps platform.\n\n> Download [The Forrester Wave: Integrated Software Delivery Platforms, Q2 2023 report](https://page.gitlab.com/forrester-wave-integrated-software-delivery-platforms-2023.html).\n\nRecognizing our leadership and continued innovation, the report emphasizes that GitLab “has led the industry towards consolidated ISDPs. GitLab's strategy includes an on-par vision to deliver an excellent developer experience without sacrificing security or compliance.... GitLab is great for enterprises wishing to consolidate their best-of-breed toolchain into one, high-performing ISDP.”\n\n> “GitLab is far ahead of its competitors and provides one product which offers an easy-to-set-up, easy-to-start product with all these capabilities integrated,” says **Daniel Widerin, Head of Software Delivery, Hilti**\n\n## Roadmap gets high scores\n\nThe Forrester report recognized GitLab for its roadmap and focus on community. “[GitLab’s] roadmap gets leading scores and includes enhanced supply chain security, enhanced UI, granular security and compliance controls, and pipeline security – all things enterprises need.”\n\nThe research firm added: “[GitLab’s] innovation is also good, going beyond traditional developers to include AI/ML engineering. GitLab is an open core product that not only invests heavily in the open source software (OSS) community but also enables its customers to contribute to the product, earning it high scores for community.”\n\nGitLab is trusted by more than 30 million users and more than 50% of Fortune 100 organizations. We will continue to focus on integrating transformative technologies into our DevSecOps Platform, such as AI, into all parts of the software delivery lifecycle, software supply chain security, and value stream analytics, to enable customers to accelerate and secure software development and delivery.\n\n> Download [The Forrester Wave: Integrated Software Delivery Platforms, Q2 2023 report](https://page.gitlab.com/forrester-wave-integrated-software-delivery-platforms-2023.html).\n\n",[745,678,476],{"slug":767,"featured":6,"template":681},"gitlab-leader-forrester-wave-integrated-software-delivery-platforms","content:en-us:blog:gitlab-leader-forrester-wave-integrated-software-delivery-platforms.yml","Gitlab Leader Forrester Wave Integrated Software Delivery Platforms","en-us/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms.yml","en-us/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms",{"_path":773,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":774,"content":780,"config":786,"_id":788,"_type":17,"title":789,"_source":18,"_file":790,"_stem":791,"_extension":21},"/en-us/blog/avoiding-burnout-as-product-designers",{"title":775,"description":776,"ogTitle":775,"ogDescription":776,"noIndex":6,"ogImage":777,"ogUrl":778,"ogSiteName":667,"ogType":668,"canonicalUrls":778,"schema":779},"Tips to avoid burnout for product designers","Effective prioritization and boundary setting are critical to product designers' growth.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670082/Blog/Hero%20Images/productdesign.jpg","https://about.gitlab.com/blog/avoiding-burnout-as-product-designers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tips to avoid burnout for product designers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2023-03-28\",\n      }",{"title":775,"description":776,"authors":781,"heroImage":777,"date":782,"body":783,"category":14,"tags":784},[697],"2023-03-28","\n\nProduct designers often choose to become a designer because of the hard-to-beat and attractive promise that accompanies it: improving the lives of people by adding value through design. Being a designer, I can vouch for how fulfilling and rewarding it can be to see a bud of an idea grow into a feature that is enjoyed by users. However, the demands of product designers can quickly become overwhelming as roles, products, and teams evolve - if left unchecked, this can result in burnout. In this blog, I will discuss how to avoid burnout by being intentional about time management and communication.\n\n## What is a product designer’s scope?\nAt GitLab, similar to many other software companies, [product designer responsibilities](https://handbook.gitlab.com/job-families/product/product-designer/) span designing thoughtfully crafted experiences, playing a central role in the overall business contributions, and everyday collaboration with key product stakeholders. The spectrum has grown over time, leading to a general misconception among designers that they are required to overreach their potential to prove their pedigree. Instead, taking up the right responsibility at the right time and doing it well often produces better results.\n\n## Define your own frame\nEach product designer envisions growth differently. In the pursuit of growth, to demonstrate specific expertise or leadership qualities, each designer may have a unique goal in mind in terms of the means you want to employ or the results you seek from that goal. Also, this implies that you cannot trust a generic template approach to map your priorities. The lens you use to distinguish important responsibilities and tasks from the rest are unique and your planning and rituals should be as well. \n\n## Establish an availability baseline\nA couple years ago, my manager, [Rayana Verissimo](https://gitlab.com/rayana), gave me a task of writing down an approximate estimation of how much time I plan to dedicate to each of the major responsibilities in my role. The math seemed simple at first: I work 40 hours a week and I had a list of about eight responsibilities. I had an idea in mind on how to divide up those responsibilities. What could go wrong? \n\nAs they say, life happens while we’re busy making other plans. I was preparing to move between countries and, in that same timeframe, our team was onboarding a new product manager. Without realizing it, I began spending a considerable amount of time at work on admin-related tasks and getting my processes in sync with my new product manager. These shifts were unannounced and unavoidable. Such surprise challenges are a part of all of our lives, though the form may vary. But when they happen, it is best to be accepting of them and keep some wiggle room in your time allotment estimation to accommodate them without disturbing the rest of your plan. \n\nThere are different ways to understand and manage your capacity. [Sunjung Park](https://gitlab.com/sunjungp), a product designer at GitLab, relies on the [UX issue weights](/handbook/product/ux/product-designer/#ux-issue-weights) framework to maintain a closer to accurate predictability of her tasks for a release cycle. I personally like to use the same and communicate my capacity for the release cycle to the team using a [planning issue](https://gitlab.com/gitlab-org/gitlab/-/issues/386189).\n\n## Assess the importance of a task to you \nDespite the evident benefits, [McKinsey Design Index](https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design) proved to be the very sign that the tech and other industries had always been looking for to validate the correlation between design and financial performance of an organization. Realizing how it can help them differentiate in the industry and directly impact revenue streams, organizations now expect designers to make some business-critical decisions, thereby expanding their responsibilities to be more cross-functional.\n\nThis evolution has led product designers to jump at every opportunity and request. However, if you do not take a moment to assess the “why” of the opportunity or request, you’re merely setting yourself up for failure. Product designers can ask some questions to help decide whether to take on the project:\n- Does the project require my expertise and skills, or help me develop one that aligns with my personal goals?\n- Does the project contribute to the business' goals?\n- Is this project something that someone else can do better than I can - while I invest my time doing something that I can do more confidently? \n- Am I on the same page with the requestor in terms of expectations and time commitment?\n- Will my delivery plan get impacted if I commit to this project? If so, what trade-offs can or need to be made?\n\n## Build trust and communicate transparently\nThe urge to say “yes” is an instinct of human behavior. However, when you say yes to every request from our peers/colleagues, you feed the [cycle of responsiveness](https://hbr.org/2012/05/are-you-sleeping-with-your-sma) to become more intense, to a point where you no longer can respond to the demand. This overwhelming wave of expectations puts you in a position where you stop exercising your creative muscles out of exhaustion and merely keep working more and more, driving down the quality of results. Making it a false victory, if one at all. Ironically, this, in turn, impacts the very relationship that you said “yes” to in the first place.\n\nI have already talked about how to decide if an opportunity or request is aligned to your goals. If the answer to that is “it isn’t,” the next thing you need to do is communicate that clearly to the requester. \n\nA plain “no” can easily be perceived as rude, but kindly communicating an honest and straightforward reason will have a higher chance of building trust with your peers than saying yes and delivering substandard results. The GitLab sub-value [Directness](https://handbook.gitlab.com/handbook/values/#directness) emphasizes the importance of transparent communication with colleagues. Another method a few members of my team, including me, use for maintaining transparency in everyday priorities is [documenting them publicly](https://gitlab.com/veethikaa/veethika-planner/-/blob/master/Weekly%20Priorities/weekly-priorities.md) in a GitLab project and keeping them visible to the team and our counterparts. \n\n## A checklist to avoid burnout\nIf you're looking to continue to enjoy your work as a product designer while also growing in your job, the following tips can help:\n\n- Take a step back and try to understand your own drives and motivations so you can more effectively plan your path ahead.\n- Be realistic about your capacity and potential trade-offs, and communicate the same to your team transparently.\n- Be discerning while taking up a new opportunity, ensure it aligns with your goals, and be comfortable passing it along to a colleague that is better suited if it doesn't.\n- Keep your communication honest, humble, and non-ambiguous to avoid miscalculated commitments that can harm relationships with your peers.\n\nMindfully and intentionally assessing a new opportunity rather than reacting by impulse can play a major role in setting yourself, and your colleagues, up for success, resulting in a happier, more impactful, and less stressful work environment.\n\n_Cover image by \u003Ca href=\"https://unsplash.com/@freestocks?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">freestocks\u003C/a> on \u003Ca href=\"https://unsplash.com/photos/vcPtHBqHnKk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>_\n",[677,701,785],"remote work",{"slug":787,"featured":6,"template":681},"avoiding-burnout-as-product-designers","content:en-us:blog:avoiding-burnout-as-product-designers.yml","Avoiding Burnout As Product Designers","en-us/blog/avoiding-burnout-as-product-designers.yml","en-us/blog/avoiding-burnout-as-product-designers",{"_path":793,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":794,"content":800,"config":809,"_id":811,"_type":17,"title":812,"_source":18,"_file":813,"_stem":814,"_extension":21},"/en-us/blog/how-is-ai-ml-changing-devops",{"title":795,"description":796,"ogTitle":795,"ogDescription":796,"noIndex":6,"ogImage":797,"ogUrl":798,"ogSiteName":667,"ogType":668,"canonicalUrls":798,"schema":799},"How is AI/ML changing DevOps?","Can DevOps help AI/ML find maturity? Here are questions to consider.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667540/Blog/Hero%20Images/devops-team-structure.jpg","https://about.gitlab.com/blog/how-is-ai-ml-changing-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How is AI/ML changing DevOps?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n        \"datePublished\": \"2022-11-16\",\n      }",{"title":795,"description":796,"authors":801,"heroImage":797,"date":803,"body":804,"category":14,"tags":805},[802],"Brendan O'Leary","2022-11-16","\n\nThe last few years have seen an explosion in artificial intelligence, [machine learning](/blog/top-10-ways-machine-learning-may-help-devops/), and other types of projects. Companies like Hugging Face and applications like [DALL-E 2](https://openai.com/dall-e-2/) have brought to the mainstream what the power of AI/ML can bring to the next generation of computing and software. As every company has become a software company over the last few decades, the ability to innovate and leverage the ever-growing amount of data that organizations have access to have become where enterprises turn to compete.\n\nHowever, a lot of AI/ML projects get stalled from several challenges that may seem familiar to software professionals who have been around since [the early days of DevOps](/blog/the-journey-to-a-devops-platform/).  Adoption and optimization of artificial intelligence and machine learning have been hampered by a lack of repeatability for experiments, a disparity of tools and information silos, and a lack of team collaboration.\n\n## A new model for data modeling\n\nOne of the first ways to look at this problem is to make sure that the mental model is in place to allow the team to reason about both the strategic vision for AI/ML at your organization. And once that has been established, also think about the tactical “jobs to be done” to lay the foundation for that work.\n\nStrategically, there are many teams that have to come together for a successful AI/ML program. First, the data has to both be acquired and transformed into a usable set of clean data. Often referred to as [“DataOps”](/blog/introducing-modelops-to-solve-data-science-challenges/) this involves the typical “ETL” or extract, load, transform processes data has to go through to be useful for teams. From there, you have to productionize the data workloads through MLOps - the experimentation, training, testing, and deployment of meaningful models based on the extracted and transformed data.\n\nAnd once those two steps are complete, you can finally understand how to make production use cases for your data. You can use AI Assisted features to focus on improving user experiences, for financial forecasting, or for general trends and analysis of various parts of your business. Given the complexity of this value chain, the various teams and skills involved, and the current mishmash of tooling, there is a lot that teams can learn from the history of DevOps as they tackle these problems.\n\n## DevOps and AI/ML\n\nMuch like the various stages of obtaining and applying AI/ML for business uses, software development consists of many varied steps with different teams and skills sets to achieve the business goals outlined. That is why years ago, folks came up with this [concept of “DevOps”](/topics/devops/)– combining teams and having them work together in a cycle of continuous improvement towards the same goals – to combat silos and inefficiencies. \n\nData science teams are using specialized tools that don't integrate with the existing software development lifecycle tools they already use. This causes teams to work in silos, creating handoff friction and resulting in finger-pointing and lack of predictability. Businesses and software teams often fail to take advantage of data, and it takes months for models to get into production by which time they may be out of date or behind competitors.  Security and data ethics are frequently treated as an afterthought. This creates risk for organizations and slows innovation. \n\n## Learning from the past\n\nIf the past decades of “DevOps” evolution have taught us anything, it's that breaking down the silos between teams through the tools and processes they are using pays off dividends for business. As your team begins their [AI/ML journey](/blog/why-ai-in-devops-is-here-to-stay/) — or if you've found yourself stalling in AI/ML initiatives already — you should consider how you can consolidate teams together, ensure they are working efficiently together, and able to collaborate without boundaries.\n\nAn explosion of tools in the space is tantalizing with the promise of “getting started” quickly. But it may not set your organization up for long-term success in these areas if those tools have the effect of separating parts of your organization from one another. Creating and sustaining an AI/ML program will require intentionality behind both the processes and tools your team is using. That allows your teams to extract, transform and load data efficiently, tune, test and deploy models effectively, and leverage AI/ML to drive value for your stakeholders for the long haul.\n",[806,232,807,808],"DevOps","performance","AI/ML",{"slug":810,"featured":6,"template":681},"how-is-ai-ml-changing-devops","content:en-us:blog:how-is-ai-ml-changing-devops.yml","How Is Ai Ml Changing Devops","en-us/blog/how-is-ai-ml-changing-devops.yml","en-us/blog/how-is-ai-ml-changing-devops",{"_path":816,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":817,"content":823,"config":833,"_id":835,"_type":17,"title":836,"_source":18,"_file":837,"_stem":838,"_extension":21},"/en-us/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":818,"description":819,"ogTitle":818,"ogDescription":819,"noIndex":6,"ogImage":820,"ogUrl":821,"ogSiteName":667,"ogType":668,"canonicalUrls":821,"schema":822},"Five fast facts about docs as code at GitLab","Here are five fast facts about how GitLab technical writers use GitLab in a docs-as-code workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Five fast facts about docs as code at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suzanne Selhorn\"},{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Diana Logan\"}],\n        \"datePublished\": \"2022-10-12\",\n      }",{"title":818,"description":819,"authors":824,"heroImage":820,"date":828,"body":829,"category":14,"tags":830},[825,826,827],"Suzanne Selhorn","Susan Tacker","Diana Logan","2022-10-12","\n\nAt GitLab, we use GitLab as our single platform to document GitLab by using a “docs-as-code” workflow. Sound confusing? \n\nThe GitLab technical writing team uses GitLab to plan, create, review, edit, and publish the [GitLab documentation](http://docs.gitlab.com). And because we use the docs-as-code workflow, we can produce a large amount of content with a small, passionate, efficient team.\n\nIf you aren’t familiar with docs as code, here’s a quick definition: \n\n[Docs as code](https://idratherbewriting.com/trends/trends-to-follow-or-forget-docs-as-code.html#what-is-docs-as-code) is a way to develop and publish product documentation. It uses the same tools and processes as software code development, placing the documentation files along with the code files in a repository for version control. \n\nIf you are wondering whether your organization could adopt a docs-as-code workflow in GitLab, read on for five fast facts that help explain how our team does it.\n\n## We use GitLab to plan both GitLab features and docs content updates\n\nOur product managers, UX designers, engineers, and quality assurance teams work together to plan our feature work. Maybe when you’re planning releases, you use a Kanban board, or you create issues in a third-party tool.\n\nAt GitLab, we use epics and [issues](https://gitlab.com/gitlab-org/technical-writing/-/issues/680) to plan our work, and [issue boards](https://gitlab.com/groups/gitlab-org/-/boards/4340643?label_name%5B%5D=Category%3ADocs%20Site) to track our progress. We value transparency, so all of this information is available to everyone, including discussions about planning. The tech writing team has visibility into the status of development at any time.\n\n![planning issue](https://about.gitlab.com/images/blogimages/planning_issue.png)\n\nIf we have larger doc efforts, we track them in GitLab, make the changes by using GitLab, and mark issues as done in GitLab. If a year passes and we want to remember why we made a change, we search GitLab and find who made the change and why. If you’re working in many different tools right now, imagine what it would be like to view everything in one place. Everything feels faster and more efficient. You skip the time you’d normally spend going through emails and websites and Slack to find lost discussions. It’s all here in GitLab.\n\nAnd if you love your wiki and don’t want to go without it, we have a wiki feature too.\n\n## We use GitLab to give and receive feedback on the docs\n\nIf you’ve been a writer for any amount of time, you know what a pain it can be to get people to review your content.\n\nAt GitLab, our developers write the first draft of content for all our new features. They save the content in the same repository as their code. Feature documentation is part of our development “definition of done.” They assign the draft content to our writers, who review it, add suggestions, and send their ideas and edits back to the authors.\n\nThe writers themselves also open merge requests (MRs) for content changes. And no matter who opens the MR (the writer, a developer, a support engineer, a community contributor), we all have the ability to easily comment on each other’s work.\n\nIn a merge request, it’s as simple as selecting a Suggestion button. You can comment on one line or several. You can provide changes or edits, and the person who authored the merge request can easily apply your change, or create their own competing suggestion, and you can discuss it. To invite others to the conversation, you can type their username in a comment, and they see your comment as a to-do item in GitLab. In this way, you can discuss any change. It’s transparent and inclusive.\n\n![making a suggestion](https://about.gitlab.com/images/blogimages/suggestion.png)\n\nBecause the doc content is in markdown, which is similar to plain text, it’s easy to view the differences between file versions, and to see who committed which change.\n\nMaybe you’ve worked in places where reviews were done in PDFs, or Word docs, or Google docs with comments. When you try this workflow, you'll see how much more efficient the process is. No one is passing around outdated versions of documents. No one is making updates that inadvertently wipe out someone else’s comments.\n\nAnd if anyone ever wants to know why we made a change, it’s easy to view the history of the page or even view who is to “blame” for a specific line. \n\n![who to blame?](https://about.gitlab.com/images/blogimages/blame.png)\n\nYou don’t have to store versions of a PDF document and try to search for who suggested which change. It’s all in GitLab.\n\n## We use GitLab to preview the docs content\n\nAt GitLab, we have tools to generate the docs site content locally, but you can also easily share a view of the docs site right from a merge request. If you’re playing with an idea and you want to show someone, you open a merge request, generate what we call “a review app” and voila, the changed docs site is available at a publicly available URL.\n\n![the review app](https://about.gitlab.com/images/blogimages/view_app.png)\n\nYour changes are visible, and you can iterate on them or commit as-is. Which brings us to another one of the most useful features we have at GitLab.\n\n## We use GitLab to test every content change\n\nMaybe you’re using a third-party tool to test the links in your docs, or to check spelling and grammar rules.\n\nWe are using third-party tools (Nanoc for links, Vale for spelling and grammar), but like everything else, these tools can be incorporated into GitLab, and into the writer workflow.\n\nEach writer has our tools installed locally and can view everything, from the document’s reading level to passive and active voice fixes on their local machine. But for those contributors who don’t have the toolset, we run a version of our tests in a pipeline as part of every commit.\n\n![a lint error](https://about.gitlab.com/images/blogimages/lint_error_2.png)\n\nIf you’re a developer and you don’t consider yourself to be an expert writer, you might find that the pipeline failed on your merge request because of an important grammar or branding rule. We’ve defined a list of many rules, and assigned levels of importance to them. So not only do we have a [style guide](https://docs.gitlab.com/ee/development/documentation/styleguide/) and [word list](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html), but we also run tests to ensure our content doesn’t stray too far from those rules.\n\n## We use GitLab to generate the HTML output and we host the output on GitLab Pages\n\nOur CI/CD pipeline converts our markdown content and compiles it into HTML. Then we host this output on GitLab Pages, at the [docs.gitlab.com](http://docs.gitlab.com) website.\n\n![the pipeline](https://about.gitlab.com/images/blogimages/pipeline2.png)\n\nHaving the output generated by a pipeline means that we can update the docs site whenever we want. While the product is released once a month, we update the docs site once every hour. That means docs.gitlab.com always contains the most up-to-date content available, sometimes even pre-release information. Since the development planning and implementation issues are typically open to the public as part of our transparency value, pre-announcing features isn’t an issue. \n\nSo as you can see, for a multitude of reasons, we love our docs-as-code workflow. It can be an adjustment to transition to one tool for all of your doc needs, but GitLab supports the full writer workflow, no matter who writes your content. And we know, because we’ve been using it for years. \n\nLearn more about the tech writing docs-as-code work at GitLab:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZlabtdA-gZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nTo learn more about contributing to our open source documentation, check out our instructions in “[How to update the docs](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs).” We welcome your contributions!\n",[831,832,676],"careers","contributors",{"slug":834,"featured":6,"template":681},"five-fast-facts-about-docs-as-code-at-gitlab","content:en-us:blog:five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab","en-us/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","en-us/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"_path":840,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":841,"content":847,"config":853,"_id":855,"_type":17,"title":856,"_source":18,"_file":857,"_stem":858,"_extension":21},"/en-us/blog/what-makes-a-great-tech-talk",{"title":842,"description":843,"ogTitle":842,"ogDescription":843,"noIndex":6,"ogImage":844,"ogUrl":845,"ogSiteName":667,"ogType":668,"canonicalUrls":845,"schema":846},"What makes a great tech talk?","I've compiled some of my favorite tech talks to find out what makes them great.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670658/Blog/Hero%20Images/data-startup-cognitive-logic-talks-migrating-to-gitlab.jpg","https://about.gitlab.com/blog/what-makes-a-great-tech-talk","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What makes a great tech talk?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n        \"datePublished\": \"2022-10-04\",\n      }",{"title":842,"description":843,"authors":848,"heroImage":844,"date":849,"body":850,"category":14,"tags":851},[802],"2022-10-04","\n\nAs someone who spends a reasonable amount of time writing, rehearsing, and giving tech talks, I often find folks new to speaking about tech asking me: how do you do it? How do you know that you will be able to write and give an excellent tech talk?\n\nThe simple answer is: I don't know. An excellent tech talk isn't definable and solvable like an engineering problem. It's part tech, part passion, part storytelling, and part luck. But in thinking about speakers and talks that I've looked up to throughout the years, I believe that I've found a few key ingredients in any tech talk that I've seen and would consider \"great.\"  In reviewing these, I actually came to appreciate what I somewhat already knew: the \"tech\" part of the talk is probably the least important part of a great tech talk. Yet, as professionals, that is what we get wrapped around. And it is what worries us when writing a speech. The best demo ever - that's what will save my talk! But in the end, it's not just the tech content that counts, so let's look at the five critical ingredients for a great tech talk:\n\n- Story and narrative\n- Passion\n- Connection to the audience\n- Balance\n- Call to action\n\nFor each ingredient, I've included a talk that best illustrates that principle and a link to the talk. As an aside, every moderately good talk I've ever written was inspired while listening to or after hearing a great talk from one of these amazing technologists. Remember: [good artists copy, great artists steal](https://www.youtube.com/watch?v=a6jeZ7m0ycw).\n\n## Story and narrative\n\n[Keynote: Reflections](https://www.youtube.com/watch?v=jiaLsxjBeOQ): **Kelsey Hightower, KubeCon CloudNativeCon North America 2019**\n\nStories are how humans have always learned and taught each other. From the earliest stories around campfires to teach about the dangers of predators or the ways to find food to the modern world where we are bombarded by stories that we now call 'marketing' - stories have always played a pivotal role in learning and teaching.\n\nAnd so, without a story, your audience is already lost. You can show some of the most incredible technology, a fantastic demo, and wow people with statistics...but if there is no connection to the real world - to their lives - then it will go in one ear and out of the other. And the story doesn't have to be complicated - a story is, after all, just a beginning, middle, and an end...maybe a conflict or two. But telling the story - showing how the technology or what you are presenting applies to real people in the real world - is critical to getting your point across.\n\nIt's so critical that some of the best tech talks are only stories. In the \"Reflections\" Keynote at KubeCon CloudNativeCon 2019, Kelsey Hightower - one of the most respected tech speakers known for his impressive and fun demos - didn't even appear to bring a laptop on stage. Speaking from the heart, Kelsey tells the stories of the early days of Kubernetes, of showing inclusion, of practicing intentional inclusion. And with those few simple but powerful stories, the audience is captivated and learns more in 15 minutes about what it means to be an inclusive open source community than they would have with hours of slides of fancy graphics and data.\n\n### More from Kelsey\n\n- [Kubernetes and the Path to Serverless](https://www.youtube.com/watch?v=oNa3xK2GFKY)\n- [Kelsey Hightower's Best Live Demo Yet](https://www.youtube.com/watch?v=U6SfRPwTKqo)\n- [TechExplorers: Kelsey Hightower](https://www.youtube.com/watch?v=9OHNejqXOoo)\n- [HashiConf 2017 Keynote](https://www.youtube.com/watch?v=v77FFbQwC6E)\n\n## Passion\n\n**[Zebras All the Way Down](https://www.youtube.com/watch?v=fE2KDzZaxvE): Bryan Cantrill, Uptime 2017**\n\nStories will help you make your talk more personal - both for you and the audience. But that won't carry much weight for long if you don't have passion for the stories and how they apply to the problem and solution you're trying to present. For the audience to stay engaged throughout the talk, they need to care about what you are talking about. And if it isn't clear from your speech, word choice, and energy that you are passionate about your topic, there is no way your audience will come along with you and care about what you have to say.\n\nNo one will ever accuse Bryan Cantrill of not being passionate. And in his talk \"Zebras All the Way Down,\" he brings that passion to advocating for one's own healthcare to understand at a deep level how our systems are impacted by the various layers of software. And that includes a lot of software we don't think about like that below the operating system. Turning a personal story about his physician father and his sister who had a rare condition into the way to think about solving hard debugging problems, Bryan brings the audience along. He makes you care about what he has to say...even if what he's talking about is far removed from your daily work.\n\n### More from Bryan\n\n- [Debugging Under Fire: Keep your Head when Systems have Lost their Mind](https://www.youtube.com/watch?v=30jNsCVLpAE)\n\n- [Corporate Open Source Anti-patterns](https://www.youtube.com/watch?v=Pm8P4oCIY3g)\n\n- [Fork Yeah! The Rise and Development of illumos](https://www.youtube.com/watch?v=-zRN7XLCRhc)\n\n## Connection to the audience\n\n**[Why Open Source Firmware is Important](https://www.youtube.com/watch?v=mUTx61t443A): Jessie Frazelle, GOTO 2019**\n\nOnce you've brought your whole self to the talk - your stories and your passion - you still need to ensure your audience will be engaged and want to hear about those things from you. To do that, you have to build a connection with your audience. The way to do this may seem simple on the surface, but it does actually take some effort. You need to understand at least two things about your audience: who they are and why they showed up to your talk.\n\nFirst - who is your audience? You have to understand who they are - what are their roles professionally? What is their experience like personally? What makes them passionate, and what are their stories? Understanding your audience will help you shape your talk to match their interests with your passions - a surefire method for success.\n\nSecond - why did they show up to your talk? You've already won a little bit here - they came to the conference or meetup, they saw your abstract and maybe a little bit about you, and chose to come to hear what you had to say. That should give you confidence that the audience wants you to succeed just as much as you want. Think for yourself: have you ever shown up to a tech talk hoping the speaker would bomb? Probably not. So that's half of the battle won already, but you can't take it for granted. They showed up expecting to learn or get something out of your talk. You need to think about how they apply what they want out of it and then deliver.\n\nA great example is Jessie Frazelle's talk at GOTO Chicago in 2019 on \"Open Source Firmware.\" On the surface, it might not seem like a great example - Jessie even has a disclaimer at the beginning of the talk. She's \"forcing\" an audience of software engineers to get a few rings lower than they are comfortable - down into the  UEFI kernel, management engine, and other low-level firmware pieces. But Jessie's passion for this part of the stack and showing the audience how it directly applies to how we all build software with many abstraction layers above the firmware is offered throughout the talk. Jessie convinces the audience to care about the software turtles all the way down. Along the way, she teaches about the stack of code we don't know about...and the rings of trust below \"0\" and the kernel.\n\n### More from Jessie\n\n- [Breaking Containers: Chaos Engineering and Kubernetes](https://www.youtube.com/watch?v=1hhVS4pdrrk)\n\n- [Benefits of isolation provided by containers](https://www.youtube.com/watch?v=fKDupfKu_Mw)\n\n- [Container Hacks and Fun Images](https://www.youtube.com/watch?v=cYsVvV1aVss)\n\n## Balance\n\n**[The Art of Code](https://www.youtube.com/watch?v=6avJHaC3C2U): Dylan Beattie, NDC London 2020**\n\nOnce you've got your audience bought in - and know what you're going to tell them and why - you've got to write the talk. Until now, not much has been focused on that. There are a lot of methods out there for outlining, writing, and structuring your speech. Far too many, in fact, for me to get into here. And that's not my goal - there is a one-size-fits-all method for creating a great tech talk. Much like many technical problems, the answer to \"how should I structure this thing\" is \"it depends.\" However, the best tech talks I've ever seen strike a balance - a balance of the tech and the stories, learning and entertainment, questions and answers.\n\nThis balance boils down to balancing the \"three S's of a great tech talk\":\n\n_Style_\n\n_Substance_\n\n_Stories_\n\nEven though one of these S's (stories) repeats one of our early items, I think that only serves to express how important it is to a great talk. You must tell a story. But unless you're giving a keynote at a conference where you're the most respected person in the room (shoutout to Kelsey Hightower), the stories won't always be the whole package. In most tech talks, folks are coming to learn something about technology or how humans interact with technology - so bringing substance is essential. You have to prove you know what you're talking about and that it matters to your audience.\n\nBut, as we've discussed already, that substance can't be just dry numbers on a chart or some other way to present cold unconnected data. While that is often the business of any serious engineering endeavor, a presentation on stage is more than that. You must also bring style - charisma, humor, fun visuals, and passion - all ways you can make sure style is balanced with the substance of your talk. Sure, some have a lot more style than others - but those with no style are the ones that are quickly forgotten.\n\nPerhaps one of the best speakers when it comes to this balance is Dylan Beattie. In \"The Art of Code,\" Dylan takes us through various elements - from maths to retro computing to programming Fizz Buzz as an 80's hair ballad, complete with guitar playing and singing from Dylan. However, Dylan balances the exciting talk style with the stories he wants the audience to hear. And he sprinkles in the substance about how we as technologists have a responsibility to the world...and need to not take ourselves too seriously.\n\n### More from Dylan\n\n- [Fractals, Factories and Fast Food](https://www.youtube.com/watch?v=Vs1DWYrw2Ps)\n\n- [Architecture: The Stuff That's Hard to Change](https://www.youtube.com/watch?v=3LtQWxhqjqI)\n\n- [Ctrl-Alt-Del: Learning to Love Legacy Code](https://www.youtube.com/watch?v=wPjHuvulivM)\n\n## Call to Action\n\n**[Why work doesn't happen at work](https://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work/transcript?language=en): Jason Fried, TEDx Midwest**\n\nThis last key - a meaningful call to action - is the one I struggled the most to name. As they say, there are only two hard things in software development: naming things, cache invalidation, and off-by-one errors. The connotation behind \"call to action\" may come off at first as sounding too \"sales and marketing\" like many software engineers. But that connotation does not impact the importance of a call to action. Using the strictest definition of the word, it is a vital part of your talk.\n\nAs we discussed, your audience came to your talk, hoping for you to succeed. They've now sat through you talking \"at\" them for 15, 25, 45 minutes or more. So the call to action is not for you - it's not self-serving like a sales pitch. Your call to action at the end of your talk should be your gift to the audience. It should be about them, not about you. It should give them concrete next steps they can take to positively impact what you were talking about in their own lives, organization, or world. This call to action is what you want the audience to remember, and the best tech talks are also the most memorable.\n\nAnd they don't have to be about tech at all even. In Jason Fried's TEDx talk \"Why work doesn't happen at work,\" Jason presents the main ideas around how we've become accustomed to working together are broken...and, more importantly, offers concrete ways to fix them. And while those calls to action are simple, they also go to the heart of Jason's story and passion: making it less crazy at work by freeing up people to do their best work with time and space.\n\n## What's next?\n\nSo, given that you've come this far, I hope I've shared my passion for great tech talks with you. Hopefully, that passion is shared, and you've found a new way of thinking about your own talks. So what is my gift to you for having come this far? Well, it's going to sound like an oversimplified call to action, but I'm telling you it's exactly what you should do:\n\n**Go give a talk!**\n\nYour unique stories are valuable. You are passionate about things that others should care more about. There are audiences out there - in meetups, small events, or large conferences  - that want to hear what you have to say and will be rooting for you when you get up in front of them. All that's left is to strike a balance between those stories and substance with some of your own personal style to make it exciting and engaging.\n\nSo go forth, and write that talk. I'm confident you can do it.\n",[831,268,852],"open source",{"slug":854,"featured":6,"template":681},"what-makes-a-great-tech-talk","content:en-us:blog:what-makes-a-great-tech-talk.yml","What Makes A Great Tech Talk","en-us/blog/what-makes-a-great-tech-talk.yml","en-us/blog/what-makes-a-great-tech-talk",{"_path":860,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":861,"content":867,"config":874,"_id":876,"_type":17,"title":877,"_source":18,"_file":878,"_stem":879,"_extension":21},"/en-us/blog/jobs-to-be-done-interviews",{"title":862,"description":863,"ogTitle":862,"ogDescription":863,"noIndex":6,"ogImage":864,"ogUrl":865,"ogSiteName":667,"ogType":668,"canonicalUrls":865,"schema":866},"How we use the Jobs-To-Be-Done Framework to rethink user workflow","We experimented with our methodology and this is what we learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670074/Blog/Hero%20Images/jobs-to-be-done.jpg","https://about.gitlab.com/blog/jobs-to-be-done-interviews","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we use the Jobs-To-Be-Done Framework to rethink user workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erika Feldman\"},{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2022-09-07\",\n      }",{"title":862,"description":863,"authors":868,"heroImage":864,"date":870,"body":871,"category":14,"tags":872},[869,697],"Erika Feldman","2022-09-07","\n\nThe past few years exposed us to the heights of unpredictability, and a lot of time was spent on Zoom. The pandemic showed us that planning is not enough for an organization to survive in difficult times. Companies need to be flexible enough to innovate in accordance with altered workflows if they wish to sustain and support market use cases as they evolve. Innovating and iterating at the speed of DevOps requires designers and researchers to look at the user workflow differently, outside of the content of the UI. To understand our users and how their work has changed, we zoomed out our perspective by asking users their key tasks and goals at the Stage level - instead of presenting them with a UI to work within. \n\nAt GitLab, we use the Jobs-To-Be-Done ([JTBD](/handbook/product/ux/jobs-to-be-done/)) framework to always keep room for innovation in our approach to research and customer inquiry. We believe that our users do not purchase our product because of the features and capabilities we build into it, but for what it helps them accomplish in their workflows. To capture more macro-changes in user workflows through this research, we adjusted the level of the JTBD framework to focus on the entire code integration, verification, and deployment process.  \n\nWhen we are too focused on the features and solutions we work on day after day, our frame becomes myopic, our sense of progress becomes skewed, and [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) rears its head. Our product then reflects our organizational structure rather than the user's workflow. The JTBD framework helps us be more aware of opportunities in the competitive arena by allowing us to understand the goal of the products at a more fundamental level that can easily be missed by a superficial frame.   \n\n## Pipeline execution JTBDs\nThe [Pipeline Execution group](/handbook/engineering/development/ops/verify/pipeline-execution/) in GitLab is responsible for supporting the functionalities with respect to Continuous Integration use cases. GitLab [CI/CD](/topics/ci-cd/) offerings have come a long way over the years. This realization triggered us to start re-examining the vision we have for the Stage Group earlier this year. We wanted to make sure that we’re leaving no stone unturned. And what better place to start than revisiting our JTBDs?\n\n## Designing the research\nTo avoid cutting any corners, we decided to keep our confidence in the product and our biases aside and speak with users without talking to them about our UI. A privilege of working at GitLab is having a well-documented handbook that is a living and evolving single source of truth. We looked at the [documented process](/handbook/product/ux/jobs-to-be-done/mapping-jobs-to-be-done/) and, at the same time, made notes on our assumption around what might not have gone right the previous time we did this exercise. These are the areas we felt we could improve on:\n\n1. Making interviews more collaborative\n2. Documenting the findings without bias\n3. Helping participants tell us about the fundamental workflow level, and not at a utility level\n\n## The interview template\nWe co-created an interview deck with users to help us codify their workflows. After an introduction to the session to set them at ease, we showed them a relatively blank canvas with different stages of their workflow written on the top of the slide. We started with our GitLab Stages, falling into the Conway conunmdrum. At the end of our inquiry and co-creation of the deck templates that we use across participants, we had the following six steps: \n\n1. Define - How code is defined and how it will be integrated and verified\n1. Locate - How team members gets to know about Infrastructure-as-Code frameworks and how they should be used\n1. Execute - How the processes and frameworks are ultimately executed\n1. Monitor - How performance is monitored\n1. Modify  - How teams change existing processes or existing code\n1. Secure, Deploy, and Debrief - How teams securely release changes to production and learn from their most recent process\n\nSpeaking with users for this research activity didn't just help us identify new JTBDs, but also validate some of the [previously listed ones](/handbook/engineering/development/ops/verify/pipeline-execution/jtbd/). The same research also helped us identify opportunities related to learnability of the tool, post code-integration monitoring capabilities and discoverability of the code-verification practices set up by organization on GitLab for their teams.\n\nUsers are at the focal point of our decisons at GitLab and going forward we will continue to improve our research methods and communication practices to capture the insights in the purest form. \n\n",[678,677,873],"product",{"slug":875,"featured":6,"template":681},"jobs-to-be-done-interviews","content:en-us:blog:jobs-to-be-done-interviews.yml","Jobs To Be Done Interviews","en-us/blog/jobs-to-be-done-interviews.yml","en-us/blog/jobs-to-be-done-interviews",{"_path":881,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":882,"content":888,"config":895,"_id":897,"_type":17,"title":898,"_source":18,"_file":899,"_stem":900,"_extension":21},"/en-us/blog/the-changing-roles-in-devsecops",{"title":883,"description":884,"ogTitle":883,"ogDescription":884,"noIndex":6,"ogImage":885,"ogUrl":886,"ogSiteName":667,"ogType":668,"canonicalUrls":886,"schema":887},"Why - and how - DevOps roles are changing","Our 2022 Global DevSecOps Survey finds developers in ops and security while operations is everywhere.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664007/Blog/Hero%20Images/devopsroles.jpg","https://about.gitlab.com/blog/the-changing-roles-in-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why - and how - DevOps roles are changing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-08-31\",\n      }",{"title":883,"description":884,"authors":889,"heroImage":885,"date":891,"body":892,"category":14,"tags":893},[890],"Valerie Silverthorne","2022-08-31","\nFor three years, developers, security team members, and operations professionals have suggested to us in our annual surveys that their responsibilities were shifting. But this year that “shift” became a tidal wave of change - and that change is towards [DevSecOps](/topics/devsecops/).\n\nIn our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/), more than 5,000 practitioners shared details of DevOps roles in a state of flux: devs taking on ops and security tasks, security working hand-in-hand with dev teams, and ops wearing an improbable number of hats. \n\nThese are big changes, but surprisingly not chaotic ones. In fact, at a time of great technical and macroeconomic upheaval, the evolution of DevOps jobs and responsibilities seems to be designed to bring teams more tightly together. DevOps is more than 14 years old at this point – an argument could be made that [true collaboration](/blog/collaboration-communication-best-practices/) is finally underway. \n\nWhatever is at play, it’s clear substantive changes are happening. Here’s what our respondents told us about their new responsibilities.\n\n## DIY and developers\n\nToday’s developers are literally DIYing all the (ops) things. This year, 38% reported instrumenting code they’ve written for production monitoring, up 12% from 2021 and more than double the percentage in 2020. The same percentage of devs monitor and respond to the infrastructure, up 13% from last year, and 36% are “on call” for app-in-production alerts. Some devs are now authoring runbooks for apps in production and even serving as a point-of-contact if something is escalated.\n\nThey’re also spending a lot more time on toolchains. Nearly 40% spend between one-quarter and one-half of their time [maintaining or integrating toolchains](/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer/) (more than double last year’s percentage), while a full third of devs spend between half and **all** of their time on this task.\n\nAnd, in any time left over, devs are digging into security, so much so that 53% said they are fully responsible for security in their organizations.\n\nAt the same time, devs are also opting out of tasks that have long been in their wheelhouse, including testing, manual testing, code review, documenting code changes, and planning.\n\n## Security is a team sport\n\nNo longer a siloed group, security team members are literally rolling up their sleeves and joining in. Almost 29% of those surveyed said they’re now part of a cross-functional team and 35% are more involved with teams and “hands on” with DevOps projects, an 11-point jump over 2021.\n\nFor the first time ever, 7% of security team respondents said they have more influence on engineering decisions; a small percentage, but it’s a start for a group traditionally viewed as not part of the “team.”\n\n## Nimble ops pros\n\nWhile devs are busy with what have been traditional ops roles, ops pros are off-roading with responsibilities not really seen in DevOps teams before. For the past few years, ops has reported splitting time between managing infrastructure and managing the cloud, and that didn’t change dramatically in 2022. But when they’re not juggling the cloud and infrastructure, ops is taking on a number of new challenges, including DevOps coaching, responsibility for automation, overseeing [all compliance efforts](/blog/the-importance-of-compliance-in-devops/), and [platform engineering](/topics/devops/what-is-a-devops-platform-engineer/). \n\nAnd, as if that isn’t enough, 48% of ops pros said they feel fully responsible for security in their organizations.\n\nWant to know more about how DevOps roles are changing? Read our [2022 Global DevSecOps Survey](/developer-survey/).\n",[722,806,831,894],"security",{"slug":896,"featured":6,"template":681},"the-changing-roles-in-devsecops","content:en-us:blog:the-changing-roles-in-devsecops.yml","The Changing Roles In Devsecops","en-us/blog/the-changing-roles-in-devsecops.yml","en-us/blog/the-changing-roles-in-devsecops",{"_path":902,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":903,"content":909,"config":915,"_id":917,"_type":17,"title":918,"_source":18,"_file":919,"_stem":920,"_extension":21},"/en-us/blog/open-core-is-worse-than-plugins",{"title":904,"description":905,"ogTitle":904,"ogDescription":905,"noIndex":6,"ogImage":906,"ogUrl":907,"ogSiteName":667,"ogType":668,"canonicalUrls":907,"schema":908},"Open core is worse than plugins... and that’s why it’s better","Learn why GitLab's decision to opt for the \"worse\" choice has been a great success.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681581/Blog/Hero%20Images/gitlab-linux-ibm-z-redhat-openshift.jpg","https://about.gitlab.com/blog/open-core-is-worse-than-plugins","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open core is worse than plugins... and that’s why it’s better\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2022-07-14\",\n      }",{"title":904,"description":905,"authors":910,"heroImage":906,"date":912,"body":913,"category":14,"tags":914},[911],"Sid Sijbrandij","2022-07-14","\nOpen core is obviously a horrible approach to creating a product with an ecosystem of extensions and integrations: There are no proper protocols and interfaces. Instead, anyone can just add their integration to the code base and even adjust said code base to their needs if it doesn’t fit.\n\nSo why have we been using the “Worse” approach at GitLab for many years now, with great success? Because [Worse is Better](https://www.dreamsongs.com/RiseOfWorseIsBetter.html) (a term conceived by [Richard P. Gabriel](https://en.wikipedia.org/wiki/Richard_P._Gabriel)). Of course, it turns out that “Worse” is actually even better than Worse is Better suggested.\n\nGabriel’s [original argument](https://www.dreamsongs.com/RiseOfWorseIsBetter.html) was that (slightly) intrinsically worse but simpler and easier to implement software has better survival characteristics than better-designed, more complex software, and thus will consistently win in the marketplace.\n\nAt GitLab, we have found that this is basically true, which is why we, for example, favor “boring technology,” even if it might not be the best possible solution for a given scenario. But this doesn’t tell the whole story: It turns out that such software is not just more successful, it also ends up being qualitatively better in the end.\n\n## Worse is even better\n\nIt is important to note that Gabriel’s original argument was not that **bad** software wins out. In fact, both his “worse” and his “better” have the same qualities:\n\n1. Simplicity, of interface and implementation\n2. Correctness\n3. Consistency\n4. Completeness\n\nHowever, his “worse” and his “better” have slightly different weights for the value placed on these characteristics, with the (worse) New Jersey school favoring simplicity of implementation over simplicity of interface, whereas the (better) “MIT” school favors simplicity of interface, even at the cost of a more complex implementation.\n\nIf a simple interface can be achieved with a simple implementation, both schools agree, the difference comes when there are tradeoffs to be made.\n\nWhat makes worse even better, and what Gabriel didn’t take into account even in later [versions](https://www.dreamsongs.com/WorseIsBetter.html), is the tremendous value of feedback loops. Being early doesn’t just let the New Jersey approach win in the marketplace, it also allows it to collect feedback much, much earlier and much more quickly than the MIT approach.\n\nPaul MacCready won the first [Kremer prize](https://en.wikipedia.org/wiki/Kremer_prize) not by initially setting out to build the best human-powered aircraft, but by building the one that was easiest to repair in order to gather feedback more quickly. While other teams took a year or more to recover from a crash, his plane sometimes flew again the same day. And so it was exactly this willingness to lose sight of the prize that resulted in him winning it.\n\nIn much the same way, it is these quick feedback loops that a “worse” approach enables, started much earlier, that eventually lead to a better product.\n\n## The problem with plugins\n\nAt least since the success of Photoshop, a proper plugin interface has been recognized as _The Right Way_ to make software both more compelling for users and less easy to leave behind by creating a third-party ecosystem that provides useful functionality without the vendor having to provide all of that functionality themselves.\n\nIt was so successful that systems like OpenDoc took the idea further to be just a set of plugins, with no real hosting application. None of these systems succeeded in the marketplace.\n\nOne of the reasons is that good plugin interfaces are not just hard, but downright fiendishly difficult to develop. The basic difficulty is that it is hard to get the balance right: what to expose, what to keep hidden, how to provide functionality. But that’s not the fiendish part.\n\nThe fiendishly difficult part of plugin API development is that the very things you need to do to handle the difficulties make the task even harder: You need to design more carefully, you need to make interfaces stable, you can only iterate them slowly.\n\nIn short: You face a chicken-and-egg problem of premature abstraction. In order to make a good plugin API, you need to see it being used, but in order to see how it is being used, you need to first have it. This dynamic delays initial availability and makes feedback cycles slower.\n\nSoftware is not the only domain facing this problem. Parks, for example, often have official paths that don’t match where people actually want to go. One group of landscape architects solved this by doing less: They didn’t put in any walkways in a park they had created. Instead, they waited for trails to materialize as people walked where they needed to walk. Only after those trails had materialized did they pave them, making them official.\n\nLast but not least, a plugin interface means that the final product the user sees, consisting of both the core application and all the plugins, is not as well-integrated as it could be. The value proposition of “here is a box with tools, have fun!” sounds a lot more enticing to developers than it does to end users, even when those tools are, by themselves, best of breed.\n\n## Open core\n\nOpen core, on the other hand, sounds like exactly the wrong approach, certainly from a software engineering point of view, as there are no defined black-box boundaries, but also from a business point of view as there doesn’t seem to be an actual mutually reinforcing ecosystem.\n\nHowever, the open core approach is great for end users, both for adopters who just want to use it and also adapters who need to tailor the system to their use case. And in the end, it is the end users that count.\n\nFor adapters, the system is immediately hackable. There is no need to wait for the vendor to provide a plugin interface in the first place, and no need to wait more for the vendor to make that plugin interface provide the functionality needed for a particular application some time in the future, if ever. Even if changes to the core application are required, this is at least possible.\n\nSince there is more adaptation activity happening sooner, the system becomes better at accommodating adaptation needs, and a virtuous cycle ensues.\n\nFor adopters, the benefits are multifold: First, the system gets more functionality more quickly, which is always good. Almost more importantly, this functionality is integrated by the vendor and provided as an integrated whole. There is a reason single-vendor office suites succeeded where OpenDoc’s toolbox approach failed.\n\nThat said, an open core approach does require solid engineering, a good architectural base, and ongoing vigilance. As [explained earlier](https://thenewstack.io/why-were-sticking-with-ruby-on-rails-at-gitlab/), we believe that Ruby on Rails provided us with a good starting point to build GitLab as a solid modular monolith, both approachable and well-structured. With that as a starting point, good design is encouraged by example, rather than being enforced by strict API boundary. Enforcement, on the other hand, comes in a more human form as pull requests are considered, shaped, and approved or rejected.\n\nSo boundaries still exist, but instead of being brick walls to crash against, they are low fences that are noticeably present, but can be stepped over if needed.\n\nAnd although these low fences are considered “worse” than the brick walls we are used to, they actually lead to better outcomes for everybody involved.\n",[806,852,268],{"slug":916,"featured":6,"template":681},"open-core-is-worse-than-plugins","content:en-us:blog:open-core-is-worse-than-plugins.yml","Open Core Is Worse Than Plugins","en-us/blog/open-core-is-worse-than-plugins.yml","en-us/blog/open-core-is-worse-than-plugins",{"_path":922,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":923,"content":929,"config":936,"_id":938,"_type":17,"title":939,"_source":18,"_file":940,"_stem":941,"_extension":21},"/en-us/blog/how-to-leverage-modern-software-testing-skills-in-devops",{"title":924,"description":925,"ogTitle":924,"ogDescription":925,"noIndex":6,"ogImage":926,"ogUrl":927,"ogSiteName":667,"ogType":668,"canonicalUrls":927,"schema":928},"How to leverage modern software testing skills in DevOps","Test automation is finally happening, but do teams have the necessary modern software testing skills? Here's what you need to know","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668307/Blog/Hero%20Images/test-automation-devops.jpg","https://about.gitlab.com/blog/how-to-leverage-modern-software-testing-skills-in-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to leverage modern software testing skills in DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lauren Minning\"}],\n        \"datePublished\": \"2022-07-05\",\n      }",{"title":924,"description":925,"authors":930,"heroImage":926,"date":932,"body":933,"category":14,"tags":934},[931],"Lauren Minning","2022-07-05","\nTesting is a critical step in the software development lifecycle but also the part of the process most DevOps teams trip over. The solution — test automation — has been talked about for years but has been far easier said than done. However, with new technologies on the rise, test automation is taking off. DevOps teams need to be prepared with modern software testing skills. Here's how to get started.\n\n## The benefits of automated software testing\n\nIn [GitLab's 2021 Global DevSecOps Survey](/developer-survey/) of over 4,000 developers, security professionals, and operations team members, respondents agreed on one universal truth: Software testing is the biggest reason why development is delayed. \n\nIt’s critical to get software testing right because it’s financially disastrous to get it wrong. How much money do software mistakes add up to? Somewhere in the trillions. Yes, with a “t.”\n\n[DevOps.com](https://devops.com/this-is-not-just-a-test-devops-and-the-need-to-automate/) reported that software failures in companies’ operations systems cost a total of almost $1.6 trillion in the U.S. in 2019 alone. \n\nBut testing has traditionally been difficult to do efficiently and not particularly popular with developers. The solution? Test automation combined with modern software testing skills.\n\n## It’s a hands-on start\n\nDevOps teams looking to up their test game need to take a step back... into _manual_ testing.\n\n(The irony is not lost on us.)\n\nA manual testing mindset can actually improve all facets of automated software testing. As devs perform basic tests on their code as it’s being written, channeling their inner manual tester can be helpful. Whether it’s looking at the requirements again or running failed fixes *one more time*, that attention to detail should be brought into how automated test cases are built and executed. \n\n## Take the modern view\n\nOnce developers have incorporated some old-school habits into their test cases, it’s time to consider some fresh perspectives, up to and including a deep understanding of the organization’s goals and objectives.\n\nAccording to [Modern Testing](https://www.moderntesting.org), there are key principles of modern testing that every developer needs to be aware of for successful testing at any stage:\n\n- Job one is to make the business better. \n- Rely on trusted resources like [Lean Thinking](https://www.lean.org/explore-lean/what-is-lean/) and the [Theory of Constraints](https://www.leanproduction.com/theory-of-constraints/#:~:text=The%20Theory%20of%20Constraints%20is,referred%20to%20as%20a%20bottleneck).\n- Fail fast but focus on success.\n- Always be the customer when testing.\n- Do data-driven work. \n- Testers are evangelists. \n\n## Get certified\n\nAs the saying goes, every little bit helps. Though it is not required, a training program or certification course in software testing can enhance team capabilities.\n\nIf there's interest in this option, research courses online that might fit. From beginners to experienced testers, there’s something for everyone.\n\nNot sure where to start? Teams can explore the International Software Testing Qualifications Board (ISTQB) [Foundation Level Certification for CTFL certification](https://astqb.org/certifications/foundation-level-certification/). This is required before taking any other certifications (see [the full list of ISTQB prerequisites](https://astqb.org/certifications/#prerequisites)). After CTFL, there are many interesting certification options. \n\nThe [American Software Qualifications Board](https://astqb.org/certifications/), which offers the ISTQB certifications, is another great resource and has a helpful [Software Testing Career Road Map](https://astqb.org/benefits/road-map/). \n\n## Embrace new technologies\n\n[Artificial intelligence and machine learning](/blog/ai-in-software-development/) are at the core of test automation, so a thorough understanding of the technologies is a key modern software testing skill to have onboard. If AI/ML is already in use, ask to shadow or “apprentice” those working with it. Organize a Q&A for the DevOps team with an expert, and pull together a suggested reading list. The more understanding and experience, the easier it will be to get the most out of an ML bot.\n\n## Dive into the metrics\n\nAutomation is not only going to lead to faster releases, it's going to make it possible to do even more testing, which is great but, of course, also means there will be even _more_ data than ever before. It can be easy to feel overwhelmed by it all, so it's critical DevOps teams decide and [focus on the metrics that matter most](/blog/gitlab-top-devops-tooling-metrics-and-targets/) to the organization. It could be pipeline stability, time to first failure, or the \"age\" of open bugs... but whatever they are, they're important to continue to measure and understand.\n\n## The bottom line on modern software testing skills\n\nTesters, who’ve often been overlooked when it comes to DevOps fame and glory, have an opportunity to reinvent themselves and their QA roles if they can take advantage of modern software testing skills. It’s a critical step in the process that is finally getting some much needed attention and tech investment, so it makes sense to take it seriously.\n",[806,935,894],"testing",{"slug":937,"featured":6,"template":681},"how-to-leverage-modern-software-testing-skills-in-devops","content:en-us:blog:how-to-leverage-modern-software-testing-skills-in-devops.yml","How To Leverage Modern Software Testing Skills In Devops","en-us/blog/how-to-leverage-modern-software-testing-skills-in-devops.yml","en-us/blog/how-to-leverage-modern-software-testing-skills-in-devops",{"_path":943,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":944,"content":950,"config":954,"_id":956,"_type":17,"title":957,"_source":18,"_file":958,"_stem":959,"_extension":21},"/en-us/blog/two-sizes-fit-most-postgresql-and-clickhouse",{"title":945,"description":946,"ogTitle":945,"ogDescription":946,"noIndex":6,"ogImage":947,"ogUrl":948,"ogSiteName":667,"ogType":668,"canonicalUrls":948,"schema":949},"Two sizes fit most: PostgreSQL and Clickhouse","Relational databases are not in decline. Here's why.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/two-sizes-fit-most-postgresql-and-clickhouse","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Two sizes fit most: PostgreSQL and Clickhouse\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2022-04-29\",\n      }",{"title":945,"description":946,"authors":951,"heroImage":947,"date":952,"body":953,"category":14},[911],"2022-04-29","\nSince the introduction of [System R](https://en.wikipedia.org/wiki/IBM_System_R_) in 1974, relational databases in general, and SQL databases in particular, have risen to become the dominant approach to data persistence in the industry, and have maintained that dominance despite various significant challengers. Though some have rumored the death and decline of traditional relational databases, PostgreSQL has turned out to be an improvement on its predecessors, as well as its supposed successors. \n\nIn fact, the open-source MySQL database was so ubiquitous that it became part of the eponymous LAMP stack (Linux, Apache, MySQL, Perl) that dominated early web development.\n\nThe one big exception to this trend is OLAP, where specialized techniques that can drastically improve the performance of certain workloads have met with use-cases that actually require these techniques, with new contenders such as Clickhouse enabling qualitatively different approaches to analytics.\n\n## One size does not fit all\n\nAs often happens when a technology becomes dominant, it gets applied unthinkingly even when it may not actually be appropriate, and so all kinds of data was and is being pushed into general-purpose relational databases.\nExtreme examples could be found, such as developers creating remote Oracle databases for data sets with a total of 5 small elements (not columns, pieces of data) or Apple pushing their system logs into an SQLite database (a mistake they later corrected).\n\nBind10 development started under the premise to solve scaling issues with Bind9 as DNS nameserver, using SQLite as backend. The DNS development was discontinued by ISC in 2014, and the OSS project [Bundy](https://github.com/bundy-dns/bundy) remains inactive. PowerDNS focussed on [performance scaling with MySQL/PostgreSQL](https://doc.powerdns.com/authoritative/performance.html) early.\n\nIn 2005, Michael Stonebraker, database researcher behind Ingres and later PostgreSQL, together with Uğur Çetintemel, penned a paper [“One Size Fits All”: An Idea Whose Time Has Come and Gone](http://cs.brown.edu/%7Eugur/fits_all.pdf) arguing that this had gone too far too long and backing up that argument with [benchmark results](http://nms.csail.mit.edu/%7Estavros/pubs/osfa.pdf).\n\nIn short, there were many workloads outside of the core application of databases, Online Transaction Processing (OLTP), where the general database architectures were outclassed sufficiently that it did not make sense to use them.\n\nIt should be noted that Stonebraker and Çetintemel argued not against relational databases or SQL, but against a specific architecture descendent from the original System R and Ingres systems that were and still are being used by most general purpose database systems.\n\nThis architecture has the following features:\n\n- Disk and row-oriented storage and indexing structures\n- Multithreading to hide latency\n- Locking-based concurrency control mechanisms\n- Log-based recovery\n\nIn addition to special-purpose text indexing, the primary use-case for which the traditional architecture was proving inadequate was data warehouses, for which column stores were proving 10-100x more efficient than the traditional row stores.\n\n## Clickhouse\n\nThe prediction that OLAP database engines would split off from mainstream databases has largely come to pass in the industry, with OLAP databases now being a significant category in its own right, with vertica, the commercial offshot of the original cstore discussed in the paper, one of the major players.\n\nThe practical advantages of these databases for analytical work are, as predicted, substantial enough that having a separate database engine is warranted.\n\nOr even necessary, as was the case for Yandex's clickhouse OLAP database, recently spun out into a startup that just received a US $250m series B.\nThe clickhouse developers wanted to have realtime analytics, but do so not with customized data structures, as is customary in this application domain, but instead with a generalized database engine queryable with SQL.\nOf course, there is a reason this is usually done with customised data structures: doing so with a generalized database engine was considered impossible, partly because it was impossible with existing engines.\nAs is often the case, impossible turns out to \"just\" be a lot of work and some brilliant engineering, and after a few years the developers had what they had sought after: a database engine specialised for OLAP, but general enough, queryiable via SQL and still capable of real-time analytics.\n\nBoth the engineering and the benchmark results are impressive, including our own [tests](https://gitlab.com/gitlab-org/incubation-engineering/apm/apm/-/issues/4#results) [(video0)](https://www.youtube.com/watch?v=cMdQsxolcqc).\n\nIt is significantly faster than PostgreSQL extensions such as CitusDB or Timescale DB, and reportedly also faster than vertica.\n\n## The end of an era?\n\nThe 2005 paper left OLTP as the only area where the traditional (disk-based, row-oriented, multi-threaded) architecture was viable. Two years later, he published [The end of an Architectural Era (It’s Time for a Complete Rewrite)](http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf), where he argues that even for OLTP, the existing engines can be surpassed by more than a factor of ten.\n\nThe key insight was that long held assumptions about the relative performance of different components were no longer accurate, and so it turns out that, according to Stonbraker et al, around 90% of the performance budget of the database engine is used not for actually processing data, but for overheads such as buffer management and locking.\nSo if we could remove those overheads, we could make a database engine that is 10x faster than existing ones. Achieving these gains would require building a database engine that is single-threaded and works in main memory, a radical departure from the existing architecture.\n\nBut not an unprecedented one. Main memory capacities have improved many more than a million times since those early databases were designed, so many workloads that used to require persistent storage due to size can now be handled in memory.\n\nFor example, even in the early 2000s Yahoo had a policy that any dataset less than 2GB should live in RAM, not on disk. A little later, [EventPoster](https://www.martinfowler.com/bliki/EventPoster.html) architectures, [In-Process REST](https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11) and the [LMAX](https://martinfowler.com/articles/lmax.html) exchange with the [Disruptor](https://lmax-exchange.github.io/disruptor/) pattern demonstrated that moving from complex multi-threaded, disk-based systems to single threaded RAM based architectures could yield tremendous benefits in terms of simplicity, reliability and performance.\n\nAnd that was with 32 bit computing. Nowadays, we can get single servers with tens of terabytes of memory configured for us at the click of a mouse (with a subsequent bill...), so the workloads we can keep in RAM are quite substantial.\n\nStonebraker and his team built [H-Store](https://hstore.cs.brown.edu), an academic prototype, and [voltdb](https://en.wikipedia.org/wiki/VoltDB), a commercial product with the associated startup.\n\n## It hasn't taken the database world by storm.\n\nSurprisingly, that isn't because it doesn't work as intended. From all reports it seems like it does, in fact, work pretty much as advertised and can fulfill its promises.\n\nHowever, those promises came with tradeoffs, and it seems like those tradeoffs aren't ideal for most domains. First, though keeping the entire database in RAM at all times is feasible nowadays, it's probably not a good price/performance tradeoff for most domainst, for which most data is cold.\nSecond, although much higher peak performance is possible, machines are now so fast that the the highest possible peak performance is only necessary for very special domains.\n\nThird, with machines now so fast and performance now usually adequate, performance focus has shifted from peak or even throughput to worst-case latencies. With only a single thread accessing the database, a single long query can stall the entire database and cause extremely bad tail-end latencies. So the fastest database using conventional measures of throughput and peak performance may actually require supreme care not to score worst in the performance metric people now care most about.\nLast not least, requiring a distributed setup, while fine for large installs, creates a high burden for entry-level setups, meaning there is no good on-ramp for this technology.\n\n## PostgreSQL\n\nSo it looks like the era of the conventionally architected OLTP database has not, in fact, ended. Of course, this shouldn't be of too much concern to Professor Stonebraker as the contender coming out on top is still his brainchild, just an earlier one. No, not [Ingres](https://en.wikipedia.org/wiki/Ingres_%28database%29) the early public peer to IBM's System R, but its successor: PostgreSQL.\n\nPostgreSQL is becoming, or has become, the dominant variant of these conventionally architected databases according to both industry sentiment and database [rankings](https://db-engines.com/en/ranking/relational+dbms). Certainly among the engines not beholden to a major database vendor in one way or another.\n\nAt GitLab, we also use PostgreSQL with replication, having [moved away](/blog/removing-mysql-support/) from MySQL in 2019, partly because PostgreSQL actually had features that are important for us, partly because most of our customers were using it anyhow.\n\n## What about NoSQL?\n\nWell, what about it? Although the NoSQL movement of the early 2000s did point to some shortcomings in the dominant databases, the technological prescriptions actually only made sense in very rare circumstances.\nNoSQL isn't really a category, but more a feature of rich database engines like PostgreSQL.\n\nWith increasing compute power and fast storage, high volumes and transaction rates can be handled with traditional database engines, and non-traditional engines can serve relational models using SQL as the interface, see voltdb and Google's Spanner, built on top of Bigtable.\nThere are use-cases where a relational database is not needed and a key-value store is sufficient, or a JSON document store is called for, but for example JSON types in PostgreSQL handle most of these use cases just fine. Even for very specialised use-cases such as text or GIS, modern relational database engines provide direct support.\n",{"slug":955,"featured":6,"template":681},"two-sizes-fit-most-postgresql-and-clickhouse","content:en-us:blog:two-sizes-fit-most-postgresql-and-clickhouse.yml","Two Sizes Fit Most Postgresql And Clickhouse","en-us/blog/two-sizes-fit-most-postgresql-and-clickhouse.yml","en-us/blog/two-sizes-fit-most-postgresql-and-clickhouse",{"_path":961,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":962,"content":968,"config":975,"_id":977,"_type":17,"title":978,"_source":18,"_file":979,"_stem":980,"_extension":21},"/en-us/blog/celebrating-17-years-of-git",{"title":963,"description":964,"ogTitle":963,"ogDescription":964,"noIndex":6,"ogImage":965,"ogUrl":966,"ogSiteName":667,"ogType":668,"canonicalUrls":966,"schema":967},"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":963,"description":964,"authors":969,"heroImage":965,"date":970,"body":971,"category":14,"tags":972},[890],"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",[973,806,974],"git","collaboration",{"slug":976,"featured":6,"template":681},"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":982,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":983,"content":989,"config":996,"_id":998,"_type":17,"title":999,"_source":18,"_file":1000,"_stem":1001,"_extension":21},"/en-us/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development",{"title":984,"description":985,"ogTitle":984,"ogDescription":985,"noIndex":6,"ogImage":986,"ogUrl":987,"ogSiteName":667,"ogType":668,"canonicalUrls":987,"schema":988},"Observability is key to cloud-native transitions and modern application development","Want better visibility into the entire software development lifecycle across environments? Learn how observability can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663993/Blog/Hero%20Images/2018-developer-report-cover.jpg","https://about.gitlab.com/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Observability is key to cloud-native transitions and modern application development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-04-05\",\n      }",{"title":984,"description":985,"authors":990,"heroImage":986,"date":992,"body":993,"category":14,"tags":994},[991],"Sandra Gittlen","2022-04-05","\n\n_This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes._\n\nModern application development requires DevOps teams to be able to collaborate and react to what is happening across the software development lifecycle. Yet, as companies move away from monolithic code bases resident on a server or cluster of virtual machines to cloud-native environments, this goal becomes more difficult to achieve. Cloud-native architectures are more complex with more elements to configure, protect, execute, and measure. To ensure maximum visibility and responsiveness to issues early on in application development and throughout the lifecycle, companies are adopting observability.\n\n## Observability defined\n\nObservability, which [451 Research](https://451research.com/) defines as the collection and analysis of data logs, metrics, and traces, becomes critical and essential with cloud-native technologies and acts as a step beyond monitoring. “The need for such an approach has been brought to the fore by complex, distributed microservices-based applications where the variables are so numerous that it can be impossible to know exactly what metrics need to be collected for the gamut of potential events that could arise,” 451 Research’s “Voice of the Enterprise: DevOps, Organizational Dynamics - Advisory Report” states.\n\n“A need to know what is happening with infrastructure and applications, particularly across hybrid and multi-cloud infrastructure, has driven broad adoption of observability,” according to the report.\n\n## How observability improves cloud-native tech adoption\n\nMore than half of organizations surveyed by 451 Research report either full adoption or some adoption at the team level of cloud-native technologies such as containers, Kubernetes, service mesh, and serverless computing. Another quarter to one-third of respondents plans to deploy cloud-native technologies.\n\nThe challenge is visibility across this new, more complex architecture. While cloud-native technologies offer more flexibility and cost efficiencies for computing resources, they can make it difficult to gain end-to-end visibility of software vulnerabilities, application performance, and quality assessments, and to be able to know where and how to affect change early on in the development lifecycle.\n\nDevOps improvements such as security and analytics are driving the adoption of observability, as is the increased need for compliance. With observability, according to 451 Research’s report, “one can query the data they have and ask any number of questions about a system, and, ideally, get an answer without having to predefine the exact data collected or tagging applied to answer the question.”\n\nIn other words, observability can provide a more flexible toolkit and enable a more active drill-down into what’s actually happening in the development lifecycle. With properly implemented observability, DevOps teams can, in real-time, identify a problem, fix it, benchmark the improvement, and measure it going forward – even in a cloud-native environment that is abstracted from knowledge of underlying systems. Having the ability to observe and measure your end-to-end DevOps efforts can reduce risk and provide greater control of cloud-native environments. \n\nDigital transformation leaders and laggards alike understand the need for observability. Nearly two-thirds of all respondents say they have adopted observability (41%) or have it in discovery/proof of concept (23%). Nearly a third plan to implement it within 12 to 24 months.\n\n“While it is great to see these adoption rates, the ultimate goal is to evolve observability’s inputs into actionable insights that positively impact the business,” says Sebastien Pahl, principal product manager at GitLab and co-founder of observability start-up OpsTrace (which was [acquired by GitLab in 2021](/press/releases/2021-12-14-gitlab-acquires-opstrace-to-expand-its-devops-platform-with-open-source-observability-solution.html)).\n\n## The benefits of observability\n\nIn modern application development, dev, sec, and ops teams share the responsibility of software development and delivery. In mature organizations, DevOps can extend to include stakeholders from compliance, legal, finance, and other departments with a direct stake in value delivery. Observability provides DevOps teams greater flexibility in how to utilize and share data across an organization.\n\nPahl likens observability to a flight crew being able to see, learn from, and react to all the data from instruments and dashboards on a plane as it is flying. “With observability, everyone can look at the same data through a different lens,” he says.\n\nObservability has significant benefits, including the following:\n\n- Developers can add code early in the development lifecycle for events they want to observe.\n\n- DevOps teams can move faster because they know when something is wrong and exactly what is wrong. They can fix problems once and move on.\n\n- Organizations can detect problems before customers do.\n\n- DevOps teams can assign certain alerts to specific individuals or teams so ops teams won’t be burned out responding to general alerts.\n\n- The inputs and metrics written through observability lay the foundation for AI and machine learning.\n\n## Observability and the DevOps Platform\n\nGitLab believes that [observability is foundational](https://opstrace.com/blog/gitlabobsvervabilityui) to a DevOps platform, and will make the capability available to all GitLab users. [Our vision](/direction/monitor/) is to make every GitLab project observable by default, with features that are easy to operate without specialized, expert skills. Teams can connect the dots between every deployment, incident, and other noteworthy events using and collaborating with telemetry data, which ultimately decreases the frequency and severity of production issues.\n\nGitLab’s observability capability is completely open-sourced and relies on open APIs such as Prometheus and OpenTelemetry so users don’t have to worry about vendor lock-in from instrumentation to alerting. It’s built into the GitLab DevOps platform to help you use the capability right away within your native workflow.\n\nLearn more about [observability and the DevOps Platform](https://about.gitlab.com/).\n\n\n\n\n\n\n\n",[806,723,852,995],"features",{"slug":997,"featured":6,"template":681},"observability-is-key-to-cloud-native-transitions-and-modern-application-development","content:en-us:blog:observability-is-key-to-cloud-native-transitions-and-modern-application-development.yml","Observability Is Key To Cloud Native Transitions And Modern Application Development","en-us/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development.yml","en-us/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development",{"_path":1003,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1004,"content":1010,"config":1016,"_id":1018,"_type":17,"title":1019,"_source":18,"_file":1020,"_stem":1021,"_extension":21},"/en-us/blog/want-a-better-devops-career-learn-the-business",{"title":1005,"description":1006,"ogTitle":1005,"ogDescription":1006,"noIndex":6,"ogImage":1007,"ogUrl":1008,"ogSiteName":667,"ogType":668,"canonicalUrls":1008,"schema":1009},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749669715/Blog/Hero%20Images/synchronous-collaboration-as-a-remote-designer.jpg","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":1005,"description":1006,"authors":1011,"heroImage":1007,"date":1013,"body":1014,"category":14,"tags":1015},[1012],"Johanna Ambrosio","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",[806,831,974],{"slug":1017,"featured":6,"template":681},"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":1023,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1024,"content":1030,"config":1036,"_id":1038,"_type":17,"title":1039,"_source":18,"_file":1040,"_stem":1041,"_extension":21},"/en-us/blog/key-organizational-models-for-devops-teams",{"title":1025,"description":1026,"ogTitle":1025,"ogDescription":1026,"noIndex":6,"ogImage":1027,"ogUrl":1028,"ogSiteName":667,"ogType":668,"canonicalUrls":1028,"schema":1029},"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":1025,"description":1026,"authors":1031,"heroImage":1027,"date":1032,"body":1033,"category":14,"tags":1034},[1012],"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",[806,974,1035],"growth",{"slug":1037,"featured":6,"template":681},"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":1043,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1044,"content":1050,"config":1056,"_id":1058,"_type":17,"title":1059,"_source":18,"_file":1060,"_stem":1061,"_extension":21},"/en-us/blog/how-to-move-from-ic-to-devops-manager-and-succeed",{"title":1045,"description":1046,"ogTitle":1045,"ogDescription":1046,"noIndex":6,"ogImage":1047,"ogUrl":1048,"ogSiteName":667,"ogType":668,"canonicalUrls":1048,"schema":1049},"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":1045,"description":1046,"authors":1051,"heroImage":1047,"date":1053,"body":1054,"category":14,"tags":1055},[1052],"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",[806,831,974],{"slug":1057,"featured":6,"template":681},"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":1063,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1064,"content":1070,"config":1077,"_id":1079,"_type":17,"title":1080,"_source":18,"_file":1081,"_stem":1082,"_extension":21},"/en-us/blog/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them",{"title":1065,"description":1066,"ogTitle":1065,"ogDescription":1066,"noIndex":6,"ogImage":1067,"ogUrl":1068,"ogSiteName":667,"ogType":668,"canonicalUrls":1068,"schema":1069},"Fantastic Infrastructure as Code security attacks and how to find them","Learn about possible attack scenarios in Infrastructure as Code and GitOps environments, evaluate tools and scanners with Terraform, Kubernetes, etc., and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667482/Blog/Hero%20Images/cover-image-unsplash.jpg","https://about.gitlab.com/blog/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Fantastic Infrastructure as Code security attacks and how to find them\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2022-02-17\",\n      }",{"title":1065,"description":1066,"authors":1071,"heroImage":1067,"date":1073,"body":1074,"category":14,"tags":1075},[1072],"Michael Friedrich","2022-02-17","\n[Infrastructure as Code](/topics/gitops/infrastructure-as-code/)(IaC) has eaten the world. It helps manage and provision computer resources automatically and avoids manual work or UI form workflows. Lifecycle management with IaC started with declarative and idempotent configuration, package, and tool installation. In the era of cloud providers, IaC tools additionally help abstract cloud provisioning. They can create defined resources automatically (network, storage, databases, etc.) and apply the configuration (DNS entries, firewall rules, etc.).\n\nLike everything else, it has its flaws. IaC workflows have shifted left in the development lifecycle, making it more efficient. Developers and DevOps engineers need to learn new tools and best practices. Mistakes may result in leaked credentials or supply chain attacks. Existing security assessment tools might not be able to detect these new vulnerabilities.\n\nIn this post, we will dive into these specific risks and focus on IaC management tools such as Terraform, cloud providers, and deployment platforms involving containers and Kubernetes.\n\nFor each scenario, we will look into threats, tools, integrations, and best practices to reduce risk.\n\nYou can read the blog post top-down or navigate into the chapters individually.\n\n- [Scan your own infrastructure - know what's important](#scan-your-infrastructure---know-what-is-important)\n    - [Thinking like an attacker](#thinking-like-an-attacker)\n- [Tools to detect Terraform vulnerabilities](#tools-to-detect-terraform-vulnerabilities)\n- [Develop more IaC scenarios](#develop-more-iac-scenarios)\n    - [Terraform Module Dependency Scans](#terraform-module-dependency-scans)\n    - [IaC Security Scanning for Containers](#iac-security-scanning-for-containers)\n    - [IaC Security Scanning with Kubernetes](#iac-security-scanning-with-kubernetes)\n- [Integrations into CI/CD and Merge Requests for Review](#integrations-into-cicd-and-merge-requests-for-review)\n    - [Reports in MRs as comment](#reports-in-mrs-as-comment)\n    - [MR Comments using GitLab IaC SAST reports as source](#mr-comments-using-gitlab-iac-sast-reports-as-source)\n- [What is the best integration strategy?](#what-is-the-best-integration-strategy)\n\n## Scan your infrastructure - know what is important\n\nStart with identifying the project/group responsible for managing the IAC tasks. An inventory search for specific IaC tools, file suffixes (Terraform uses `.tf`, for example), and languages can be helpful. The security scan tools discussed in this blog post will discover all supported types automatically. Once you have identified the projects, you can use one of the tools to run a scan and identify the detected possible vulnerabilities.\n\nThere might not be any scan results because your infrastructure is secure at this time. Though, your processes may require you to create documentation, runbooks, and action items for eventually discovered vulnerabilities in the future. Creating a forecast on possible scenarios to defend is hard, so let us change roles from the defender to the attacker for a moment. Which security vulnerabilities are out there to exploit as a malicious attacker? Maybe it is possible to create vulnerable scenarios and simulate the attacker role by running a security scan.\n\n### Thinking like an attacker\n\nThere can be noticeable potential vulnerabilities like plaintext passwords in the configuration. Other scenarios involve cases you would never think of or a chain of items causing a security issue.\n\nLet us create a scenario for an attacker by provisioning an S3 bucket in AWS with Terraform. We intend to store logs, database dumps, or credential vaults in this S3 bucket.\n\nThe following example creates the `aws_s3_bucket` resource in Terraform using the AWS provider.\n\n```hcl\n# Create the bucket\nresource \"aws_s3_bucket\" \"demobucket\" {\n  bucket = \"terraformdemobucket\"\n  acl = \"private\"\n}\n```\n\nAfter provisioning the S3 bucket for the first time, someone decided to make the S3 bucket accessible by default. The example below grants public access to the bucket using `aws_s3_bucket_public_access_block`. `block_public_acls` and `block_public_policy` are set to `false` to allow any public access.\n\n```\n# Grant bucket access: public\nresource \"aws_s3_bucket_public_access_block\" \"publicaccess\" {\n  bucket = aws_s3_bucket.demobucket.id\n  block_public_acls = false\n  block_public_policy = false\n}\n```\n\nThe S3 bucket is now publicly readable, and anyone who knows the URL or scans network ranges for open ports may find the S3 bucket and its data. Malicious actors can not only capture credentials but also may learn about your infrastructure, IP addresses, internal server FQDNs, etc. from the logs, backups, and database dumps being stored in the S3 bucket.\n\nWe need ways to mitigate and detect this security problem. The following sections describe the different tools you can use. The full Terraform code is located in [this project](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/tree/main/terraform/aws) and allows you to test all tools described in this blog post.\n\n## Tools to detect Terraform vulnerabilities\n\nIn the \"not worst case\" scenario, the Terraform code to manage your infrastructure is persisted at a central Git server and not hidden somewhere on a host or local desktop. Maybe you are using `terraform init, plan, apply` jobs in CI/CD pipelines already. Let us look into methods and tools that help detect the public S3 bucket vulnerability. Later, we will discuss CI/CD integrations and automating IaC security scanning.\n\nBefore we dive into the tools, make sure to clone the demo project locally to follow the examples yourself.\n\n```shell\n$ cd /tmp\n$ git clone https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning.git && cd  infrastructure-as-code-scanning/\n```\n\nThe tool installation steps in this blog post are illustrated with [Homebrew on macOS](https://brew.sh/). Please refer to the tools documentation for alternative installation methods and supported platforms.\n\nYou can follow the tools for Terraform security scanning by reading top-down, or navigate into the tools sections directly:\n\n- [tfsec](#tfsec)\n- [kics](#kics)\n- [terrascan](#terrascan)\n- [semgrep](#semgrep)\n- [tflint](#tflint)\n\n### tfsec\n\n[tfsec](https://github.com/aquasecurity/tfsec) from Aqua Security can help detect Terraform vulnerabilities. There are [Docker images available](https://github.com/aquasecurity/tfsec#use-with-docker) to quickly test the scanner on the CLI, or binaries to [install tfsec](https://aquasecurity.github.io/tfsec/v1.1.4/getting-started/installation/). Run `tfsec` on the local project path `terraform/aws/` to get a list of vulnerabilities.\n\n```shell\n$ brew install tfsec\n$ tfsec terraform/aws/\n```\n\nThe default scan provides a table overview on the CLI, which may need additional filters. Inspect `tfsec –help` to get a list of all available [parameters](https://aquasecurity.github.io/tfsec/v1.1.4/getting-started/usage/) and try generating JSON and JUnit output files to process further.\n\n```shell\n$ tfsec terraform/aws --format json --out tfsec-report.json\n1 file(s) written: tfsec-report.json\n$ tfsec terraform/aws --format junit --out tfsec-junit.xml\n1 file(s) written: tfsec-junit.xml\n```\n\nThe full example is located in the [terraform/aws directory in this project](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/tree/main/terraform/aws).\n\n#### Parse tfsec JSON reports with jq\n\nIn an earlier blog post, we shared [how to detect the JSON data structures and filter with chained jq commands](/blog/devops-workflows-json-format-jq-ci-cd-lint/). The tfsec report is a good practice: Extract the `results` key, iterate through all array list items and filtered by `rule_service` being `s3`, and only print `severity`, `description` and `location.filename`.\n\n```shell\n$ jq \u003C tfsec-report.json | jq -c '.[\"results\"]' | jq -c '.[] | select (.rule_service == \"s3\") | [.severity, .description, .location.filename]'\n```\n\n![tfsec parser output example](https://about.gitlab.com/images/blogimages/iac-security-scanning/tfsec-json-jq-parser.png){: .shadow}\n\n### kics\n\n[kics](https://kics.io/) is another IaC scanner, providing support for many different tools (Ansible, Terraform, Kubernetes, Dockerfile, and cloud configuration APIs such as AWS CloudFormation, Azure Resource Manager, and Google Deployment Manager).\n\nLet's try it: [Install kics](https://docs.kics.io/latest/getting-started/) and run it on the vulnerable project. `--report-formats`, `--output-path` and `--output-name` allow you to create a JSON report which can be automatically parsed with additional tooling.\n\n```shell\n$ kics scan --path .\n$ kics scan --path . --report-formats json --output-path kics --output-name kics-report.json\n```\n\nParsing the JSON report from `kics` with jq works the same way as the tfsec example above. Inspect the data structure and nested object, and filter by AWS as `cloud_provider`. The `files` entry is an array of dictionaries, which turned out to be a little tricky to extract with an additional `(.files[] | .file_name )` to add:\n\n```\n$ jq \u003C kics/kics-report.json | jq -c '.[\"queries\"]' | jq -c '.[] | select (.cloud_provider == \"AWS\") | [.severity, .description, (.files[] | .file_name ) ]'\n```\n\n![kics json jq parser](https://about.gitlab.com/images/blogimages/iac-security-scanning/kics-json-jq-parser.png){: .shadow}\n\n`kics` returns different [exit codes](https://docs.kics.io/latest/results/#exit_status_code) based on the number of different severities found. `50` indicates `HIGH` severities and causes your CI/CD pipeline to fail.\n\n### checkov\n\n[Checkov](https://checkov.io) supports Terraform (for AWS, GCP, Azure and OCI), CloudFormation, ARM, Severless framework, Helm charts, Kubernetes, and Docker.\n\n```shell\n$ brew install checkov\n$ checkov --directory .\n```\n\n### terrascan\n\n[Terrascan](https://runterrascan.io/docs/getting-started/) supports Terraform, and more [policies](https://runterrascan.io/docs/policies/) for cloud providers, Docker, and Kubernetes.\n\n```shell\n$ brew install terrascan\n$ terrascan scan .\n```\n\n### semgrep\n\nSemgrep is working on [Terraform support](https://semgrep.dev/docs/language-support/), currently in Beta. It also detects Dockerfile errors - for example invalid port ranges and multiple ranges, similar to kics.\n\n```shell\n$ brew install semgrep\n$ semgrep --config auto .\n```\n\n### tflint\n\n[tflint](https://github.com/terraform-linters/tflint) also is an alternative scanner.\n\n## Develop more IaC scenarios\n\nWhile testing IaC Security Scanners for the first time, I was looking for demo projects and examples. The [kics queries list for Terraform](https://docs.kics.io/latest/queries/terraform-queries/) provides an exhaustive list of all vulnerabilities and the documentation linked. From there, you can build and create potential attack vectors for demos and showcases without leaking your company code and workflows.\n\n[Terragoat](https://github.com/bridgecrewio/terragoat) also is a great learning resource to test various scanners and see real-life examples for vulnerabilities.\n\n```shell\n$ cd /tmp && git clone https://github.com/bridgecrewio/terragoat.git && cd terragoat\n\n$ tfsec .\n$ kics scan --path .\n$ checkov --directory .\n$ semgrep --config auto .\n$ terrascan scan .\n```\n\nIt is also important to verify the reported vulnerabilities and create documentation for required actions for your teams. Not all detected vulnerabilities are necessarily equally critical in your environment. With the rapid development of IaC, [GitOps}(https://about.gitlab.com/topics/gitops/), and cloud-native environments, it can also be a good idea to use 2+ scanners to see if there are missing vulnerabilities on one or the other.\n\nThe following sections discuss more scenarios in detail.\n\n- [Terraform Module Dependency Scans](#terraform-module-dependency-scans)\n- [IaC Security Scanning for Containers](#iac-security-scanning-for-containers)\n- [IaC Security Scanning with Kubernetes](#iac-security-scanning-with-kubernetes)\n\n### Terraform Module Dependency Scans\n\nRe-usable IaC workflows also can introduce security vulnerabilities you are not aware of. [This project](https://gitlab.com/gitlab-de/use-cases/iac-tf-vuln-module) provides the module files and package in the registry, which can be consumed by `main.tf` in the demo project.\n\n```hcl\nmodule \"my_module_name\" {\n  source = \"gitlab.com/gitlab-de/iac-tf-vuln-module/aws\"\n  version = \"1.0.0\"\n}\n```\n\nkics has [limited support for the official Terraform module registry](https://docs.kics.io/latest/platforms/#terraform_modules), `checkov` failed to download private modules, `terrascan` and `tfsec` work when `terraform init` is run before the scan. Depending on your requirements, running `kics` for everything and `tfsec` for module dependency checks can be a solution, suggestion added [here](https://gitlab.com/groups/gitlab-org/-/epics/6653#note_840447132).\n\n### IaC Security Scanning for Containers\n\nSecurity problems in containers can lead to application deployment vulnerabilities. The [kics query database](https://docs.kics.io/latest/queries/dockerfile-queries/) helps to reverse engineer more vulnerable examples: Using the latest tag, privilege escalations with invoking sudo in a container, ports out of range, and multiple entrypoints are just a few bad practices.\n\nThe following [Dockerfile](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/blob/main/Dockerfile) implements example vulnerabilities for the scanners to detect:\n\n```\n# Create vulnerabilities based on kics queries in https://docs.kics.io/latest/queries/dockerfile-queries/\nFROM debian:latest\n\n# kics: Run Using Sudo\n# kics: Run Using apt\nRUN sudo apt install git\n\n# kics: UNIX Ports Out Of Range\nEXPOSE 99999\n\n# kics: Multiple ENTRYPOINT Instructions Listed\nENTRYPOINT [\"ex1\"]\nENTRYPOINT [\"ex2\"]\n```\n\nKics, tfsec, and terrascan can detect `Dockerfile` vulnerabilities, similar to semgrep and checkov. As an example scanner, terrascan can detect the vulnerabilities using the `--iac-type docker` parameter that allows to filter the scan type.\n\n```shell\n$ terrascan scan --iac-type docker\n```\n\n![terrascan Docker IaC type scan result](https://about.gitlab.com/images/blogimages/iac-security-scanning/terrascan-docker-iac.png){: .shadow}\n\nYou can run kics and tfsec as an exercise to verify the results.\n\n### IaC Security Scanning with Kubernetes\n\nSecuring a Kubernetes cluster can be a challenging task. Open Policy Agent, Kyverno, RBAC, etc., and many different YAML configuration attributes require reviews and automated checks before the production deployments. [Cluster image scanning](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html) is one way to mitigate security threats, next to [Container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) for the applications being deployed. A suggested read is the book [“Hacking Kubernetes” book](https://www.oreilly.com/library/view/hacking-kubernetes/9781492081722/) by Andrew Martin and Michael Hausenblas if you want to dive deeper into Kubernetes security and attack vectors.\n\nIt's possible to make mistakes when, for example, copying YAML example configuration and continue using it. I've created a deployment and service for a [Kubernetes monitoring workshop](/handbook/marketing/developer-relations/developer-evangelism/projects/#practical-kubernetes-monitoring-with-prometheus), which provides a practical example to learn but also uses some not so good practices.\n\nThe following configuration in [ecc-demo-service.yml](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/blob/main/kubernetes/ecc-demo-service.yml) introduces vulnerabilities and potential production problems:\n\n```yaml\n---\n# A deployment for the ECC Prometheus demo service with 3 replicas.\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: ecc-demo-service\n  labels:\n    app: ecc-demo-service\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: ecc-demo-service\n  template:\n    metadata:\n      labels:\n        app: ecc-demo-service\n    spec:\n      containers:\n      - name: ecc-demo-service\n        image: registry.gitlab.com/everyonecancontribute/observability/prometheus_demo_service:latest\n        imagePullPolicy: IfNotPresent\n        args:\n        - -listen-address=:80\n        ports:\n        - containerPort: 80\n---\n# A service that references the demo service deployment.\napiVersion: v1\nkind: Service\nmetadata:\n  name: ecc-demo-service\n  labels:\n    app: ecc-demo-service\nspec:\n  ports:\n  - port: 80\n    name: web\n  selector:\n    app: ecc-demo-service\n```\n\nLet's scan the Kubernetes manifest with kics and parse the results again with jq. A list of kics queries for Kubernetes can be found in the [kics documentation](https://docs.kics.io/latest/queries/kubernetes-queries/).\n\n```shell\n$ kics scan --path kubernetes --report-formats json --output-path kics --output-name kics-report.json\n\n$ jq \u003C kics/kics-report.json | jq -c '.[\"queries\"]' | jq -c '.[] | select (.platform == \"Kubernetes\") | [.severity, .description, (.files[] | .file_name ) ]'\n```\n\n![Kubernetes manifest scans and jq parser results with kics](https://about.gitlab.com/images/blogimages/iac-security-scanning/kics-kubernetes-jq-parser.png){: .shadow}\n\n[Checkov](https://www.checkov.io/) detects similar vulnerabilities with Kubernetes.\n\n```\n$ checkov --directory kubernetes/\n$ checkov --directory kubernetes -o json > checkov-report.json\n```\n\n[kube-linter](https://docs.kubelinter.io/#/?id=installing-kubelinter) analyzes Kubernetes YAML files and Helm charts for production readiness and security.\n\n```shell\n$ brew install kube-linter\n$ kube-linter lint kubernetes/ecc-demo-service.yml --format json > kube-linter-report.json\n```\n\n[kubesec](https://kubesec.io/) provides security risk analysis for Kubernetes resources. `kubesec` is also integrated into the [GitLab SAST scanners](https://docs.gitlab.com/ee/user/application_security/sast/#enabling-kubesec-analyzer).\n\n```shell\n$ docker run -i kubesec/kubesec:512c5e0 scan /dev/stdin \u003C kubernetes/ecc-demo-service.yml\n```\n\n## Integrations into CI/CD and Merge Requests for Review\n\nThere are many scanners out there, and most of them return the results in JSON which can be parsed and integrated into your CI/CD pipelines. You can learn more about the evaluation of GitLab IaC scanners in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/39695). The table in the issue includes licenses, languages, outputs, and examples.\n\n`checkov` and `tfsec` provide JUnit XML reports as output format, which can be parsed and integrated into CI/CD. Vulnerability reports will need a different format though to not confuse them with unit test results for example. Integrating a SAST scanner in GitLab requires you to provide [artifacts:reports:sast](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportssast) as a specified output format and API. [This report](https://docs.gitlab.com/ee/user/application_security/iac_scanning/#reports-json-format) can then be consumed by GitLab integrations such as MR widgets and vulnerability dashboards, available in the Ultimate tier. The following screenshot shows adding a Kubernetes deployment and service with potential vulnerabilities in [this MR](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/merge_requests/3).\n\n![MR widget showing IaC vulnerabilities with Kubernetes](https://about.gitlab.com/images/blogimages/iac-security-scanning/gitlab-iac-mr-widget-kubernetes.png){: .shadow}\n\n### Reports in MRs as comment\n\nThere are different ways to collect the JSON reports in your CI/CD pipelines or scheduled runs. One of the ideas can be creating a merge request comment with a Markdown table. It needs a bit more work with parsing the reports, formatting the comment text, and interacting with the GitLab REST API, shown in the following steps in a Python script. You can follow the implementation steps to re-create them in your preferred language for the scanner type and use [GitLab API clients](/partners/technology-partners/#api-clients).\n\nFirst, read the report in JSON format, and inspect whether `kics_version` is set to continue. Then extract the `queries` key, and prepare the `comment_body` with the markdown table header columns.\n\n```python\nFILE=\"kics/kics-report.json\"\n\nf = open(FILE)\nreport = json.load(f)\n\n# Parse the report: kics\nif \"kics_version\" in report:\n    print(\"Found kics '%s' in '%s'\" % (report[\"kics_version\"], FILE))\n    queries = report[\"queries\"]\nelse:\n    raise Exception(\"Unsupported report format\")\n\ncomment_body = \"\"\"### kics vulnerabilities report\n\n| Severity | Description | Platform | Filename |\n|----------|-------------|----------|----------|\n\"\"\"\n```\n\nNext, we need to parse all queries in a loop, and collect all column values. They are collected into a new list, which then gets joined with the `|` character. The `files` key needs a nested collection, as this is a list of dictionaries where only the `file_name` is of interest for the demo.\n\n```python\n# Example query to parse: {'query_name': 'Service Does Not Target Pod', 'query_id': '3ca03a61-3249-4c16-8427-6f8e47dda729', 'query_url': 'https://kubernetes.io/docs/concepts/services-networking/service/', 'severity': 'LOW', 'platform': 'Kubernetes', 'category': 'Insecure Configurations', 'description': 'Service should Target a Pod', 'description_id': 'e7c26645', 'files': [{'file_name': 'kubernetes/ecc-demo-service.yml', 'similarity_id': '9da6166956ad0fcfb1dd533df17852342dcbcca02ac559becaf51f6efdc015e8', 'line': 38, 'issue_type': 'IncorrectValue', 'search_key': 'metadata.name={{ecc-demo-service}}.spec.ports.name={{web}}.targetPort', 'search_line': 0, 'search_value': '', 'expected_value': 'metadata.name={{ecc-demo-service}}.spec.ports={{web}}.targetPort has a Pod Port', 'actual_value': 'metadata.name={{ecc-demo-service}}.spec.ports={{web}}.targetPort does not have a Pod Port'}]}\n\nfor q in queries:\n    #print(q) # DEBUG\n    l = []\n    l.append(q[\"severity\"])\n    l.append(q[\"description\"])\n    l.append(q[\"platform\"])\n\n    if \"files\" in q:\n        l.append(\",\".join((f[\"file_name\"] for f in q[\"files\"])))\n\n    comment_body += \"| \" + \" | \".join(l) + \" |\\n\"\n\nf.close()\n```\n\nThe markdown table has been prepared, so now it is time to communicate with the GitLab API. [python-gitlab](https://python-gitlab.readthedocs.io/en/stable/api-usage.html) provides a great abstraction layer with programmatic interfaces.\n\nThe GitLab API needs a project/group access token with API permissions. The `CI_JOB_TOKEN` is not sufficient.\n\n![Set the Project Access Token as CI/CD variable, not protected](https://about.gitlab.com/images/blogimages/iac-security-scanning/gitlab-cicd-variable-project-access-token.png){: .shadow}\n\nRead the `GITLAB_TOKEN` from the environment, and instantiate a new `Gitlab` object.\n\n```python\nGITLAB_URL='https://gitlab.com'\n\nif 'GITLAB_TOKEN' in os.environ:\n    gl = gitlab.Gitlab(GITLAB_URL, private_token=os.environ['GITLAB_TOKEN'])\nelse:\n    raise Exception('GITLAB_TOKEN variable not set. Please provide an API token to update the MR!')\n```\n\nNext, use the `CI_PROJECT_ID` CI/CD variable from the environment to select the [project object](https://python-gitlab.readthedocs.io/en/stable/gl_objects/projects.html) which contains the merge request we want to target.\n\n```python\nproject = gl.projects.get(os.environ['CI_PROJECT_ID'])\n```\n\nThe tricky part is to fetch the [merge request](https://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_requests.html) ID from the CI/CD pipeline, it is not always available. A workaround can be to read the `CI_COMMIT_REF_NAME` variable and match it against all MRs in the project, looking if the `source_branch` matches.\n\n```python\nreal_mr = None\n\nif 'CI_MERGE_REQUEST_ID' in os.environ:\n    mr_id = os.environ['CI_MERGE_REQUEST_ID']\n    real_mr = project.mergerequests.get(mr_id)\n\n# Note: This workaround can be very expensive in projects with many MRs\nif 'CI_COMMIT_REF_NAME' in os.environ:\n    commit_ref_name = os.environ['CI_COMMIT_REF_NAME']\n\n    mrs = project.mergerequests.list()\n\n    for mr in mrs:\n        if mr.source_branch in commit_ref_name:\n            real_mr = mr\n            # found the MR for this source branch\n            # print(mr) # DEBUG\n\nif not real_mr:\n    print(\"Pipeline not run in a merge request, no reports sent\")\n    sys.exit(0)\n```\n\nLast but not least, use the MR object to [create a new note](https://python-gitlab.readthedocs.io/en/stable/gl_objects/notes.html) with the `comment_body` including the Markdown table created before.\n\n```python\nmr_note = real_mr.notes.create({'body': comment_body})\n```\n\nThis workflow creates a new MR comment every time a new commit is pushed. Consider evaluating the script and refining the update frequency by yourself. The script can be integrated into CI/CD with running kics before generating the reports shown in the following example configuration for `.gitlab-ci.yml`:\n\n```yaml\n# Full RAW example for kics reports and scans\nkics-scan:\n  image: python:3.10.2-slim-bullseye\n  variables:\n    # Visit for new releases\n    # https://github.com/Checkmarx/kics/releases\n    KICS_VERSION: \"1.5.1\"\n  script:\n    - echo $CI_PIPELINE_SOURCE\n    - echo $CI_COMMIT_REF_NAME\n    - echo $CI_MERGE_REQUEST_ID\n    - echo $CI_MERGE_REQUEST_IID\n    - apt-get update && apt-get install wget tar --no-install-recommends\n    - set -ex; wget -q -c \"https://github.com/Checkmarx/kics/releases/download/v${KICS_VERSION}/kics_${KICS_VERSION}_linux_x64.tar.gz\" -O - | tar -xz --directory /usr/bin &>/dev/null\n    # local requirements\n    - pip install -r requirements.txt\n    - kics scan --no-progress -q /usr/bin/assets/queries -p $(pwd) -o $(pwd) --report-formats json --output-path kics --output-name kics-report.json || true\n    - python ./integrations/kics-scan-report-mr-update.py\n```\n\nYou can find the [.gitlab-ci.yml configuration](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/blob/main/.gitlab-ci.yml) and the full script, including more inline comments and debug output [in this project](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning). You can see the implementation MR testing itself in [this comment](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/merge_requests/4#note_840472146).\n\n![MR comment with the kics report as Markdown table](https://about.gitlab.com/images/blogimages/iac-security-scanning/kics-python-gitlab-mr-update-table.png){: .shadow}\n\n### MR comments using GitLab IaC SAST reports as source\n\nThe steps in the previous section show the raw `kics` command execution, including JSON report parsing that requires you to create your own parsing logic. Alternatively, you can rely on the [IaC scanner in GitLab](https://docs.gitlab.com/ee/user/application_security/iac_scanning/#making-iac-analyzers-available-to-all-gitlab-tiers) and parse the SAST JSON report as [a standardized format](https://docs.gitlab.com/ee/user/application_security/iac_scanning/#reports-json-format). This is available for all GitLab tiers.\n\nDownload the [gl-sast-report.json example](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/blob/main/example-reports/gl-sast-report-kics-iac.json), save it as `gl-sast-report.json` in the same directory as the script, and parse the report in a similar way shown above.\n\n```python\nFILE=\"gl-sast-report.json\"\n\nf = open(FILE)\nreport = json.load(f)\n\n# Parse the report: kics\nif \"scan\" in report:\n    print(\"Found scanner '%s' in '%s'\" % (report[\"scan\"][\"scanner\"][\"name\"], FILE))\n    queries = report[\"vulnerabilities\"]\nelse:\n    raise Exception(\"Unsupported report format\")\n```\n\nThe parameters in the vulnerability report also include the CVE number. The `location` is using a nested dictionary and thus easier to parse.\n\n```python\ncomment_body = \"\"\"### IaC SAST vulnerabilities report\n\n| Severity | Description | Category | Location | CVE |\n|----------|-------------|----------|----------|-----|\n\"\"\"\n\nfor q in queries:\n    #print(q) # DEBUG\n    l = []\n    l.append(q[\"severity\"])\n    l.append(q[\"description\"])\n    l.append(q[\"category\"])\n    l.append(q[\"location\"][\"file\"])\n    l.append(q[\"cve\"])\n\n    comment_body += \"| \" + \" | \".join(l) + \" |\\n\"\n\nf.close()\n```\n\nThe `comment_body` contains the Markdown table, and can use the same code to update the MR with a comment using the GitLab API Python bindings. An example run is shown in [this MR comment](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/merge_requests/8#note_841940319).\n\nYou can integrate the script into your CI/CD workflows using the following steps: 1) Override the `kics-iac-sast` job `artifacts` created by the `Security/SAST-IaC.latest.gitlab-ci.yml` template and 2) Add a job `iac-sast-parse` which parses the JSON report and calls the script to send a MR comment.\n\n```yaml\n# GitLab integration with SAST reports spec\ninclude:\n- template: Security/SAST-IaC.latest.gitlab-ci.yml\n\n# Override the SAST report artifacts\nkics-iac-sast:\n  artifacts:\n    name: sast\n    paths:\n      - gl-sast-report.json\n    reports:\n      sast: gl-sast-report.json\n\niac-sast-parse:\n  image: python:3.10.2-slim-bullseye\n  needs: ['kics-iac-sast']\n  script:\n    - echo \"Parsing gl-sast-report.json\"\n    - pip install -r requirements.txt\n    - python ./integrations/sast-iac-report-mr-update.py\n  artifacts:\n      paths:\n      - gl-sast-report.json\n```\n\nThe CI/CD pipeline testing itself can be found in [this MR comment](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/merge_requests/9#note_841976761). Please review the [sast-iac-report-mr-update.py](https://gitlab.com/gitlab-de/use-cases/infrastructure-as-code-scanning/-/blob/main/integrations/sast-iac-report-mr-update.py) script and evaluate whether it is useful for your workflows.\n\n## What is the best integration strategy?\n\nOne way to evaluate the scanners is to look at their extensibility. For example, [kics](https://docs.kics.io/latest/creating-queries/) calls them `queries`, [semgrep](https://semgrep.dev/docs/writing-rules/overview/) uses `rules`, [checkov](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) says `policies`, [tfsec](https://aquasecurity.github.io/tfsec/v1.1.5/getting-started/configuration/custom-checks/) goes for `custom checks` as a name. These specifications allow you to create and contribute your own detection methods with extensive tutorial guides.\n\nMany of the shown scanners provide container images to use, or CI/CD integration documentation. Make sure to include this requirement in your evaluation. For a fully integrated and tested solution, use the [IaC Security Scanning feature in GitLab](https://docs.gitlab.com/ee/user/application_security/iac_scanning/), currently based on the `kics` scanner. If you already have experience with other scanners, or prefer your own custom integration, evaluate the alternatives for your solution. All scanners discussed in this blog post provide JSON as output format, which helps with programmatic parsing and automation.\n\nMaybe you'd like to [contribute a new IaC scanner](https://docs.gitlab.com/ee/user/application_security/iac_scanning/#contribute-your-scanner) or help improve the detection rules and functionality from the open source scanners :-)\n\nCover image by [Sawyer Bengtson](https://unsplash.com/photos/tnv84LOjes4) on [Unsplash](https://unsplash.com)\n{: .note}\n",[894,1076,806],"kubernetes",{"slug":1078,"featured":6,"template":681},"fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them","content:en-us:blog:fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them.yml","Fantastic Infrastructure As Code Security Attacks And How To Find Them","en-us/blog/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them.yml","en-us/blog/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them",{"_path":1084,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1085,"content":1091,"config":1096,"_id":1098,"_type":17,"title":1099,"_source":18,"_file":1100,"_stem":1101,"_extension":21},"/en-us/blog/ten-reasons-why-your-business-needs-ci-cd",{"title":1086,"description":1087,"ogTitle":1086,"ogDescription":1087,"noIndex":6,"ogImage":1088,"ogUrl":1089,"ogSiteName":667,"ogType":668,"canonicalUrls":1089,"schema":1090},"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":1086,"description":1087,"authors":1092,"heroImage":1088,"date":1093,"body":1094,"category":14,"tags":1095},[890],"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",[806,110,974],{"slug":1097,"featured":6,"template":681},"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":1103,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1104,"content":1110,"config":1116,"_id":1118,"_type":17,"title":1119,"_source":18,"_file":1120,"_stem":1121,"_extension":21},"/en-us/blog/top-10-ways-machine-learning-may-help-devops",{"title":1105,"description":1106,"ogTitle":1105,"ogDescription":1106,"noIndex":6,"ogImage":1107,"ogUrl":1108,"ogSiteName":667,"ogType":668,"canonicalUrls":1108,"schema":1109},"Top 10 ways machine learning may help DevOps","Is machine learning part of your DevOps plan? Here are some ways ML could fit right in.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668426/Blog/Hero%20Images/retrospectivesgitlabpost.jpg","https://about.gitlab.com/blog/top-10-ways-machine-learning-may-help-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top 10 ways machine learning may help DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-02-14\",\n      }",{"title":1105,"description":1106,"authors":1111,"heroImage":1107,"date":1112,"body":1113,"category":14,"tags":1114},[762],"2022-02-14","_This post is meant as a general introduction to DevOps and machine learning, but does not represent GitLab’s roadmap with ModelOps. Read more about [our ModelOps plans](/blog/introducing-modelops-to-solve-data-science-challenges/)._\n\nLike a superhero’s cape, machine learning can enhance the innate powers of your DevOps program. \n\nYes, it’s early days, and no, machine learning can’t do everything you may want it to – yet. But if you [start using ML tools now](/topics/devops/the-role-of-ai-in-devops/), you’ll be poised to make it a full-fledged participant in your DevOps team as the technology continues to mature. Here are some things ML can help with today.\n\n1. **Make sense of your test data.** Whether it’s regression, unit, functional, or user acceptance testing, ML can help sort through the data generated from those tests, find patterns, figure out the coding problems that caused any bugs, and alert the troops. \n\n2. **Manage your help-desk alerts.** You can teach ML about the factors that make up different types of alerts and automatically route alerts to the best-qualified (mostly human) problem-solver, be it the service desk or a networking guru. Some ML systems can also fix problems without human intervention, based on rules you create.\n\n3. **Put the security into “DevSecOps.”** ML algorithms can, in real time, look through the massive amount of information generated from your security software and network logs and determine if there’s a breach long before a human could. The ML software compares the usual network-traffic baseline to what it’s seeing currently and detects when there’s an attack, or it can tell you if the amount of code in an app or system has suddenly grown to double its size when it shouldn’t have. ML can also triage the problems it finds, as well as take actions to correct security issues based on your guidelines. Further, ML tools can also help ensure your governance rules are followed and create a detailed audit trail.\n\n4. **Gather user requirements.** Natural language processing has come a long way, and can collect, validate, and track documents to streamline the process of figuring out what users are asking for. The technology can also help detect incomplete requirements or wonky timelines and can translate user wants and needs into highly technical project requirements. This makes the entire project-management process more efficient.\n\n5. **Help with pesky dev details.** No, not to replace developers, of course – at least not yet. But ML can learn from past apps you’ve created to recommend security guardrails and how to make software scale and perform better, among other things. Developers definitely see this trend coming, and in [GitLab’s 2021 Global DevSecOps Survey](/developer-survey/), around a third said that an understanding of AI or ML is the most important skill for their future careers. ML-powered code completion tools are already on the market, which provide suggestions for app developers.\n\n6. **Automate testing and create test data.** ML can automatically create the tests you need for QA and the test cases they’re based on, generate and manage test data, and automate code reviews. Natural language processing can help you review test cases and eliminate duplicates, as well as identify gaps in test coverage. Teams will continue to use machine learning models to [make test automation smarter](https://www.forrester.com/blogs/predictions-2021-software-developers-face-mounting-pressure/) , Forrester Research predicts.\n\n7. **Reduce complexity and allow better communication throughout the software chain.** ML can smooth out the rough edges among teams responsible for different parts of the process, and act as an Esperanto of sorts to allow people to speak to each other using the same language. No more, “It worked on my machine.” \n\n8. **Save time on manual provisioning.** Sure the cloud makes this easier, but ML can provision what it thinks you’ll need before you actually need it. \n\n9. **Improve software and product quality.** ML can help find issues like resource leaks, wasted CPU cycles, and other problems, so you can optimize your code before it hits production. At Facebook, [a bug detection tool](https://www2.deloitte.com/us/en/insights/focus/signals-for-strategists/ai-assisted-software-development.html/#:~:text=AI%20is%20helping%20to%20make%20better%20software%20Professionals%20are%20using,in%20design,%20development,%20and%20deployment&text=Artificial%20intelligence%20isn't%20writing,develop%20and%20test%20custom%20software.) predicts defects and suggests remedies that prove correct 80% of the time, Deloitte reports. And the IEEE ran a study from Google X about an ML method that [predicts failures of individual components](https://ieeexplore.ieee.org/document/7448033) that was “far more accurate than the traditional MTBF approach.” \n\n10. **Integrate your workflows and allow continuous improvement.** Some DevOps teams are using ML to analyze all development, operational, and test tools to find any gaps, as well as where pieces of the pipeline need to be better integrated and where APIs are still needed. ML algorithms can help teams figure out why some projects go very well, and others don’t. You can use ML to monitor your monitors and make sure they’re fully operational. Further, ML continues to learn from its training models – both the ones you provide and those it learns on its own as it goes – to continue to help you provide better products and services over time. And when you get down to it, isn’t that the whole point of technology?\n\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._",[806,1115,722,808],"code review",{"slug":1117,"featured":6,"template":681},"top-10-ways-machine-learning-may-help-devops","content:en-us:blog:top-10-ways-machine-learning-may-help-devops.yml","Top 10 Ways Machine Learning May Help Devops","en-us/blog/top-10-ways-machine-learning-may-help-devops.yml","en-us/blog/top-10-ways-machine-learning-may-help-devops",{"_path":1123,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1124,"content":1130,"config":1135,"_id":1137,"_type":17,"title":1138,"_source":18,"_file":1139,"_stem":1140,"_extension":21},"/en-us/blog/4-must-know-devops-principles",{"title":1125,"description":1126,"ogTitle":1125,"ogDescription":1126,"noIndex":6,"ogImage":1127,"ogUrl":1128,"ogSiteName":667,"ogType":668,"canonicalUrls":1128,"schema":1129},"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","\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":1125,"description":1126,"authors":1131,"heroImage":1127,"date":1132,"body":1133,"category":14,"tags":1134},[762],"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.",[806,974,232],{"slug":1136,"featured":6,"template":681},"4-must-know-devops-principles","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":1142,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1143,"content":1149,"config":1155,"_id":1157,"_type":17,"title":1158,"_source":18,"_file":1159,"_stem":1160,"_extension":21},"/en-us/blog/learn-python-with-pj-part-1",{"title":1144,"description":1145,"ogTitle":1144,"ogDescription":1145,"noIndex":6,"ogImage":1146,"ogUrl":1147,"ogSiteName":667,"ogType":668,"canonicalUrls":1147,"schema":1148},"Learn Python with Pj! Part 1 - Getting started","Follow along as our education evangelist Pj Metz learns Python, and shares his experiences in the first of a multi-part series.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664962/Blog/Hero%20Images/python.jpg","https://about.gitlab.com/blog/learn-python-with-pj-part-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Learn Python with Pj! Part 1 - Getting started\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"PJ Metz\"}],\n        \"datePublished\": \"2022-02-08\",\n      }",{"title":1144,"description":1145,"authors":1150,"heroImage":1146,"date":1152,"body":1153,"category":14,"tags":1154},[1151],"PJ Metz","2022-02-08","\n\n_Hello World!_ \n\nMy name is Pj Metz and I’m the education evangelist at GitLab. My day job involves working with universities across the globe to help faculty and students learn to use GitLab for educational or research purposes. Currently, my code experience is limited to C# and JavaScript, with some HTML and CSS in there for good measure. However, one of the most popular languages in the education community is Python, so I decided to jump in and teach myself Python to better connect with my community members. \n\nI’ll be learning on [Codecademy](https://www.codecademy.com), an online interactive learning platform that offers a variety of languages and career path curriculums, both free and paid. It’s where I started learning to code back in 2020 so I’m already comfortable with it’s format and curriculum style. \n\nEvery few weeks you’ll see what I’ve learned and how I’ve applied that new knowledge. I’ll discuss the basics of writing in Python and show off some of what I’ve done. I’m still relatively new to writing code in general, so expect to see this through the eyes of a beginner — not just a Python beginner, but coding in general. I might even make a mistake in my descriptions/explanations. Let’s jump in! 🐍\n\n## First lessons\n\nThe first few lessons involved writing a “hello world” and changing the value of a premade variable.\n\n![codecademy screen showing instructions on the left, the IDE in the middle, and the output on the right](https://about.gitlab.com/images/blogimages/helloworld.png)\n\nI moved on to writing my own variables and experimenting with several different types, including ints, strings, and floats. I learned that you can change a variable after defining it, similar to many languages, and that you can even change the type; the most recently defined type will be the one used at run time. Concatenation works similarly to other languages: using a plus sign to combine variables. I did some reading ahead and learned about [f-strings](https://www.geeksforgeeks.org/formatted-string-literals-f-strings-python/) as an easy method of concatenating strings. I’m used to doing something similar in JavaScript for my [Twitter bots,](https://gitlab.com/MetzinAround/DivasLive) so this felt important to know. \n\nI also learned how to do some control flow through `if`, `elif`, and `else`. The logic remains the same, but conventions are a bit different. I’m used to writing an if statement like this in JavScript. \n\n```javascript\nif(partyRock === 'in the house tonight') {\n  everybody = 'have a good time'\n  console.log(`Party rock ${partyRock} everybody just ${everybody}`)\n} else {\n  everybody = 'sad party rock noises'\n  console.log(everybody)\n}\n\n```\nIn Python, there are no curly braces. Rather, a colon and indent takes care of that work. \n\n```python\nif partyRock == 'in the house tonight':\n   everybody = 'have a good time'\n   print(f\"Party Rock is {partyRock} everybody just {everybody}\")\nelse:\n  everybody = 'sad party rock noises'\n  print(everybody)\n```\n\n## Initial thoughts\n\nI like the readability of Python. It’s a little less cluttered, but I remember being very excited about curly braces when I first learned them. Using them for functions and methods and the like always made me feel like a “real programmer” when I was first starting. That being said, Python syntax is coming along naturally for me. \n\nSomething that’s different for me is the way Python has you initialize variables. C# is a statically typed language, meaning that part of defining a variable is saying what type of variable it is (int, string, float, etc.). Python does not require you to define the type, it will simply know at run-time. This is similar to JavaScript, but it does still throw me since I started learning with C#. Additionally, in JavaScript you have to use `let`, `var`, or `const`. In Python you just … name it and give it a value. Felt strange at first, but has become more natural as I progressed. Not having to define the type always strikes me as “weird,” but that’s personal preference, not anything actually verifiably wrong. \n\nAdditionally, the naming convention of variables is different as well. Python convention dictates underscores as spaces, while C# and JavaScript both prefer camel case, which is where each new word is capitalized. \n\n``` cs\n int minLength = 8\n```\n```javascript\nminLength = 8\n```\n\n``` python\nmin_length = 8\n```\n\nThe [naming conventions of Python](https://www.python.org/dev/peps/pep-0008/#naming-conventions) have certain rules for when to use underscores and how, especially double underscores which behave differently in Python depending on where they appear in the name. I only know what I’ve seen so far in Codecademy, but they’ve named all their variables with underscores instead of spaces. \n\n### Favorite new knowledge\n\nI really like being able to create multiple line strings simply by using three quotes, similar to using three backticks for a code block in markdown. Formatting the output has always been frustrating for me; having to remind myself that `\\n` exists and then looking up how exactly I’m supposed to use it is something I’ve spent an embarrassing amount of time on. And likely will do until the day I hang up my keyboard for good. \n\n![a code block showing a multi line sentence and the terminal output after showing correct format as dictated by the code](https://about.gitlab.com/images/blogimages/pythonmultilinestring.png)\n\nThis is nice in that how it looks in the code is how it looks in the output. I love that! \n\nThis is the first installment in the Learn Python with Pj! series. Make sure to read:\n- [Part 2 - Lists and loops](/blog/learn-python-with-pj-part-2/)\n- [Part 3 - Functions and strings](/blog/learn-python-with-pj-part-3/)\n- [Part 4 - Dictionaries and Files](/blog/learn-python-with-pj-part-4-dictionaries-and-files/)\n- [Part 5 - Build a hashtag tracker with the Twitter API](/blog/learn-python-with-pj-part-5-building-something-with-the-twitter-api/)\n\n",[831,806,1035],{"slug":1156,"featured":6,"template":681},"learn-python-with-pj-part-1","content:en-us:blog:learn-python-with-pj-part-1.yml","Learn Python With Pj Part 1","en-us/blog/learn-python-with-pj-part-1.yml","en-us/blog/learn-python-with-pj-part-1",{"_path":1162,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1163,"content":1169,"config":1174,"_id":1176,"_type":17,"title":1177,"_source":18,"_file":1178,"_stem":1179,"_extension":21},"/en-us/blog/first-time-open-source-contributor-5-things-to-get-you-started",{"title":1164,"description":1165,"ogTitle":1164,"ogDescription":1165,"noIndex":6,"ogImage":1166,"ogUrl":1167,"ogSiteName":667,"ogType":668,"canonicalUrls":1167,"schema":1168},"First time open source contributor? 5 things to get you started","Open source really is *open* but it can be difficult to know where (and how) to jump in. Here's our best advice.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671390/Blog/Hero%20Images/developers-choose-open-source.jpg","https://about.gitlab.com/blog/first-time-open-source-contributor-5-things-to-get-you-started","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"First time open source contributor? 5 things to get you started\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-02-07\",\n      }",{"title":1164,"description":1165,"authors":1170,"heroImage":1166,"date":1171,"body":1172,"category":14,"tags":1173},[762],"2022-02-07","If you haven’t yet contributed to an open source software project, you may be eager to get going. Contributing to open source is a [great way to learn, teach, and build your technical expertise](https://clearcode.cc/blog/why-developers-contribute-open-source-software/). And it feels good to be part of a community. Yet your first time contributing can be intimidating. Here are five things you need to know to get up and running on open source:\n\n1. Contributing isn’t just about writing code. Open source projects need help on a variety of things, starting with coding, but also things like designing navigation and menus, writing documentation, managing timelines, organizing open issues, moderating message boards and answering questions. [Other ways to get started/](https://www.hanselman.com/blog/get-involved-in-open-source-today-how-to-contribute-a-patch-to-a-github-hosted-open-source-project-like-code-52) File a bug and suggest a patch for it or suggest a feature. In short, [there are many ways to contribute](https://opensource.guide/how-to-contribute/#why-contribute-to-open-source), in line with your interests and expertise. And no matter what you give, you’ll meet people and become an appreciated member of the group – sometimes contributing on ancillary things will earn you more points than coding.  \n\n2. Confusion is ok. If you’re bewildered at first, it’s not just because you’re a newbie. Each open source project has its own culture, [including terms of art, behavior norms, accepted practices](https://opensource.guide/how-to-contribute/#orienting-yourself-to-a-new-project), etc. So, even if you work for years on one project and are completely up to speed on what life is like there, it’s more than likely your next project will be totally different. There are some things that are usually present, such as the [roles of people on the project](https://opensource.guide/leadership-and-governance/), including author, owner, maintainer, contributor and committer. But the fact is, it will take time, observation and interacting with project members to understand how things are done within a project – and whether or not you are a good fit. If the vibe is not right, go elsewhere. There are so many projects that could use your support.    \n\n3. If there is a code of conduct, you need to get familiar with it. Not all open source projects will have a [code of conduct](https://opensource.guide/code-of-conduct/). When you’re interested in a project, be sure to see if there is a code of conduct and, if so, what it says. That way, you won’t make a gaffe without realizing it (and having to hear about it from everyone else). At a high level, respect the other participants (see number 5, below). If there is no explicit code of conduct, there are [core values and norms](https://opensource.com/open-organization/21/8/leadership-cultural-social-norms) that are recognized in the open source community. Chief among these are kindness and worldwide collaboration.\n\n4. Open Source Projects often have community governance models. There are [three types of org structures](https://opensource.guide/leadership-and-governance/) generally associated with open source projects: BDFL (Benevolent Dictator for Life; [Python](/blog/beginner-guide-python-programming/)is [one example](https://artsandculture.google.com/entity/benevolent-dictator-for-life/m03m3r0l?hl=en), meritocracy (this exact term may not be used but it’s about the relative “merit” of contributions; [Apache projects](https://www.apache.org/index.html#projects-list) follow this model) or liberal contribution (under which the people who contribute the most have the most say; [Node.js](https://openjsf.org) and [Rust](/blog/rust-programming-language/)are examples). In recent years, the BDFL model has [fallen out of favor](https://readwrite.com/open-source-magento-roy-rubin-bdfl/) in some circles as it leaves the project vulnerable if a leader steps away. [As Jason Baker wrote](https://opensource.com/article/18/7/bdfl) on OpenSource.com, “How an open source project is governed can have very real consequences on the long-term sustainability of its user and developer communities alike.” Just something to keep in mind.\n\n5. When in doubt, ask away, there are no dumb questions. As with any group you might belong to, you and the other members will be happier if the tone is welcoming and kind. Essentially, you’re there to collaborate so respect is important. Open source participants tend to be diverse in every possible way, stay open and considerate. Women traditionally are underrepresented in open source, [so be encouraging](https://internethealthreport.org/2019/codes-of-conduct-in-open-source-communities/). Try not to waste people’s time and provide as much context as needed in issues and conversations. Most projects will set the expectation that participants should [respect each other and be civil](https://developer.mozilla.org/en-US/docs/MDN/Contribute/Open_source_etiquette) in their interactions. \n\nThe rules are a lot like the ones you may have learned in your childhood: Observe before you jump in, share your knowledge generously, always thank people who help you, and play well with others. Don’t be tempted to add to threads just to see your name. Try to find answers to questions within the community before you ask. Read the README file. [Read the documentation](https://gomakethings.com/open-source-etiquette/). If you do ask a question or send a pull request, be patient. Don't expect an immediate reply and don’t keep posting the same question. People have different priorities and might have been caught up with work and life. Make sure you have buy-in from project implementers before you send in actual code. This shows you want to contribute and you respect the work that has gone on before you.    \n\nReady to get started? Here are some success stories from our community to inspire you:\n* Dave Barr wrote about [“Why new software engineers should contribute to GitLab”](https://davebarr.dev/why-new-software-engineers-should-contribute-to-gitlab/)\n\n* [You’re hired! Two GitLab contributors turn their success into full-time engineering roles](/blog/you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles/)",[852,806,268],{"slug":1175,"featured":6,"template":681},"first-time-open-source-contributor-5-things-to-get-you-started","content:en-us:blog:first-time-open-source-contributor-5-things-to-get-you-started.yml","First Time Open Source Contributor 5 Things To Get You Started","en-us/blog/first-time-open-source-contributor-5-things-to-get-you-started.yml","en-us/blog/first-time-open-source-contributor-5-things-to-get-you-started",{"_path":1181,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1182,"content":1188,"config":1195,"_id":1197,"_type":17,"title":1198,"_source":18,"_file":1199,"_stem":1200,"_extension":21},"/en-us/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":1183,"description":1184,"ogTitle":1183,"ogDescription":1184,"noIndex":6,"ogImage":1185,"ogUrl":1186,"ogSiteName":667,"ogType":668,"canonicalUrls":1186,"schema":1187},"How to keep up with CI/CD best practices","In this post, we look at continuous integration/continuous delivery (CI/CD), how to implement some best practices, and why it is important.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to keep up with CI/CD best practices\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":1183,"description":1184,"authors":1189,"heroImage":1185,"date":1190,"body":1191,"category":14,"tags":1192},[890],"2022-02-03","\nContinuous integration and continuous delivery (CI/CD) are at the heart of any successful DevOps practice. Teams wanting to achieve modern software development must keep up with [CI/CD](/topics/ci-cd/) best practices. Here’s what you need to know to make sure your team is on the right track.\n\n## What is the meaning of CI/CD?\n\nIt’s a tech process, it’s a mindset, it’s a series of steps… CI/CD is all of those things. Put simply, CI enables DevOps teams to streamline code development using automation. CI simplifies software builds and source code integration, enables version control, and promotes greater collaboration via automation. Where CI leaves off, continuous delivery kicks in with automated testing and deployment. Not only does CD reduce the amount of “hands on” time ops pros need to spend on delivery and deployment, it also enables teams to [drastically reduce the number of tools](/resources/whitepaper-forrester-manage-your-toolchain/) required to manage the lifecycle.\n\n## What are the best practices for CICD?\n\nIf you want to be successful with CI/CD, make continuous integration, delivery, and deployment your mantra as they are the cornerstones of software development practices. The goal of DevOps is to get software to users more quickly than traditional methods, and these development practices will help make that happen.\n\nIf you ask 10 DevOps teams for their take on CI/CD best practices, granted, you'll likely get 10 different answers. However, there are several tips that are widely agreed upon:\n\n1. Only build once: Don't create a new build for each stage because you risk introducing inconsistencies. Instead, promote the same build artifacts throughout each stage of the CI/CD pipeline. This requires an environment-agnostic build.\n\n2. Streamline the tests: Strike a balance between test coverage and performance. If it takes too long for test results users will try to circumvent the process.\n\n3. Fail fast: On the CI side, devs committing code need to know as quickly as possible if there are issues so they can roll the code back and fix it while it’s fresh in their minds. The idea of “fail fast” helps reduce developer context switching too, which makes for happier DevOps professionals.\n\n4. Make it daily: The more regular the code commits, the more benefit DevOps teams will see.\n\n5. Fix it if it’s broken: CI/CD makes it simple to fix broken builds.\n\n6. Clean pre-production environments:The longer environments are kept running, the harder it becomes to track all the configuration changes and updates that have been applied. This is good incentive to clean up pre-production environments between each deployment. \n\n7. Automation all the time: Keep tweaking the CI/CD pipeline to ensure the “continuous automation” state is achieved.\n\n8. Know the steps: Make sure the release and rollback plans are well documented and understood by the entire team.\n\n9. Keep it safe: CI/CD is a shift left, so it offers a good opportunity to integrate security earlier in the process.\n\n10. It’s a loop: Make sure there’s an easy way for the entire team to receive (and contribute to) feedback.\n\n## Continuous delivery best practices\n\nContinuous delivery/deployment feels like it deserves it’s own deep dive into best practices because CI often steals most of the headlines. Here is a roundup of CD best practices:\n\n- Start where you are: Don’t wait for a new platform. It’s always possible to tweak what you have to make it faster and more efficient.\n\n- Less is more: The best CD is done with minimal tools.\n\n- Track what’s happening: Issues and merge requests can get out of hand. If milestones are an option, they can help. Bonus: Milestones do double-duty when setting up Agile sprints and releases.\n\n- Automatically deploy changes: Streamline user acceptance testing and staging with automation.\n\n- Manage the release pipeline: Automation is the answer.\n\n- Establish monitoring: Keeping a good eye on the production process saves time and money. It also can provide key data points to the business side.\n\n- Kick off continuous deployment: Once continuous delivery is humming, bring on the hands-free deployment where it’s possible to send changes to production automatically. \n\n## How to improve the CI/CD pipeline\n\nA pipeline is just another way of characterizing the series of steps involved in deploying a new version of software. Monitoring and automation are concepts introduced in a CI/CD pipeline to improve the app development process, especially during the integration and testing phases, as well as when software is delivered and deployed.\n\nThe typical elements of a CI/CD pipeline are: plan, analyze, design, build, test, release, deploy, validation and compliance and maintenance. These steps can be done manually, but the real value of a CI/CD pipeline comes when they are automated.\n\nIf it’s time to finetune the CI/CD pipeline, consider the following performance enhancements:\n\n- Mix up the release strategy. A [canary release](https://martinfowler.com/bliki/CanaryRelease.html) (sometimes called a canary deployment) might be worth considering. In a canary release, new features are deployed to just a select group of users.\n\n- Add more automated testing because there is [never enough automated testing](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/). \n\n- Continue to pare down. Fewer tools mean fewer handoffs and steps. If CI/CD is part of a [DevOps platform](/topics/devops-platform/), everything will be in one place. \n\n- Consider a routine practice of [software composition analysis](https://www.csoonline.com/article/3640808/software-composition-analysis-explained-and-how-it-identifies-open-source-software-risks.html) to ensure the DevOps team is keeping track of critical open source software issues. \n\n## How to measure the success of CI/CD \n\nDevOps teams can’t know how well their CI/CD practices are going unless they measure them. [Metrics](https://about.gitlab.com/topics/ci-cd/continuous-integration-metrics/) play an important role in improving system performance and helping to identify where value can be added. They also provide a baseline for measuring the impact of any improvements made.\n\n Here are the best metrics to employ:\n\n### Cycle time\nThis refers to how long it takes to roll out a functional application from the time work on the code begins. To figure out the average life cycle time, measure the development process phases. This metric will provide insight into what the overall development time is and any bottlenecks in the process.\n\n### Time to value\nThis refers to how long it takes to release written code. The integration, testing, delivery, and deployment should take anywhere from minutes up to a few hours for test cycles to finish. If it takes days to move a build through the CI/CD pipeline time to value is not being realized and the process should be fine-tuned.\n\n### Uptime\nUptime is a measure of stability and reliability and whether everything is working as it should. It is one of the biggest priorities the ops team has. When the CI/CD strategy is automated, ops leaders can focus more of their time on system stability and less time on workflow issues.\n\n### Error rates\nApplication error rates is a fact of life in the development process. Tracking them is very important because not only can error rates indicate quality problems, but also ongoing performance and uptime related issues. \nIf uptime and error rates seem high, it can illustrate a [common CI/CD challenge](https://about.gitlab.com/blog/modernize-your-ci-cd/) between dev and ops teams. Operations goals are a key indicator of process success.\n\n### Infrastructure costs\nInfrastructure costs are critically important with cloud native development. Deploying and managing a CI/CD platform can result in big expenses if they are not kept in check.\nTo determine how they will set their prices, cloud providers will consider what the cost is of network hardware, infrastructure maintenance, and labor. \n\n### Team retention\nIt’s no mystery: When a developer – or anyone, really – feels valued and satisfied they’re apt to stick around. When teams work well together and know how to collaborate, retention is likely to follow. On the flip side, developers might feel uncomfortable speaking up if they don’t like how things are going, but looking at retention rates can help identify potential problems.\n\n##  What are the benefits of following CI/CD best practices?\n\nWhen best practices are followed, the [benefits of CI/CD](https://about.gitlab.com/topics/ci-cd/benefits-continuous-integration/) are felt throughout an organization: From HR to operations, teams work better and achieve goals. Establishing metrics around CI/CD performance can go beyond providing insights on development and carry over to many aspects of the business. \n\nA well-functioning CI/CD pipeline can be a game changer for DevOps teams. Here are some of the biggest benefits:\n\n**Developers aren’t fixing things, they’re writing code.** Fewer tools and toolchains mean less time spent on maintenance and more time spent actually producing high-quality software applications.\n\n**Code is in production.** Rather than sitting in a queue, code actually makes it out into the real world. This also leads to happier developers.\n\n**Developers have the bandwidth to focus on solving business problems.** A streamlined CI/CD process lets developers actually focus on what matters and not on the distractions of problem code, missed handoffs, production issues, and more.\n\n**It’s easier to innovate.** It’s a competitive world, and organizations need all the tools at their disposal to stay ahead. A well-built CI/CD process makes software development easier, faster and safer, which means DevOps teams have the time and energy to think outside the box.\n\n**Attract and retain talent.** It’s a very competitive labor market and DevOps talent can be very hard to impress. Nothing says “we take our DevOps team seriously” more than an organization that’s invested in the technology and processes around CI/CD.\n\n**Everyone does what they do best.** Dev, ops, sec and test each have a critical role to play, and CI/CD helps [clearly delineate the responsibilities](/topics/devops/build-a-devops-team/).\n\n## CI/CD deployment strategy\n\nRemember that CI/CD is about getting a software application into the hands of a customer that is better and done quicker than before. Organizations that adopt CI/CD find their productivity improves significantly. The trick is coming up with a deployment strategy that works for the individual organization. \n\nHere are some strategies to help make a deployment successful:\n\n- Commit to frequency in CD\n- Automate the build process\n- Run tests in parallel, and create a deployment pipeline\n- Fail fast and adopt a shift left mentality to give developers the skills and tools to accelerate without breaking things \n- Use CI tools that provide faster feedback\n\n## How can I implement CI/CD in my organization?\n\nBefore any software is implemented, it’s key to determine what the business drivers are and the same goes for adopting CI/CD. All development stakeholders should be involved early on in the implementation process. Developers should provide input since they will be the main users of a product. \n\nMake sure to do your due diligence when researching software that enables CI/CD, and ask about free trials. \n\nWhile it may seem counterintuitive since CI/CD is about accelerating the pace of software delivery in an automated fashion, start the process with a mentality of slow and steady. The boost in efficiency will decline if bugs are steadily moving into the finished application. \n\nIt’s important to have consistency in the integration process. Perform unit tests, trigger releases manually and track metrics. Then determine what can and should be automated.\n",[1193,1194,806],"CI","CD",{"slug":1196,"featured":6,"template":681},"how-to-keep-up-with-ci-cd-best-practices","content:en-us:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","en-us/blog/how-to-keep-up-with-ci-cd-best-practices.yml","en-us/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":1202,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1203,"content":1209,"config":1216,"_id":1218,"_type":17,"title":1219,"_source":18,"_file":1220,"_stem":1221,"_extension":21},"/en-us/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too",{"title":1204,"description":1205,"ogTitle":1204,"ogDescription":1205,"noIndex":6,"ogImage":1206,"ogUrl":1207,"ogSiteName":667,"ogType":668,"canonicalUrls":1207,"schema":1208},"How Zoopla used DORA metrics to boost deployments, increase automation and more","GitLab customer Zoopla used the DORA metrics to boost production deployments from once a week to roughly 40 times a day. And that was only one of the performance improvements...","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665635/Blog/Hero%20Images/blog-performance-metrics.jpg","https://about.gitlab.com/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Zoopla used DORA metrics to boost deployments, increase automation and more\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gustaw Fit of Zoopla\"}],\n        \"datePublished\": \"2022-01-24\",\n      }",{"title":1204,"description":1205,"authors":1210,"heroImage":1206,"date":1212,"body":1213,"category":14,"tags":1214},[1211],"Gustaw Fit of Zoopla","2022-01-24","\n\nAbout two years ago, Zoopla started wondering how we could measure the overall improvements in performance in the engineering department. We were in the early stages of a program of work called [Bedrock](https://zoopla.blog/posts/2021/project-bedrock-replatforming/). Bedrock was all about making engineering capability more efficient and flexible in responding to the business needs.\n\nAfter researching various options, we decided on the [DORA metrics](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance). They provided us with all the necessary insights to track our success, and benchmark ourselves against a definition of good.\n\n## What is DORA?\n\nDORA is the acronym for the DevOps Research and Assessment group: they’ve surveyed more than 50,000 technical professionals worldwide to better understand how the technical practices, cultural norms, and management approach affect organisational performance.\n\n(Take a dive into the [latest DORA Report](https://www.ciosummits.com/Online_Assets_Puppet_2016_State_of_DevOps_Report.pdf) and in the book that summarizes the findings:  [Accelerate](https://www.amazon.com/Accelerate-Building-Performing-Technology-Organizations/dp/B07BMBYHXL/ref=sr_1_2?crid=R1O9AH85U6PR&keywords=accelerate+book&qid=1643046474&sprefix=accelerate+book%2Caps%2C70&sr=8-2)).\n\n## What are the metrics Zoopla is using?\n\n- Production deploy frequency - Time between the first commit on a merge request to master and production deployment\n- Lead time - Number of successful production deployments / day\n- Mean Time To Recover - Time required from customer impact first started to removal of the customer impact\n- Change fail rate - For the primary application or service you work on, what percentage of changes to production or released to users result in degraded service (e.g., lead to service impairment or service outage) and subsequently require remediation (e.g., require a hotfix, rollback, fix forward, patch)\n- Time to onboard - Time required from the engineer who had joined the company, until their first commit is merged to master on a non-personal repository.\n\n\n## How do we understand the metrics?\n\n- Production deploy frequency - limiting amount of code going to production at once (limited batch size)\n- Lead time - reducing amount of blockers for developers\n- MTTR - improving speed of incident recovery\n- Change fail rate - improving quality focus\n- Time to onboard - how efficient is our onboarding process\n\nFollowing the rules of lean:\n\n- Value is only released to production, once it leaves the factory floor (production deploy frequency)\n- Optimize Work In Progress (lead time)\n- Invest in SRE/automation (mean time to recover)\n- Practice kaizen (change fail rate)\n- Have efficient knowledge sharing and work allocation processes (time to onboard)\n\n## How are we collecting the metrics?\n\nWe are using the following data sources:\n\n[GitLab](https://about.gitlab.com) for deploy frequency, lead time, change fail rate and time to onboard\n\n[Blameless](https://www.blameless.com) for mean time to recover (as recorded in incidents)\n\n[Jenkins](https://www.jenkins.io) for deploy frequency and change fail rate\n\nThe process is using APIs extensively. We also needed to come up with a standardised data schema to be able to meaningfully use the metrics. The raw data stored in the s3 bucket can be used in any visualization tool. For our own purposes we have decided to display them in a google spreadsheet. All of these required an extensive implementation effort. The whole flow is powered by modern Python.\n\nSome parts of our process are still not perfect. We are actively working to simplify the flows and standardize data sets.\n\n## How are the metrics used at Zoopla?\n\nThe dashboard is regularly reviewed by the senior engineering management. The metrics are on public display, and are discussed and reviewed in our monthly town hall meeting, and our fortnightly Ops Review. Each team is encouraged to reflect on the metrics as they plan their work, and consider improvements they could introduce.\n\nThe metrics also influence the decisions and prioritization. Just as importantly, they help us to transform our company culture.\n\nIn terms of improvements measured:\n\n- Production deployment frequency was improved from once in a week to multiple times per day (~40 deployments per day).\n- Lead time was improved from an average of 10 days to less than two days (with many projects being close to 2-4h on average).\n- Mean time to recover: we have not measured it before, the main benefit for us is understanding what we need to improve. We are currently in the area of 1-3h on average for sev-0 or sev-1 issues and 24h on average, when we include sev-2 issues.\n- Change failure rate was about 60% before we started, it is now oscillating between ~1-5%.\n- Time to onboard was over 20 days, and we have brought this down to around five days.\n\nThe main cultural changes were:\n\n- We have automated the majority of our deployment pipelines.\n- We have added a lot of automation to incident resolution, primarily by adding auto-scaling.\n- We have trained our teams in incident response, and introduced an on-call rota.\n- We have moved the bulk of our infrastructure management to a standardised Infrastructure as Code (mainly Terraform).\n- We have improved our onboarding process.\n- We have improved our alerting, and partnered with New Relic to reduce investigation effort.\n\nWe hold the ambition to join the elite performing group of organisations as defined by the State of DevOps report. Each day brings us closer to that goal.\n\n## What are our future plans?\n\nOn the technical side, we are working to improve automation of the metrics, to go away from our internal and bespoke metric collection model. We hope our partnership with New Relic will soon enable a much better solution.\n\nOn the DevOps/DORA culture side, we are providing regular talks and training to wider audiences (not only engineering), to establish DORA as a reference point in future product development. We are also making it a key point of our new consolidated engineering strategy.\n\nWe’ve found the DORA metrics helped us improve our software development and delivery processes. With these findings, organizations can make informed adjustments in their process workflows, automation, team composition, tools, and more. We recommend you try this in your organisation too.\n\nFurther reading:\n\n- [The Phonenix Project](https://www.amazon.com/The-Phoenix-Project-audiobook/dp/B00VATFAMI/ref=sr_1_1?crid=3U43AWAK4L6YI&keywords=The+Phoenix+project&qid=1643046949&sprefix=the+phoenix+project%2Caps%2C70&sr=8-1) by Gene Kim, Kevin Behr and George Spafford\n- [The Goal: A Process of Ongoing Improvement](https://www.amazon.com/The-Goal-audiobook/dp/B00IFGGDA2/ref=sr_1_1?crid=2EAKYMNBHT0B5&keywords=the+goal+by+eliyahu+goldratt&qid=1643047036&s=audible&sprefix=The+goal%2Caudible%2C125&sr=1-1) by Eliyahu Goldratt and Jeff Cox\n- [The Unicorn Project](https://www.amazon.com/The-Unicorn-Project-Gene-Kim-audiobook/dp/B0812C82T9/ref=sr_1_1?crid=2B0ENCYRNG2BO&keywords=the+unicorn+project&qid=1643047132&s=audible&sprefix=the+unicorn%2Caudible%2C76&sr=1-1) by Gene Kim et al\n",[806,1215,678],"customers",{"slug":1217,"featured":6,"template":681},"how-zoopla-uses-dora-metrics-and-your-team-can-too","content:en-us:blog:how-zoopla-uses-dora-metrics-and-your-team-can-too.yml","How Zoopla Uses Dora Metrics And Your Team Can Too","en-us/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too.yml","en-us/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too",{"_path":1223,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1224,"content":1230,"config":1236,"_id":1238,"_type":17,"title":1239,"_source":18,"_file":1240,"_stem":1241,"_extension":21},"/en-us/blog/collaboration-techniques-for-distributed-teams",{"title":1225,"description":1226,"ogTitle":1225,"ogDescription":1226,"noIndex":6,"ogImage":1227,"ogUrl":1228,"ogSiteName":667,"ogType":668,"canonicalUrls":1228,"schema":1229},"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously","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":1225,"description":1226,"authors":1231,"heroImage":1227,"date":1233,"body":1234,"category":14,"tags":1235},[1232],"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](/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",[701,974,785],{"slug":1237,"featured":6,"template":681},"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":1243,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1244,"content":1250,"config":1256,"_id":1258,"_type":17,"title":1259,"_source":18,"_file":1260,"_stem":1261,"_extension":21},"/en-us/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together",{"title":1245,"description":1246,"ogTitle":1245,"ogDescription":1246,"noIndex":6,"ogImage":1247,"ogUrl":1248,"ogSiteName":667,"ogType":668,"canonicalUrls":1248,"schema":1249},"Want secure software development? Our top 5 tips to bring dev and sec together","Every DevOps team wants secure software development but it's surprisingly hard to achieve. Here are 5 strategies to bring dev and sec together.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679444/Blog/Hero%20Images/twotogether.jpg","https://about.gitlab.com/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want secure software development? Our top 5 tips to bring dev and sec together\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-01-10\",\n      }",{"title":1245,"description":1246,"authors":1251,"heroImage":1247,"date":1252,"body":1253,"category":14,"tags":1254},[890],"2022-01-10","\nThe most productive DevOps teams achieve secure software development by baking sec in from the start. That’s a worthwhile goal, but the reality is developers and security teams don’t always get along. From squabbles around where the buck stops to finger-pointing about finding and fixing bugs, dev and sec often struggle to get on the same page.\n\nAt a time when the security stakes have never been higher, dev and sec simply have to figure it out.\n\nHere are our top five tips to [bridge the gap between dev and sec](/blog/developer-security-divide/) and truly welcome security into the DevOps fold.\n\n**1. Forget the past**\n\nIn the bad, old days, a security officer swooped in when code was hitting production to point out problems and demand changes, often with little to no context or explanation. Developers didn’t exactly jump all over themselves to cooperate. TL;DR there’s plenty of blame to explain the lack of secure software development.\n\t\nThankfully, DevOps and modern application development bring fresh narratives and workflows. Nearly 28% of security pros now work in cross-functional DevOps teams, according to our [2021 Global DevSecOps Survey](/developer-survey/). And over 70% have shifted security left, the survey found. \n\nWhat’s the secret to their success? It’s all about DevOps and the [technology changes required to do it successfully](https://about.gitlab.com/blog/elite-team-strategies-to-secure-software-supply-chains/). Our survey found that teams settled on DevOps for better code quality and faster release times, but the tech choices to support that success – automated testing, security scans, and shift-left security – actually ended up bringing dev and sec closer together.\n\n_The takeaway_: The right technology is surprisingly helpful in breaking down stereotypes.\n\n**2. Learn each other’s languages**\n\nClearly, dev and sec have an ongoing communication problem. \n\nIn fact, they can’t even agree on who “owns” security, as we saw in our survey. A sec pro told us, “Security must be a practice of every member of the team from the front-end developer to the system administrator (and also non-tech roles),” while a dev said, “It’s all up to the developer!”\n\nWork needs to happen, and it starts with the very old-fashioned concept of getting to know one another. A sec pro could attend a developer meet-up, and a dev could sit in on a security retro. For some teams, this is going to have to be a forced function where management mandates cross-functional “lunch and learns,” virtual offsites, or even ice breakers.\n\n_The takeaway_: Yes, even an escape room (or other bonding exercises) can [help a team start to speak the same language](https://blog.hslu.ch/majorobm/2019/03/15/escape-rooms-a-great-team-building-activity/).\n\n**3. Institute a security champions program**\n\nIf you can’t beat them, join them, or in this case, embed them. [Developer security champions]( https://devops.com/devops-security-champion-who-what-and-why/) are known and trusted devs who have an interest and enthusiasm for security and want to share it with colleagues. This can be a very successful strategy to actually shift security left and change mindsets forever. \n\nSecurity champions can be part of a formalized program led by the sec team, or grow in a more organic fashion via an enthusiastic dev. Either way, [experts suggest this is a solid way to bring a DevOps team to DevSecOps](/blog/why-security-champions/).\n\n_The takeaway_: Sometimes the message is heard and understood most clearly from an insider.\n\n**4. Meet dev and sec where they are**\n\nIt’s tough to hold a dev accountable for security problems when the vast majority of them aren’t taught about it in college. And sec pros don’t necessarily know how to code. So is it any surprise that two very different skill sets, degree programs, and job requirements might find it hard to come together?\n\nIt’s not surprising but it is problematic. [One solution](https://techbeacon.com/security/why-developers-dislike-security-what-you-can-do-about-it) involves both sides (figuratively) going back to school. Devs can get hands-on training in security, while sec pros learn how to code.\n\nAlso DevOps managers might consider adding [“security software developer”](https://cybersecurityguide.org/careers/security-software-developer/) to the 2022 roster. This fairly new job title has [over 1,000 postings on Glassdoor.com](https://www.glassdoor.com/Job/united-states-security-software-engineer-jobs-SRCH_IL.0,13_IN1_KO14,40.htm?clickSource=searchBox).\n\n_The takeaway_: Continuing education and cross-functional training can yield enormous benefits.\n\n**5. Make the experience real**\n\nActions can speak louder than words, so why not let developers experience, first-hand, what’s involved in a security breach (and, by implication, what the stakes are)? Invite devs to every hacking exercise planned, and get extra points if a [security red team](https://csrc.nist.gov/glossary/term/red_team_blue_team_approach) is involved. \n\t\nAt the same time, introduce security pros to the user experience (UX) team, and invite them to meet with actual users and hear real-time feedback. \n\n_The takeaway_: It’s impossible to feel anything but invested if you truly feel like you’re part of the process.\n",[806,894,1255],"workflow",{"slug":1257,"featured":6,"template":681},"want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together","content:en-us:blog:want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together.yml","Want Secure Software Development Our Top 5 Tips To Bring Dev And Sec Together","en-us/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together.yml","en-us/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together",{"_path":1263,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1264,"content":1270,"config":1275,"_id":1277,"_type":17,"title":1278,"_source":18,"_file":1279,"_stem":1280,"_extension":21},"/en-us/blog/congratulations-to-hashicorp",{"title":1265,"description":1266,"ogTitle":1265,"ogDescription":1266,"noIndex":6,"ogImage":1267,"ogUrl":1268,"ogSiteName":667,"ogType":668,"canonicalUrls":1268,"schema":1269},"Congratulations to HashiCorp! Enjoy the cake!","We’re thrilled to see our open source and tech partner HashiCorp join us in the public market. Public companies like HashiCorp, MongoDB, Confluent, and GitLab show that with the right business models, open source can be highly profitable. Here’s a look at HashiCorp’s history, our partnership, and a nod to the future.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663383/Blog/Hero%20Images/tanuki-bg-full.png","https://about.gitlab.com/blog/congratulations-to-hashicorp","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Congratulations to HashiCorp! Enjoy the cake!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-12-09\",\n      }",{"title":1265,"description":1266,"authors":1271,"heroImage":1267,"date":1272,"body":1273,"category":14,"tags":1274},[762],"2021-12-09","![Cake with message reading \"Congrats on your IPO!\"](https://about.gitlab.com/images/blogimages/hashicorp-cake.jpg)\n\nFrom one open source DevOps company to another, we want to congratulate HashiCorp on becoming a public company! In celebration of your debut in the public markets we sent you a cake!\n\nGitLab and HashiCorp have been partners since 2019. And not only do we work well together, we have a lot in common: both companies have strong business models that are open-core providing both open-source and proprietary features for DevOps practitioners enabling them to create safer software faster. We may solve very different problems in the DevOps ecosystem, but that’s what makes us great partners.\n\n## HashiCorp: always ahead of the curve\n\nAlthough co-founder Mitchell Hashimoto didn’t officially incorporate HashiCorp (named after him) until 2012, he was making contributions to the open source community [from the time he was a teen](https://thenewstack.io/new-stack-makers-mitchell-hashimoto-vagrant-containers-growing-open-source/). And it’s clear Mitchell and team approached the business with a fresh perspective: HashiCorp’s Vagrant was the first automated provisioning of developer environments, which was very useful for onboarding and demos. When Docker became more popular, Vagrant added a Docker provider, making it more usable, even with Docker and Docker Compose later around.\n\nThe team made another bold move in 2014, rolling out the HashiCorp configuration language (HCL) as an alternative to YAML. The step got developers talking and taking sides, but also thinking about what might work best.\n\nAll of those efforts led to perhaps the most ground-breaking part of HashiCorp’s strategy: Vault. The company’s solution that safely stores and controls access to tokens, secrets, API keys, and more, is not just successful, it’s revolutionary. HashiCorp has turned the idea of secrets keeping on its head, by not just allowing companies to store secrets away, but to also have to renew them regularly, kind of like changing the locks on your door on a regular schedule, rather than giving out lots of keys. Clearly this is a paradigm shift for security.\n\n## HashiCorp and GitLab together\n\nVault’s a breakthrough technology for HashiCorp (don’t forget you can use GitLab with Vault to set up [GitLab OpenID connect for authentication](https://docs.gitlab.com/ee/integration/vault.html) or access your [secrets securely in CI](https://docs.gitlab.com/ee/ci/secrets/) as variables) but it’s just one of many that we integrate with.\n\n### Terraform and the GitLab DevOps Platform\n\n[Terraform](https://www.terraform.io) plays a critical role in GitLab’s GitOps/Infrastructure as Code (IaC) workflows, lowering the barriers to entry for teams to adopt Terraform while enabling them to use more stages on the DevOps platform. GitLab’s Terraform integration allows teams to manage the Terraform state in GitLab without external configuration backends.\n\nWe have created the [GitLab Terraform Provider](https://docs.gitlab.com/ee/user/infrastructure/iac/#the-gitlab-terraform-provider) to manage resources on your GitLab instance like groups, projects, users, and more to improve productivity by eliminating an engineer’s dependence on provisioning requests.\n\nA merge request is the center of all collaboration on the DevOps platform. It is important to verify how changes will affect your infrastructure, taking advantage of the [Terraform integration with merge requests](https://docs.gitlab.com/ee/user/infrastructure/iac/mr_integration.html). You can see the planned changes to your infrastructure without leaving the scope of a merge request review at the same time.\n\nUsing GitLab as a [Terraform Module Registry](https://docs.gitlab.com/ee/user/packages/terraform_module_registry/) allows you to publish and reference private Terraform modules in your project’s infrastructure registry, ensuring it’s possible to reuse modules across projects securely. Along with our [IaC security scanning](https://about.gitlab.com/releases/2021/11/22/gitlab-14-5-released/#introducing-infrastructure-as-code-iac-security-scanning) as part of the verify stage, you can safely maintain your infrastructure with ease.\n\n### Terraform and GitLab.com\n\nTerraform is used to manage all the environments of [GitLab.com’s infrastructure](https://gitlab.com/gitlab-com/gitlab-com-infrastructure/) in a single project, allowing collaboration across the entire engineering organization. It is also playing a critical role in our ongoing [migration to Kubernetes](https://about.gitlab.com/handbook/engineering/infrastructure/production/kubernetes/gitlab-com/). Want to deploy a stateful application quickly? GitLab’s [five-minute production app](https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template) template leverages the power of Terraform to get you from idea to production in minutes.\n\n## We’re all-remote\n\nHashiCorp is a remote-first, distributed organization and publicly shares [proven principles](https://works.hashicorp.com) for everyone to learn. GitLab shares this passion for expanding access to opportunity, bolstering global communities, and building more inclusive workplaces where everyone can contribute.\n\n## We see the promise of the future\n\nThe successes of companies like GitLab and HashiCorp, as well as MongoDB and Confluent, on the open market show providing a free tier and commercial offering can be a highly profitable business model for open source technologies and we believe the DevOps market potential is just starting to be tapped.\n\nIn the [words of Dave Bullock](https://about.gitlab.com/blog/wag-labs-blog-post/), former Director of engineering at Wag!: “_We use GitLab with Terraform to test, review, save, and deploy all of our infrastructure as well as the application…The original idea was to just use GitLab 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._”  This is an example of the power of the DevOps Platform. GitLab’s partnership with HashiCorp has made it easier for customers to use more stages of the DevOps Platform. \n\nWe’re joining the global chorus in wishing HashiCorp the best of luck with its public offering.",[806,852,232],{"slug":1276,"featured":6,"template":681},"congratulations-to-hashicorp","content:en-us:blog:congratulations-to-hashicorp.yml","Congratulations To Hashicorp","en-us/blog/congratulations-to-hashicorp.yml","en-us/blog/congratulations-to-hashicorp",{"_path":1282,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1283,"content":1289,"config":1294,"_id":1296,"_type":17,"title":1297,"_source":18,"_file":1298,"_stem":1299,"_extension":21},"/en-us/blog/devsecops-faq-get-up-to-speed-on-this-hot-devops-area",{"title":1284,"description":1285,"ogTitle":1284,"ogDescription":1285,"noIndex":6,"ogImage":1286,"ogUrl":1287,"ogSiteName":667,"ogType":668,"canonicalUrls":1287,"schema":1288},"DevSecOps FAQ: Get up to speed","There's more to dev, sec and ops than meets the eye, particularly when they're combined. Here's what you need to know about DevSecOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669784/Blog/Hero%20Images/security-testing-principles-devs.jpg","https://about.gitlab.com/blog/devsecops-faq-get-up-to-speed-on-this-hot-devops-area","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOps FAQ: Get up to speed\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-12-08\",\n      }",{"title":1284,"description":1285,"authors":1290,"heroImage":1286,"date":1291,"body":1292,"category":14,"tags":1293},[890],"2021-12-08","\n\nIf it feels like [DevSecOps](/topics/devsecops/) is just one more flavor of DevOps, we get it. After all, DevOps could be known as _DevSecBizTestMonitorOps_, but that’s not easy to say or remember. DevSecOps actually plays a unique role in the world of software development. Here’s what you need to know.\n\n## Why is DevSecOps important?\n\nAll of the [well-publicized security breaches](/blog/are-you-ready-for-the-newest-era-of-devsecops/) have shown us one thing: Security can no longer be an afterthought in software development. It used to be that security was a separate department and function with a top-down approach and little actual understanding of how software was developed. Code was handed to security late in the process, and then the sec team had to chase busy devs down for fixes. TL;DR: Let’s just say that didn’t ever work well.\n\nToday, DevSecOps aims squarely at the idea that security has to be baked into the process from the beginning. The need for security to [“shift left,”](/blog/efficient-devsecops-nine-tips-shift-left/) i.e., move from production to development, is at the heart of what DevSecOps is. \n\nThe data is clear: The earlier a developer finds a flaw, the faster the fix, so DevSecOps puts security scans (and their results) in a dev’s workflow, minimizing the barriers to resolution and greatly decreasing context-switching. \n\nAnd this isn’t just something that’s a nice-to-have – it’s actually happening. In our [2021 Global DevSecOps Survey](/developer-survey), we found DevSecOps teams are running more [SAST](https://docs.gitlab.com/ee/user/application_security/sast/), [DAST](https://docs.gitlab.com/ee/user/application_security/dast/), [container](https://docs.gitlab.com/ee/user/application_security/container_scanning/) and [dependency scans](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) than ever before. And, thanks to DevSecOps, a full 72% of security pros told us their organizations’ security efforts as either “strong” or “good.” \n\n## The difference between DevSecOps and DevOps\n\nDevSecOps *is* DevOps and honestly the terms are, can, and should be used interchangeably. That said, GitLab defines DevOps as [“...people working together to conceive, build and deliver secure software at top speed”](/topics/devops/) and, as you can see, that definition includes security. DevSecOps, on the other hand, “weaves security practices into every stage of software development right through deployment with the use of tools and methods to protect and monitor live applications.”\n\nSome think the term “DevSecOps” puts undue emphasis on security, but we heartily disagree. You can’t emphasize security enough!\n\n## Why is DevSecOps important to business?\n\nThe number one benefit of DevOps is code quality, according to our survey, and, clearly, that’s businesses’ priority as well; bad code costs money literally (time to fix) and figuratively (brand reputation). \n\nSo, if it’s [time to convince management to invest in DevSecOps](/blog/devops-stakeholder-buyin/), it’s important to continue to emphasize how devastating a security breach can be.\n\nAlso, it’s vital to connect the dots on exactly how a DevSecOps team can help prevent the worst-case scenarios. From [automated software testing](/blog/devsecops-security-automation/#5-benefits-of-automated-security) to a [security champions program](/blog/why-security-champions/), DevSecOps is one of the most efficient ways to help prevent hacks.\n\n## The future of DevSecOps\n\nThe future of DevSecOps can be summed up in one simple word: more. More testing, more automation, more integration, more shift left, more comprehensive scans… just more of everything that brings security into the development process earlier in the game.\n\nThere are signs that “more” is already happening, based on our 2021 survey results. Nearly 28% of security respondents report they are now part of a cross-functional team and a growing percentage are more focused on compliance. And more than 70% of security pros report their teams shifted left in 2021, up from 65% in 2020. In other words, security is increasingly _on the team._ \n\nAnd don’t forget about the promise of artificial intelligence and machine learning. As [AI/ML use expands in DevOps teams](/blog/ai-in-software-development/), DevSecOps will no doubt benefit.\n\n## Ready to learn DevSecOps?\n\nIf you’re ready to dive into DevSecOps, we have a 20 question quiz so you can test your readiness level and learn more.\n",[806,894,831],{"slug":1295,"featured":6,"template":681},"devsecops-faq-get-up-to-speed-on-this-hot-devops-area","content:en-us:blog:devsecops-faq-get-up-to-speed-on-this-hot-devops-area.yml","Devsecops Faq Get Up To Speed On This Hot Devops Area","en-us/blog/devsecops-faq-get-up-to-speed-on-this-hot-devops-area.yml","en-us/blog/devsecops-faq-get-up-to-speed-on-this-hot-devops-area",{"_path":1301,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1302,"content":1308,"config":1313,"_id":1315,"_type":17,"title":1316,"_source":18,"_file":1317,"_stem":1318,"_extension":21},"/en-us/blog/devops-predictions-gitlab-experts-weigh-in-on-ai-security-remote-work-and-more",{"title":1303,"description":1304,"ogTitle":1303,"ogDescription":1304,"noIndex":6,"ogImage":1305,"ogUrl":1306,"ogSiteName":667,"ogType":668,"canonicalUrls":1306,"schema":1307},"2022 DevOps predictions: GitLab experts weigh in on AI, security, remote   work, and more","Want to see into the DevOps future? We’ve got insights to share, including the challenges for AI/ML and the impact of cloud-native on DevSecOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683162/Blog/Hero%20Images/tomasz-frankowski-kbufvkbfioe-unsplash.jpg","https://about.gitlab.com/blog/devops-predictions-gitlab-experts-weigh-in-on-ai-security-remote-work-and-more","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2022 DevOps predictions: GitLab experts weigh in on AI, security, remote   work, and more\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-12-06\",\n      }",{"title":1303,"description":1304,"authors":1309,"heroImage":1305,"date":1310,"body":1311,"category":14,"tags":1312},[762],"2021-12-06","2022 is set to be a big year for [DevOps](/topics/devops/), especially when it comes to integrating AI and machine learning, pushing security further left in the development cycle, and expanding opportunities for open source and remote work. We’ve gathered eight predictions from the top minds here at GitLab about the DevOps platform and the DevOps industry overall.\n\n## 1. AI/ML adoption will increase and will be instrumental in addressing supply chain issues and labor shortages.\n\n[Taylor McCaslin](https://gitlab.com/tmccaslin), Group Manager, Product - ModelOps & Anti-Abuse, says:\n\n“We’re going to see increased adoption of [AI/ML](/direction/modelops/ai_assisted/) across all industries. With the labor and supply chain shortages and dramatic shifts in climate-related events, companies globally are having to learn to do more with less in even more dynamic environments. AI/ML is well-suited to solve some of these complex problems in industries we may not have expected [adoption from] this early.\n\nWe have started seeing governments embrace AI/ML technologies. When you think about it, governments are by definition inefficient, but they hold a lot of data that’s ripe territory for AI/ML to make an impact. Take the Internal Revenue Service in the U.S., for example. ML applied to process paper tax returns or to look for anomalies could reduce costs and increase revenue from catching tax fraud and data entry mistakes. Also, with Covid-19 not looking like it will go away anytime soon, there are huge data problems that are well suited for AI/ML in tracking and proving vaccination status. The list for AI/ML is endless.\n\nAI/ML still is a specialty field. So businesses need to have clear use cases for hiring data science teams and setting them up for success to deploy models into production. We still see friction between traditional DevOps technologies and new data science platforms slowing time to value and increasing the cost of developing AI/ML technologies, but those problems are becoming more understood and we’ll see that gap shorten over time reducing cost and complexities.”\n\n## 2. Businesses will continue to integrate security more tightly into DevOps and create DevSecOps teams to reduce risk, speed deployment, and gain a competitive advantage.\n\n[Johnathan Hunt](https://gitlab.com/JohnathanHunt), Vice President of Security, says:\n\n“The [DevSecOps](/blog/gitlab-is-setting-standard-for-devsecops/) practice will continue to increase in 2022 as more organizations understand the efficiencies and improved security of this strategy. Further, those that are currently leveraging DevSecOps as part of their development practice are realizing the benefits with fewer vulnerabilities, faster deployments, less time spent in corrective actions, and an overall reduction of risk. Ultimately, this will provide companies with a differentiated approach, leading to competitive advantages in their space.\n\nDevSecOps is important to prioritize due to the increased threat landscape that remote work models introduce. It is imperative that companies focus on transformative ways to protect their product and data to effectively manage their overall risk posture. DevSecOps is a proven strategy that reduces risk and security incidents while allowing faster and more secure code deployments.”\n\n## 3. Two of the biggest buzzwords of 2021 will take divergent paths next year: Kubernetes will play a fundamental role in DevSecOps, while zero trust will see only moderate gains.\n\nHunt says:\n\n“DevOps users have come to realize the benefits of operating security controls natively within Kubernetes rather than separate tools and separate teams adding steps to the process. This is a fundamental component to furthering the DevSecOps story. Additionally, the [Kubernetes](/blog/gitlab-kubernetes-agent-on-gitlab-com/) platform is continuing to evolve and adapt to the need for greater control and automation within reach of DevOps users leading to the natural and highly advantageous shift left strategy.\n\nMeantime, although we are seeing an increase in the implementation of certain zero trust principles, overall the industry has been slow to respond. Much of this is due to the understanding, complexity, and difficulty of implementing full zero-trust models within the tech stack. I predict 2022 will, at best, see a moderate gain in the adoption of [zero trust](/blog/questions-regarding-our-zero-trust-efforts/).”\n\n## 4. Secure software supply chain will become a standard element of security strategy for government organizations.\n\n[Bob Stevens](https://gitlab.com/bstevens1), Area Vice President of Public Sector, says:\n\n“Federal agencies are starting to tackle software supply chain security, spurred by guidance from NIST and actions outlined in Executive Orders issued in early 2021. While these guidelines are critical to success, agencies will rise to the challenge of implementing new security measures instead of waiting to act. Regardless of the publication of final guidance, CIOs will implement actions for software supply chain security to proactively defend their agencies. CIOs know that enhancing cyber defenses immediately is crucial to outsmarting adversaries, and they will not delay in enacting change. Once guidelines are final, CIOs will adjust their policies to meet best practices.\n\nTo ensure security in the software supply chain, people, processes, and technologies need to work together in unison. This includes code that has been examined by numerous security personnel, build processes that take place in the open, and high-quality software that is tested and trusted. Software factories and contractors that work with them will also need to put in place a comprehensive and continuously monitored software bill of materials (SBOM), allowing everyone touching the software to fully understand the dependencies and vulnerabilities of their ecosystems.\n\nA DevOps platform can address many important security considerations. With security scanners built into the development process, agencies can scan every line of code as it is committed, allowing developers to identify and remediate vulnerabilities before they are pushed.“\n\n## 5. Cloud adoption will extend to other parts of the development life cycle, including developers’ own environments. \n\n[Brendan O’Leary](https://gitlab.com/brendan), Staff Developer Evangelist, says:\n\n“I still see a lot of enterprises or individual teams that find themselves at [various phases of DevOps](/blog/welcome-to-the-devops-platform-era/). So I believe that 2022 will bring a shift towards platforms - either through DIY or adoption of a DevOps platform. We’ll see more adoption of cloud technologies for other parts of the development lifecycle as well, such as developers’ own environments.”\n\n## 6. Open source will grow beyond a common software development practice to a full business model embraced by organizations.\n\n[Cesar Saavedra](https://gitlab.com/csaavedra1), Technical Marketing Manager, says:\n\n“Open source growth will continue in the future, and not just as a way to develop software but also as a business model. Not only have companies realized the need to be [digital leaders](https://www.capgemini.com/wp-content/uploads/2017/07/The_Digital_Advantage__How_Digital_Leaders_Outperform_their_Peers_in_Every_Industry.pdf) to be successful in the market, but also large commercial vendors are becoming open source and switching to this business model to stay competitive and open-source startups have caught [the interest of investors](https://techcrunch.com/2021/06/26/2170552/). Open source is taking over the software market. In fact, the Open Source Services Market is [predicted to grow](https://www.businesswire.com/news/home/20201113005374/en/66.84-Billion-Open-Source-Services-Market-by-Industry-Service-Type-and-Geography---Global-Forecast-to-2026---ResearchAndMarkets.com) at a CAGR of ~21.75% with a value expected to reach $66.84 billion by 2026. Another proof point of this growth is that [recent surveys show](https://www.datadoghq.com/container-report/#10) that the most popular container images are all based on open source software, which indicates this growing adoption trend of open source.\n\nAdopting open source into your business model is a complex decision and process. If you’re a successful company with a proprietary software product, it’s just a matter of time before a competitor with an open source offering will appear in your market segment. In this case, you will most likely need to switch your business model to one suited for open source software. For example, you will need to switch from license+subscription revenues to just subscription. Another big decision to make is whether or not to open source your software. Many software products that started as proprietary software converted to open source licensing, e.g. Adobe Flex, Visual Studio Code, .NET framework, PowerShell, Solaris. Open sourcing your software product usually goes hand-in-hand with adopting an open source business model of subscription-based revenues.\n\nYou also will need to contribute back to the open source community by making your enhancements and fixes to your product available in your open source project. In fact, to be successful in the open source market, you have to commit resources to help develop open source projects.”\n\n## 7. The open source community will grow significantly as a result of the acceleration of digital-first and cloud-native companies.\n\nSaavedra says: \n\n“The cloud helped accelerate the adoption of open source software because it allowed companies to scale up without incurring large costs in software licensing (open source subscription models are less expensive than proprietary software). Furthermore, open source software fosters collaboration among the brightest minds no matter where around the globe they reside, bringing together the power of the community and benefiting developers, organizations, and vendors alike. As a result, developers and organizations continue to adopt and contribute to open source projects due to a low entry barrier, accessibility, and cost. The Covid-19 pandemic [accelerated this adoption even more](https://venturebeat.com/2021/01/26/how-the-pandemic-is-accelerating-enterprise-open-source-adoption/) due to the switch to remote work by organizations that now have access to a new set of developer talent well versed in open source. The acceleration of digital-first and cloud-native companies will increase the use of open source, which will, in turn, demand more and more open source developers. The result will be an increase in the size of the open source community worldwide.”\n\n## 8. All-remote will become a prevailing work environment as a means to attract and retain talent.\n\nDarren Murph, Head of Remote, says:\n\n“All-remote and all-colocated will become the prevailing environments. Hybrid-remote will be broadly tested but will be rife with friction and dysfunction due to a lack of understanding in its implementation. The terminology also will evolve. For some organizations, hybrid will end up meaning ‘remote-first with an office for special events,’ while those who attempt to force knowledge workers into a more rigid in-office schedule will struggle to retain employees. \n\nDedicated leadership surrounding remote transitions and overall future-of-work strategy will increase in 2022. What GitLab pioneered has served as [a blueprint for organizations](/company/culture/all-remote/head-of-remote/) like Facebook, Dropbox, Okta, LinkedIn, VMWare, and other tech firms. Next year, industries beyond tech will begin to embrace remote work and create awareness for the intrinsic link between organizational design and talent brand. Organizations that rigidly force knowledge workers back into the office will see above-average attrition rates. With two years of remote work habits being ingrained, top talent will demand continued flexibility. Many organizations that have resisted investing in creating excellent remote work infrastructure will be forced to do so to compete with more flexible rivals. \n\nA well-built remote work plan will be seen as a hedge against future crises. Just as organizations are currently expected to have succession and security plans, having a remote work strategy will be critical to business continuity. Organizations will also need to work hard to establish psychological safety. As people resume social gatherings, employers have an opportunity to lean into the culture that is built outside of work and create strategies for that to be shared within the workplace.”",[806,894,852],{"slug":1314,"featured":6,"template":681},"devops-predictions-gitlab-experts-weigh-in-on-ai-security-remote-work-and-more","content:en-us:blog:devops-predictions-gitlab-experts-weigh-in-on-ai-security-remote-work-and-more.yml","Devops Predictions Gitlab Experts Weigh In On Ai Security Remote Work And More","en-us/blog/devops-predictions-gitlab-experts-weigh-in-on-ai-security-remote-work-and-more.yml","en-us/blog/devops-predictions-gitlab-experts-weigh-in-on-ai-security-remote-work-and-more",{"_path":1320,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1321,"content":1327,"config":1333,"_id":1335,"_type":17,"title":1336,"_source":18,"_file":1337,"_stem":1338,"_extension":21},"/en-us/blog/soft-skills-are-the-key-to-your-devops-career-advancement",{"title":1322,"description":1323,"ogTitle":1322,"ogDescription":1323,"noIndex":6,"ogImage":1324,"ogUrl":1325,"ogSiteName":667,"ogType":668,"canonicalUrls":1325,"schema":1326},"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":1322,"description":1323,"authors":1328,"heroImage":1324,"date":1330,"body":1331,"category":14,"tags":1332},[1329],"Sharon Gaudin","2021-11-30","\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",[831,806,974],{"slug":1334,"featured":6,"template":681},"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":1340,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1341,"content":1347,"config":1352,"_id":1354,"_type":17,"title":1342,"_source":18,"_file":1355,"_stem":1356,"_extension":21},"/en-us/blog/situational-leadership-strategy",{"title":1342,"description":1343,"ogTitle":1342,"ogDescription":1343,"noIndex":6,"ogImage":1344,"ogUrl":1345,"ogSiteName":667,"ogType":668,"canonicalUrls":1345,"schema":1346},"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":1342,"description":1343,"authors":1348,"heroImage":1344,"date":1349,"body":1350,"category":14,"tags":1351},[911],"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",[831,974,1255],{"slug":1353,"featured":6,"template":681},"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":1358,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1359,"content":1365,"config":1370,"_id":1372,"_type":17,"title":1373,"_source":18,"_file":1374,"_stem":1375,"_extension":21},"/en-us/blog/the-top-skills-you-need-to-get-your-devops-dream-job",{"title":1360,"description":1361,"ogTitle":1360,"ogDescription":1361,"noIndex":6,"ogImage":1362,"ogUrl":1363,"ogSiteName":667,"ogType":668,"canonicalUrls":1363,"schema":1364},"The top skills you need to get your DevOps dream job or a higher salary","AI, ML, automation – time to learn these new tech skills to stay competitive and land the job or promotion you want.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664025/Blog/Hero%20Images/devopscareer.jpg","https://about.gitlab.com/blog/the-top-skills-you-need-to-get-your-devops-dream-job","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The top skills you need to get your DevOps dream job or a higher salary\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2021-11-17\",\n      }",{"title":1360,"description":1361,"authors":1366,"heroImage":1362,"date":1367,"body":1368,"category":14,"tags":1369},[1329],"2021-11-17","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nIf you’re looking to transform your job, [your salary](/blog/four-tips-to-increase-your-devops-salary/) and your ability to get a job with your dream company, there are some skills you need to add to your toolkit.\n\nDevOps is a rapidly changing field. Automation is booming. There’s an increasing focus on artificial intelligence (AI) and machine learning (ML), along with moving security to the left. And there’s a call to master an ever-growing list of programming languages. Face it, DevOps professionals need to be in a [constant learning mode](/blog/best-advice-for-your-devops-career-keep-on-learning/). If you’re picking up new expertise, you’re likely going to find yourself in a [coveted position](/blog/a-look-at-devops-salaries/) since companies are struggling to fill jobs with DevOps professionals who have the latest skills. \n\nSo what technologies should you consider adding to your toolbelt? Of course, you need to take stock of your own skill set, experiences and certifications, and compare all of that to what your company, or your dream company, might need. Here’s a helpful list of considerations.\n\n## Expand your programming languages\n\nSo when it comes to figuring out what programming languages you should know, it’s a lengthy list to cull through. What would most benefit your company? And what would benefit a potential employer?\n\nThe DevOps Institute noted in its [2021 Upskilling Enterprise DevOps Skills Report](https://info.devopsinstitute.com/2021-upskilling-report-download) that it’s smart for developers to make sure they don’t specialize in a single language. \n\nAccording to the [Stack Overflow survey](https://insights.stackoverflow.com/survey/2021), developers who are already working with other programming languages are most interested in learning [Python](/blog/beginner-guide-python-programming/), JavaScript and Go. And [Brendan O’Leary](https://gitlab.com/brendan), a staff developer evangelist, and product and engineering leader at GitLab, advised that developers should learn Go and [Rust](/blog/rust-programming-language/), which are both useful for building in memory safety.\n\nEven if you’re programming with a popular but common language like JavaScript or C++ currently, that doesn’t mean you can’t showcase other languages on your resume through contributions to open source projects or by [volunteering your coding time](https://www.donatecode.com).\n\n### Understand the role of automation\n\nThe DevOps Institute’s survey noted that automation tool knowledge is a “must-have.” And out of all the automation skills, the report listed the top five as continuous integration (78 percent), continuous delivery (77 percent), continuous deployment (72 percent), continuous operation and support (62 percent), and [DevSecOps](/topics/devsecops/) (56 percent). \n\nIf your current team’s process isn’t highly automated, don’t fear – there are lots of learning options to the rescue. A quick search on YouTube found more than [100 videos on continuous deployment](https://www.youtube.com/results?search_query=continuous+deployment), as just one example. Most large companies offer their own training tracks (and [we do too](/learn/)) and, of course, there are [lots of certification programs](/blog/best-advice-for-your-devops-career-keep-on-learning/) as well.\n\n### Bone up on other key DevOps skills\n\nThe third-highest ranked skill domain is technical skills, according to the DevOps Institute. It’s a broad category, but there are core technical skills, like having an understanding of cloud platforms, [CI/CD](/topics/ci-cd/) and monitoring, along with operating systems, containers, big data, data analysis and microservices that will be important to nearly any employer.\n\nIn our 2021 Global DevSecOps Survey, developers told us there were a lot of technologies they’d like to dig into, including GitOps, IoT/blockchain, cloud/cloud native, cross-platform development, low code, data science, Python and cryptography.\n\nThat tracks with what The DevOps Institute found; the top seven technologies that organizations plan to implement over the next two years include IT automation technology, Gigabit Wi-Fi networking, Internet of Things, virtual desktop infrastructure, converged/hyperconverged infrastructure, container technology and serverless computing. \n\n### Dig into security\n\nA developer who not only understands security but can write the tests and prioritize the fixes is going to be incredibly attractive to a DevOps team looking to shift security firmly to the left. Job swapping or shadowing the security team is one way to build this knowledge base. Finding the dev team’s [security champion](/blog/why-security-champions/) and doing what they do also works. Finally, there’s a practical and actionable podcast called [The Secure Developer](https://www.devseccon.com/the-secure-developer-podcast/) that offers advice from a wide variety of developer pros and security pros on how to up your security game.\n\n### Focus on AI and ML\n\nOur AI overlords are coming, so it’s best to be prepared. While we’re only sort of kidding, it’s completely clear that AI and ML are showing up in DevOps in a surprising variety of ways, including testing, analysis and monitoring. \n\nAI and ML are most likely to arrive first in the testing arena; our survey showed that 75 percent of teams are either using AI and ML or bots for testing and code review, or they’re planning to – up from 41 percent the year before. So that’s an obvious place to focus your energies. \n\n### Jump in and explore learning opportunities\n\nIt’s about continuous education. Whether your company offers you opportunities to earn new certifications and master new languages, or you have to DIY, you need to figure out a way to keep learning. Keep adding to your skill set and resume. \n\n“Continuing to educate yourself is critical,” said GitLab’s O’Leary. “There are always new technologies, new languages, new skills to be learned. Companies need someone who is flexible and can solve problems. Mastering new technologies is one of the more important things you can do for yourself.”\n\nCover image by [Green Chameleon](https://unsplash.com/@craftedbygc) on [Unsplash](https://unsplash.com).\n\n_Our [2022 Global DevSecOps Survey](/developer-survey/) has the latest insights from over 5,000 DevOps professionals. You can also compare it with [previous year surveys](/developer-survey/previous/)_\n",[831,806,722],{"slug":1371,"featured":6,"template":681},"the-top-skills-you-need-to-get-your-devops-dream-job","content:en-us:blog:the-top-skills-you-need-to-get-your-devops-dream-job.yml","The Top Skills You Need To Get Your Devops Dream Job","en-us/blog/the-top-skills-you-need-to-get-your-devops-dream-job.yml","en-us/blog/the-top-skills-you-need-to-get-your-devops-dream-job",{"_path":1377,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1378,"content":1384,"config":1389,"_id":1391,"_type":17,"title":1392,"_source":18,"_file":1393,"_stem":1394,"_extension":21},"/en-us/blog/best-advice-for-your-devops-career-keep-on-learning",{"title":1379,"description":1380,"ogTitle":1379,"ogDescription":1380,"noIndex":6,"ogImage":1381,"ogUrl":1382,"ogSiteName":667,"ogType":668,"canonicalUrls":1382,"schema":1383},"Best advice for your DevOps career? Keep on learning","If you want a new job, or a higher salary, or preferably both, add some skills to your DevOps resume. Here's a look at our strategy for DIY-ing your continuing ed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679473/Blog/Hero%20Images/designing-in-an-all-remote-company.jpg","https://about.gitlab.com/blog/best-advice-for-your-devops-career-keep-on-learning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Best advice for your DevOps career? Keep on learning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2021-11-09\",\n      }",{"title":1379,"description":1380,"authors":1385,"heroImage":1381,"date":1386,"body":1387,"category":14,"tags":1388},[1329],"2021-11-09","\nDevOps skills might be in demand, but it’s not the time to remain complacent if you want a new (and better) job or a higher salary. Luckily the best career move you can make is also the easiest: continue to add new skills, even if you have to DIY it. \n\n“I think continually educating myself has been really important in my career, and it’s been mostly DIY,” said said [Brendan O’Leary](https://gitlab.com/brendan), a staff developer evangelist, and product and engineering leader at GitLab. “It’s allowed me to make different career moves and advance my career by changing companies or by changing roles at my current company… Continuing to educate yourself is one of the most important things you can do.”\n\n## DevOps education: how to keep learning\n\nIt’s well known that continuing to educate yourself and pursuing certifications are two of the [top ways to increase your paycheck](/blog/four-tips-to-increase-your-devops-salary/), but here’s our best advice on how to bootstrap your learning journey without waiting for your employer.\n\n### Take responsibility for your own journey\n\nDon’t panic if your company is one of the many that doesn’t offer continuous education opportunities: According to the DevOps Institute’s 2021 Enterprise DevOps Skills Report, [52 percent of companies don’t](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). (To be transparent, GitLab was one of the partners in the Institute’s survey.)\n\n### Figure out what you, and your company, need\n\nMake sure you’re not learning about a new technology or tool because it’s the cool new thing. Focus your time and energy on learning something that actually will solve a problem or give your business a competitive edge. Keep your skills aligned with shifting business demands, learning enough about a new technology so you understand if it will solve a business problem. \n\nIn a sea of possibilities, there are some concrete learning options we can suggest. In our [2021 Global DevSecOps Survey](/developer-survey/), we asked respondents what skill or skills would be most important for their future career. A majority of developers said knowledge around artificial intelligence and machine learning would be critical, while ops team members wanted more advanced programming languages. Security pros, on the other hand, wanted to become subject matter experts in their industries. \n\n### Assessing your skills and deficits\n\nGauge your baseline of skills, experience and certifications. What comes naturally to you, and what is more of a struggle? Now compare your baseline to what your company needs, and then broaden it out to what the industry is looking for.\n\nOne easy way to broadly compare your skills to others is to look at a job search site like [Glassdoor.com](https://www.glassdoor.com). The job listings detail the skills, languages, experiences, technologies and other attributes an employer is looking for.\n\nWe randomly grabbed and anonymized a job posting for a DevOps engineer from Glassdoor, below. You’ll see how many boxes you’ll need to check (we bolded the key phrases just to make the point):\n\n_You will demonstrate a **leadership** mindset, solid **operational experience**, and the **ability to problem-solve**. Additionally, you should have exceptional **communication skills**, be knowledgeable about the latest industry trends, and be **highly innovative**. The DevOps Engineer will help enhance and maintain a **programmable infrastructure, configure, implement, debug and document new and existing applications running on Linux and Windows operating systems in private and public cloud infrastructures**. Engage in **design, development, installation, and system administration of build/continuous integration systems, anti-virus systems, and configuration management systems**. Participate in the full development life cycle of DevOps projects including **assessment of requirements, system analysis, and design.**_\n\n### Go to the source for certifications\n\nOf course, there are university classes but they can be pricey. You don’t always have to spend thousands of dollars on a college course. Go to the original source of what you want to learn, and let certifications be your friend. [A survey from the McKinsey Quarterly,](https://www.mckinsey.com/business-functions/mckinsey-accelerate/our-insights/five-fifty-the-skillful-corporation?cid=fivefifty-eml-alt-mkq-mck&hlkid=a7a8ae1b68574d02b81db1f1eeb8fd8d&hctky=12428831&hdpid=8233aa33-5ff4-4450-a4c7-2f47dfeaf9d0) noted that 66 percent of survey respondents called certifications “extremely valuable.”\n\nFor instance, if you’re using The GitLab Platform, you can get a [security certification](/services/education/gitlab-security-specialist/) from GitLab. There are also [certifications for](/learn/certifications/public/) everything from CI/CD training, to project management and Git basics. Similarly, if you need to bone up on Google Cloud, check out their site for [certifications](https://acloudguru.com/training-library/gcp-cloud-training?utm_campaign=11244863417&utm_source=google&utm_medium=cpc&utm_content=469352928666&utm_term=b_&adgroupid=115625160932&gclid=Cj0KCQjw5oiMBhDtARIsAJi0qk20jsoQ55oCnlbde3tozrDRExDxxiJ0AooFulqXXguwOX072-OwJNAaAjd3EALw_wcB).\n\n### Other opportunities to educate yourself\n\nYou also can find learning opportunities at a lot of conferences, coding events, bootcamps, hackathons and workshops. Especially in the time of COVID-19, think about taking advantage of online courses. [YouTube](https://www.youtube.com) is full of hands-on technical tutorials, including a lot from GitLab and other tech companies as well as consultants and individual contributors. Don’t forget GitLab Learn, where you can do a self-paced deep dive via video tutorials into a number of key DevOps areas, including [continuous integration (CI)](/features/continuous-integration/).\n\nAnd for female developers, organizations like [Women Who Code](https://www.womenwhocode.com/) offer scholarships, tutorials and educational materials.\n\nDon’t forget about mentorships. Find someone who has the knowledge and experience you need and ask them to work with you and bring you up to speed. Then don’t forget to later turn around and lend a hand to the person coming up after you.\n\nStay tuned for more information on what hard and soft skills you should consider adding to your resume.\n\n## Read more on DevOps careers: \n\n- [6 tips to make software developer hiring easier](/blog/6-tips-to-make-software-developer-hiring-easier/)\n\n- [Four tips to increase your DevOps salary](/blog/four-tips-to-increase-your-devops-salary/)\n\n- [DevOps salaries in 2021: Where do you rank?](/blog/a-look-at-devops-salaries/)\n\n- [Have DevOps jobs to fill? Try these 3 strategies to hire and retain](/blog/have-devops-jobs-to-fill-try-these-3-strategies-to-hire-and-retain/)\n",[831,806,832],{"slug":1390,"featured":6,"template":681},"best-advice-for-your-devops-career-keep-on-learning","content:en-us:blog:best-advice-for-your-devops-career-keep-on-learning.yml","Best Advice For Your Devops Career Keep On Learning","en-us/blog/best-advice-for-your-devops-career-keep-on-learning.yml","en-us/blog/best-advice-for-your-devops-career-keep-on-learning",{"_path":1396,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1397,"content":1402,"config":1408,"_id":1410,"_type":17,"title":1411,"_source":18,"_file":1412,"_stem":1413,"_extension":21},"/en-us/blog/get-the-most-out-of-a-ceo-shadow-program",{"title":1398,"description":1399,"ogTitle":1398,"ogDescription":1399,"noIndex":6,"ogImage":947,"ogUrl":1400,"ogSiteName":667,"ogType":668,"canonicalUrls":1400,"schema":1401},"15 tips to succeed at GitLab's CEO Shadow program","A CEO shadow program can be invigorating, but also intimidating. Here are strategies to help you make the most of the experience.","https://about.gitlab.com/blog/get-the-most-out-of-a-ceo-shadow-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"15 tips to succeed at GitLab's CEO Shadow program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Neil McCorrison\"}],\n        \"datePublished\": \"2021-11-02\",\n      }",{"title":1398,"description":1399,"authors":1403,"heroImage":947,"date":1405,"body":1406,"category":14,"tags":1407},[1404],"Neil McCorrison","2021-11-02","\n\nYou may already know that GitLab offers an incredible thing called the CEO Shadow program where anyone in the company is able to spend time with CEO and co-founder [Sid Sijbrandij](/company/team/#sytses). It's an opportunity to get a behind-the-scenes look at how our company functions. \n\nThere is a lot of [information](https://www.youtube.com/c/GitLabUnfiltered/search?query=ceo%20shadow) available about the program. But for anyone considering a CEO shadow program, either at [GitLab](/handbook/ceo/shadow/#alumni) or another company, here are 15 pieces of advice to get the most out of the experience.\n\n## 1. Take lots of notes\n\nI took copious notes in a separate document because there were so many interesting things that happened - things that I want to remember, follow up on and learn more about. I've heard other shadows have had a notepad handy. Also consider how to further leverage recordings. Even in a normally unrecorded session (like a 1:1), Sid may start a recording to capture fidelity above what notes alone provide. It's an amazing trick. \n\n## 2. Be open to anything\n\nSid asked about his presentation [energy score](https://blog.energybroker.ie/whats-your-personal-energy-rating), danced the [cabbage patch](https://en.wikipedia.org/wiki/Cabbage_Patch_(dance)) during a 1:1 to celebrate a win, and was able to match everyone's energy in a discussion. So make sure to bring that energy! Also, did you know we have a [songbook](/company/culture/songbook/) that everyone can contribute to?\n\n## 3. Make the most of breaks\n\nTen-hour days of back-to-back meetings are no joke. Take the [time to refresh](/handbook/ceo/shadow/#tips-for-remote-shadows) during the day when you have breaks. \n\n## 4. You won't be alone\n\nAt GitLab, you are one of two active shadows following the [\"see one, teach one\" rotation](/handbook/ceo/shadow/#rotation-rhythm). Expect to build a great partnership with your co-shadow.\n\n## 5. Be a good partner\n\nKeep your co-shadow visible in the Zoom gallery view. It’s nice to see body language cues. It’s important to constantly help each other out between note-taking and other tasks. \n\n## 6. Everyone can benefit from a coach\n\nSid has a coach to perfect his communication and presentation skills, and others can benefit from one as well. There are lots of resources available to GitLab employees that are highly recommended, including [Modern Health](/handbook/total-rewards/benefits/modern-health/).\n\n## 7. Keep your communications organized\n\nUtilize the [sidebar sections feature in Slack](/handbook/communication/#organizing-your-slack-sidebar-by-priority). Group the pertinent CEO Shadow channels and team members. You'll want to make sure you stay on top of those messages.\n\n## 8. Tame your schedule management software\n\nIf you have [Clockwise](/handbook/tools-and-tips/other-apps/#clockwise) installed, it will override your status in Slack and pause notifications (the `z` indicator). This can mean missing important messages depending on your configuration. You can disable this by running `cw settings` and pausing the status override.\n\n## 9. MRs are essential\n\nYes, [everything starts with an MR](/handbook/communication/#start-with-a-merge-request): Have a concern, idea or suggestion? It’s going to get more traction if you take a stab at drafting it through an MR first.\n\n## 10. Experiment with your screen layout\n\nNotes on the left or right? Place them at the top of your screen near the camera. It can be easy to sink into taking notes and forget that you are often live on YouTube. Check your video once in a while to check your posture, eye placement and lighting. Don't forget to smile!\n\n## 11. Time-keeping is important \n\nUse the [time-keeping shell script](/handbook/ceo/shadow/#keeping-time) to ensure meetings [end on time](/company/culture/all-remote/meetings/#start-on-time-end-on-time). It’s amazing, simple and something a lot of shadows continue to use after the program. \n\n## 12. Don't overthink taking notes\n\nDon’t try to understand context when someone starts talking. Just try to capture what they said accurately. Taking effective notes and having [live doc meetings](/company/culture/all-remote/live-doc-meetings/) are amazing skills that the shadow program will catapult you into. \n\n## 13. Listen carefully\n\nExpect to be asked for questions in or following [Valley meetings](/handbook/ceo/shadow/#valley-meetings). They are a unique opportunity and another great chance to participate.\n\n## 14. Early is the new on-time\n\nYou should always join a meeting a minute or two before. I found that doing this during the shadow program gave me extra time to chat with participants – and often Sid – before the main meeting started. \n\n## 15. Get a true glimpse at our core values\n\nYou'll see [transparency](https://handbook.gitlab.com/handbook/values/#transparency) at work. You'll see that our [E-group](/company/team/e-group/) is full of personable, down-to-earth people who thrive on collaboration. You'll hear iteration mentioned - a lot. Not because it's a buzzword, but because it's a highly effective way to develop software. \n\n> Sid said it best: \"Iteration is one of our super powers. It's super hard to do, but when you get it right, it's super effective. It allows you to innovate quickly.\"\n\n**[Join GitLab](/jobs/) and become a CEO Shadow yourself!**\n",[676,831,268],{"slug":1409,"featured":6,"template":681},"get-the-most-out-of-a-ceo-shadow-program","content:en-us:blog:get-the-most-out-of-a-ceo-shadow-program.yml","Get The Most Out Of A Ceo Shadow Program","en-us/blog/get-the-most-out-of-a-ceo-shadow-program.yml","en-us/blog/get-the-most-out-of-a-ceo-shadow-program",{"_path":1415,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1416,"content":1421,"config":1427,"_id":1429,"_type":17,"title":1430,"_source":18,"_file":1431,"_stem":1432,"_extension":21},"/en-us/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform",{"title":1417,"description":1418,"ogTitle":1417,"ogDescription":1418,"noIndex":6,"ogImage":947,"ogUrl":1419,"ogSiteName":667,"ogType":668,"canonicalUrls":1419,"schema":1420},"How ten steps over ten years led to the DevOps Platform","It's been ten years since the first commit to GitLab! Here's a look at ten critical choices that shaped us.","https://about.gitlab.com/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How ten steps over ten years led to the DevOps Platform\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n        \"datePublished\": \"2021-10-11\",\n      }",{"title":1417,"description":1418,"authors":1422,"heroImage":947,"date":1423,"body":1424,"category":14,"tags":1425},[802],"2021-10-11","\nThe first commit to GitLab (!!) was 10 years ago. Today, it’s an entirely different world: DevOps is increasingly mainstream and there's a DevOps platform revolution.\n\nWe didn’t have a crystal ball back then, but we did try to create a product, a culture and a company that reflected what we thought mattered most. Here’s a look back at 10 key decisions we made that still have impact:\n\n1. Work in parallel: When we started, it was clear the waterfall method of software development - where one stage waited on another stage and nothing happened independently - slowed everything. We decided right from the beginning that a “work in parallel” philosophy would be fundamental to our culture and our behaviors. Also, such a philosophy naturally supported everything else we did, including bringing CI and CD together and operating as an all-remote company. Working in parallel is also vital to success with DevOps.\n\n2. CI, meet git: To merge dev and ops you have to merge development and operations. We [weren’t really sure](/blog/gitlab-hero-devops-platform/) bringing CI together with a git repository was the right step to take, but we tried it and [it worked](/blog/beginner-guide-ci-cd/). Now, developers expect CI to be perfectly integrated into their daily work, and, more and more, they are using a DevOps platform to centralize CI and CD.\n\n3. Cloud native: We’ve been talking about Kubernetes and the options made possible by cloud-native development since [2017](/blog/containers-kubernetes-basics/). We’re true believers in supporting the ability to embrace cloud-native technology and patterns.  The concept of cloud native enables teams to deliver better software faster, break down their applications into microservices and focus engineering time on delivering value to their customers - not on maintaining brittle infrastructure.\n\n4. The mighty merge request: We doubled down on the idea of a merge request, making it the hub of absolutely everything. Merge requests are not only the gateway to production, but all the other critical steps, such as security checks, which can be found in there as well. Plus, the merge request serves as a living record of changes and is essential for [better code review](/blog/iteration-and-code-review/).\n\n5. Developer-first security: For developers to have ownership of security, they need scanning early in the process and results in their workflow. That’s why [developer-first security](/topics/devsecops/what-is-developer-first-security/) is at the heart of our DevOps Platform.\n\n6. A complete definition of security: Security isn’t a “one and done” effort and our DevOps Platform enables us to offer a broad spectrum of security scans that goes far beyond just SAST and DAST. From scanning for dependencies or looking at containers, we cover all the security bases in a single platform.\n\n7. All remote, all the time: With no corporate headquarters and employees in 65 countries and regions (as of October 2021), we’re [all remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/guide/) and proud of it. This decision transformed into a corporate value that has influenced our choices and behaviors. \n\n8. Asynchronous communication: A natural result of being remote, [asynchronous communication](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/) is something we take seriously. We’re a [“handbook first”](https://handbook.gitlab.com/handbook/company/culture/all-remote/handbook-first/) organization, meaning we write everything down so information is as self-service as possible. We also carefully consider what time is spent in meetings, limiting their frequency and regularly asking ourselves if “asynchronous” is better. This has allowed us to successfully have employees in nearly every time zone around the world and follow the working in parallel philosophy.\n\n9. Visibility: Planning is critical, but it’s equally important to pair it with visibility so everyone knows what’s happening and where it’s happening. Giving context for the original plan to all team members throughout the DevOps lifecycle, how the plan has changed, and what the implementation looks like in the end is a critical advantage to a single DevOps platform.  Without this, time is wasted trying to update multiple systems with issue status, or having conflicting information in independent tools. \n\n10. Measure the results: We firmly believe it’s important to know how the stages of the SDLC are going, in detail. After all, if you can’t measure your results, how can you know things are moving in the right direction? Many DevOps teams don’t or can’t measure, but that can make it difficult to convince management of the value of the methodology. A DevOps platform makes measurement easy.\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- [Making the case for a DevOps platform: What data and customers say](/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say/)\n\n- [Agile planning with a DevOps platform](/blog/agile-planning-with-a-devops-platform/)\n\n- [Welcome to the DevOps Platform era](/blog/welcome-to-the-devops-platform-era/)\n\n- [It's time to build more accessible software. A DevOps platform can help](/blog/how-the-devops-platform-makes-building-accessible-software-easier/)\n",[1426,806,676],"DevOps platform",{"slug":1428,"featured":6,"template":681},"how-ten-steps-over-ten-years-led-to-the-devops-platform","content:en-us:blog:how-ten-steps-over-ten-years-led-to-the-devops-platform.yml","How Ten Steps Over Ten Years Led To The Devops Platform","en-us/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform.yml","en-us/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform",{"_path":1434,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1435,"content":1441,"config":1448,"_id":1450,"_type":17,"title":1451,"_source":18,"_file":1452,"_stem":1453,"_extension":21},"/en-us/blog/optimizing-devops-visibility-in-gitlab-14",{"title":1436,"description":1437,"ogTitle":1436,"ogDescription":1437,"noIndex":6,"ogImage":1438,"ogUrl":1439,"ogSiteName":667,"ogType":668,"canonicalUrls":1439,"schema":1440},"Optimize DevOps with enhanced visibility tools in GitLab 14","How GitLab 14's end-to-end visibility and actionability can help users understand and improve delivery and alignment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665839/Blog/Hero%20Images/devops.png","https://about.gitlab.com/blog/optimizing-devops-visibility-in-gitlab-14","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Optimize DevOps with enhanced visibility tools in GitLab 14\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cormac Foster\"}],\n        \"datePublished\": \"2021-07-21\",\n      }",{"title":1436,"description":1437,"authors":1442,"heroImage":1438,"date":1444,"body":1445,"category":14,"tags":1446},[1443],"Cormac Foster","2021-07-21","\n[DevOps makes teams and work more efficient](/topics/devops/how-and-why-to-create-devops-platform-team/), more consistent, and more productive – but how much more?\n\nOn its surface, the answer is simple. We need to measure workflow from idea to delivery, identify and remove blockers, and benchmark improvements in a manner that is consistent and replicable. The challenge is the way we've typically built the systems that hold the data we're trying to understand.\n\nEnhanced visibility tools are essential to measuring and optimizing modern DevOps processes, and mapping the work output to ensure the business outcomes that matter are achieved.\n\n## The failure of DIY DevOps\n\nMost businesses operate and maintain a multi-product \"DIY DevOps\" toolchain, but stitched-together applications with bespoke integrations don't lend themselves to visibility. Each component in the toolchain captures a unique set of data, with distinct formatting and metadata, logged to a siloed data store. Extracting, correlating, and displaying that data is a labor intensive chore – assuming the various APIs allow proper access at all. Poor visibility can lead to slow and imprecise decision-making and misalignment between teams, but building and maintaining visibility in DIY toolchain saps resources from your business, adding work instead of removing it.\n\n## A platform for visibility\n\nAt GitLab, we believe that stumbling in the dark and maintaining complex toolchains are not viable business strategies. We all deserve better, and [GitLab 14](/gitlab-14/) is the [DevOps platform](/topics/devops-platform/) that provides enhanced visibility without added work. As a complete DevOps platform, GitLab 14 is uniquely capable of delivering visibility into DevOps processes, surfacing out-of-the-box insights from across the product delivery lifecycle and helps users understand what works, what doesn't, and how to make improvements.\n\n## Metrics that matter\n\n![Lead Time for Changes helps you understand your team's velocity, agility, and efficiency, from the first code commit to production.](https://about.gitlab.com/images/blogimages/lead_time.png){: .shadow}\nLead Time for Changes helps you understand your team's velocity, agility, and efficiency.\n{: .note.text-center}\n\nGitLab 14 delivers operational metrics to help users understand DevOps maturity and benchmark progress. The DevOps Research and Assessment (DORA) firm demonstrated how DevOps maturity leads to positive business outcomes like happier customers, greater market share, and increased revenue. They've outlined [four key metrics](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) that are highly correlated with business performance, and GitLab 14 surfaces two of the four. [Deployment Frequency](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts) charts help monitor the efficiency of deployments over time, find bottlenecks, and understand when and how to improve deployment process. [Lead Time for Changes](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#lead-time-charts) helps users understand their team's velocity, agility, and efficiency – from the first code commit to all the way through production.\n\n## Actionable insights\n\n![Value Stream Analytics lets you zero in on value blockers and immediately remediate them.](https://about.gitlab.com/images/blogimages/value_stream_analytics.png){: .shadow}\nValue Stream Analytics lets you zero in on value blockers and immediately remediate them.\n{: .note.text-center}\n\nAfter identifying opportunities for change, you should be able to take action right away with GitLab 14. Our [customizable Value Stream Analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html) tools allow teams to monitor specific workflows tailored to their particular needs and identify high-priority blockers to delivering value to customers.\n\nUnlike products that focus exclusively on visibility and discovery, GitLab 14 makes these insights actionable. With one click, users can move from identifying a merge request stuck in code review or an issue waiting for approval to solving the problem. Actionable insights removes wasteful loops of questions and clarifications, and allows all users to focus on productive work.\n\n## See for yourself\n\nWant to learn more? Learn how GitLab customers like [Crédit Agricole](/customers/credit-agricole/), [Hotjar](/customers/hotjar/),and [others](/customers/) are turning visiblity and and insights into business value, or take the next step and [try GitLab Ultimate for free](/free-trial/)!\n\nThis blog is part two in a three-part series on some of the top features of GitLab 14. Learn more about how GitLab 14 includes some of the [top Security features in part one](/blog/are-you-ready-for-the-newest-era-of-devsecops/). \n",[806,1447],"agile",{"slug":1449,"featured":6,"template":681},"optimizing-devops-visibility-in-gitlab-14","content:en-us:blog:optimizing-devops-visibility-in-gitlab-14.yml","Optimizing Devops Visibility In Gitlab 14","en-us/blog/optimizing-devops-visibility-in-gitlab-14.yml","en-us/blog/optimizing-devops-visibility-in-gitlab-14",{"_path":1455,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1456,"content":1461,"config":1467,"_id":1469,"_type":17,"title":1470,"_source":18,"_file":1471,"_stem":1472,"_extension":21},"/en-us/blog/are-you-ready-for-the-newest-era-of-devsecops",{"title":1457,"description":1458,"ogTitle":1457,"ogDescription":1458,"noIndex":6,"ogImage":1438,"ogUrl":1459,"ogSiteName":667,"ogType":668,"canonicalUrls":1459,"schema":1460},"Are you ready for the newest era of DevSecOps?","DevSecOps is about more than shifting security testing to developers. Can you secure your software development end-to-end?","https://about.gitlab.com/blog/are-you-ready-for-the-newest-era-of-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Are you ready for the newest era of DevSecOps?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2021-07-20\",\n      }",{"title":1457,"description":1458,"authors":1462,"heroImage":1438,"date":1464,"body":1465,"category":14,"tags":1466},[1463],"Cindy Blake","2021-07-20","\n\nSecurity is on everyone's radar, from board members to inquisitive grandparents. Everyone wants to know [what software development teams are doing to protect their applications](/blog/devops-platform-supply-chain-attacks/) from attacks like that of Colonial Pipeline, Solarwinds, and others. With the launch of [GitLab 14](/gitlab-14/), we accelerated modern DevOps by bringing velocity with confidence, built-in security, and visibility, into DevOps success.\n\nThe modern DevOps solution is platform-driven, has a unified data store, and has security embedded throughout the software development lifecycle (SDLC). We find that it is these three attributes that drive demand for a modern DevOps solution among many different types of businesses. \n\nSecurity in the modern DevOps solution 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\n## Shifting security left is just the beginning\n\nMany organizations have shifted security left, or at least started on their journey, in an effort to improve development velocity while also managing security risks. When starting with their incumbent tools, many organizations find it difficult to cobble together a variety of different security scanners and trying to integrate them into a complex DevOps toolchain. We hear from customers that siloed tooling has hindered collaboration. Many of our customers turned to GitLab to simplify their [DevSecOps](/topics/devsecops/) process. \n\nGitLab is often at the forefront of the DevSecOps and \"shift security left\" conversations among developers and businesses because of the simplicity and effectiveness of embracing security capabilities via a single platform. Developers need to find and fix vulnerabilities within their natural workflow earlier, without friction or distractions, while businesses must protect their IP in an age when the stakes of security have never been higher. \n\nWhen security capabilities are embedded into the end-to-end software processes, then developers can spend time writing code instead of managing tools. It is also easier for Development and Security teams to truly collaborate when they're working on the same platform. Also, security policies can be automated and applied consistently without intervention. As a result, GitLab customers have matured and scaled their application security programs in ways that were not possible with traditional siloed solutions. \n\nWe gathered quotes from GitLab customers about using GitLab Secure. These customers opted to stay anonymous as an added security measure. \n\n* [HackerOne](/customers/hackerone/) has reduced velocity disruptions while bringing predictability to their security costs as they scale their app sec programs. \n* A global financial services organization says, \"GitLab Secure replaced Veracode, Checkmarx, and Fortify in my DevOps toolchain. GitLab scans faster, is more accurate, and doesn't require my developers to learn new tools.\" \n* A large North American grocery retailer says, \"GitLab Secure gives us unlimited scanning capability across our entire GitLab repo. This is obviously a very \"shift-left\" move as issues will be identified directly in the repo for review and triage. We will be able to get the most coverage this way ...\". \n\nIn addition, we are excited that GitLab customer, HERE Technologies, has [shared their experience](https://developer.here.com/blog/shifting-security-left-in-the-here-platform) with using GitLab to Shift Left and will present at [Commit](/events/commit/), GitLab's upcoming user conference, August 3-4. Be sure to attend for the live Q&A.\n\nBeyond just empowering developers, GitLab's security dashboard and vulnerability report have evolved into powerful tools for security pros. The vulnerability report offers streamlined vulnerability management integrated into the GitLab workflow for earlier risk visibility, simplified vulnerability tracking, and easier remediation. Be sure to catch [Lindsey Kerr](/company/team/#lkerr), frontend engineering manager for GitLab Secure, at [Commit](/events/commit/) where she will share more about the evolution of our vulnerability management capabilities.\n\n## Security must be part of the DevOps platform\n\nIn an era of attacks that focus on software supply chains, it's not enough to just find and fix security vulnerabilities earlier in the SDLC. Shifting security left is still a vital element, but even more is required. For DevSecOps 2.0, integration and simplification is necessary for success, and we must also test, monitor, and protect the security of an application's surrounding infrastructure. This infrastructure, which usually accompanies cloud native apps, relies upon containers and orchestrators with configurations that are themselves codified as Infrastructure-as-code (IaC). We will cover securing IaC on the second day of the [GitLab Commit conference](/events/commit/). Attend and judge, are you ready for DevSecOps 2.0?\n\n## What's important looking ahead?\n\nBuilt-in security has become a prerequisite to not only automate a comprehensive security scanning process but also automate the policies and actions taken when exceptions are found. A recent blog post describes [how a platform can help with supply chain attacks](/blog/devops-platform-supply-chain-attacks/). With all eyes on the security of the software supply chain, it's even more important to have [end-to-end visibility and controls](https://docs.gitlab.com/ee/administration/compliance) to help protect the software factory along with its deliverables. Compliance management is a key part of DevSecOps 2.0. Check out [where GitLab is headed](/direction/govern/compliance/compliance-management/) and contribute your thoughts and feedback to the [top issues](/direction/govern/compliance/compliance-management/#top-user-issues).  \n\nThis is part one of a three-part series on some of the key features of [GitLab 14](/gitlab-14/). Check the GitLab Blog to learn more about how GitLab 14 powers greater visibility in part two of the series.\n\n\n\n\n\n",[894],{"slug":1468,"featured":6,"template":681},"are-you-ready-for-the-newest-era-of-devsecops","content:en-us:blog:are-you-ready-for-the-newest-era-of-devsecops.yml","Are You Ready For The Newest Era Of Devsecops","en-us/blog/are-you-ready-for-the-newest-era-of-devsecops.yml","en-us/blog/are-you-ready-for-the-newest-era-of-devsecops",{"_path":1474,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1475,"content":1481,"config":1487,"_id":1489,"_type":17,"title":1490,"_source":18,"_file":1491,"_stem":1492,"_extension":21},"/en-us/blog/2021-devsecops-survey-the-great-shift-left-continues",{"title":1476,"description":1477,"ogTitle":1476,"ogDescription":1477,"noIndex":6,"ogImage":1478,"ogUrl":1479,"ogSiteName":667,"ogType":668,"canonicalUrls":1479,"schema":1480},"Looking for a DevSecOps maturity model that works? Start with our 2021 Global Survey","72% of security pros rated their organizations’ security efforts as “strong” or “good.” Could 2021 be the year DevSecOps becomes a reality?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678388/Blog/Hero%20Images/advanced-devsecops-practices.jpg","https://about.gitlab.com/blog/2021-devsecops-survey-the-great-shift-left-continues","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Looking for a DevSecOps maturity model that works? Start with our 2021 Global Survey\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2021-05-18\",\n      }",{"title":1476,"description":1477,"authors":1482,"heroImage":1478,"date":1484,"body":1485,"category":14,"tags":1486},[1483],"Chrissie Buchanan","2021-05-18","\n\nOur [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals.\n\nIn our 2021 Survey, 4300 people told us about their successes and their challenges, but in some ways the biggest takeaway were the signs of a burgeoning DevSecOps maturity model. Somehow, when Covid and [DevOps](/topics/devops/) collided, big things started to happen particularly around DevSecOps.\n\n## Yes, Virginia, there is a DevSecOps\n\nMore teams are doing DevSecOps than ever before – and doing it well. Fully 72% of security professionals rated their organizations' security efforts as \"strong\" or \"good,\" a significant increase from 59% the year before. This shows us that investments in security and the cultural shifts from DevOps to DevSecOps are paying off.\n\n## That's right, we're shifting left\n\n![Anonymous DevSecOps survey response](https://about.gitlab.com/images/blogimages/devsecops-survey-quote.png){: .medium.left.wrap-text}\n\nOver 70% of security pros said their teams have shifted left and moved security earlier into the development lifecycle. So who's in charge? That's still an open question in this new DevSecOps maturity model. Almost 31% of security pros told us **they** were the ones in charge, but 28% said *everyone* that was responsible, almost identical to last year's survey. And when it came to finding bugs, 77% of security pros admitted to being the exterminators in their org (not devs) after code is merged in a test environment. \n\nSo how is it shifting left? While there are some conflicting responses (Devs! Security! Devs! Security!) – the truth is probably somewhere in the testing.\n\n## The SAST and the furious\n\nIn this new DevSecOps maturity model there is simply more testing (and that's never a bad thing). Today, 53% of developers run SAST scans (a 13% increase from last year) and 44% run DAST scans (a 17% increase from last year). Better yet, over 50% of security pros report their devs scan containers, run dependency scans, and do license compliance checks. That's all excellent news! So all testing issues are solved, right? Well, not exactly.\n\nSecurity testing remains a sticking point. While security pros agreed that their teams are shifting left, testing still happens too late in the process (over 42%), and it's still was a struggle to fix vulnerabilities. While security is finding most of the bugs, almost 37% of them said it was tough to track the status of the bug fixes, and 33% said it was hard to prioritize the remediations. Finally, 32% said just finding someone to fix the problems was a headache too.\n\n![DevSecOps survey results](https://about.gitlab.com/images/blogimages/devsecops-survey-2.png){: .medium.center}\n\nIn spite of everything thrown at them over the last year, DevOps teams are innovating and collaborating on problems like never before, and this year's DevSecOps survey results are showing just how far we've come. Still, there are opportunities for growth and security challenges left to solve. \n\nOur 2022 GitLab DevSecOps Survey has the latest insights from over 5,000 DevOps professionals. [Download the report](/developer-survey/) and learn about the practices and processes that are shaping the way we deliver software. You can also compare it with [previous year surveys](/developer-survey/previous/)\n",[722,894],{"slug":1488,"featured":6,"template":681},"2021-devsecops-survey-the-great-shift-left-continues","content:en-us:blog:2021-devsecops-survey-the-great-shift-left-continues.yml","2021 Devsecops Survey The Great Shift Left Continues","en-us/blog/2021-devsecops-survey-the-great-shift-left-continues.yml","en-us/blog/2021-devsecops-survey-the-great-shift-left-continues",{"_path":1494,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1495,"content":1501,"config":1506,"_id":1508,"_type":17,"title":1509,"_source":18,"_file":1510,"_stem":1511,"_extension":21},"/en-us/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen",{"title":1496,"description":1497,"ogTitle":1496,"ogDescription":1497,"noIndex":6,"ogImage":1498,"ogUrl":1499,"ogSiteName":667,"ogType":668,"canonicalUrls":1499,"schema":1500},"Why software developer job satisfaction matters and how to make it happen","Science has proven happier developers are more productive. It’s time to take software developer job satisfaction seriously – here’s how the right combo of culture and tools, i.e., a DevOps platform, can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663975/Blog/Hero%20Images/devsecopssurvey.png","https://about.gitlab.com/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why software developer job satisfaction matters and how to make it happen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-05-13\",\n      }",{"title":1496,"description":1497,"authors":1502,"heroImage":1498,"date":1503,"body":1504,"category":14,"tags":1505},[890],"2021-05-13","\nIn the midst of a global pandemic and an ongoing worldwide shortage of coders, software developer job satisfaction has never been more important. But to managers, and their teams, happiness can certainly feel elusive, hard-to-measure, and difficult to achieve.\n\nBut there’s no question it’s a worthwhile goal, and you don’t have to look further than science for proof of that. Two years ago authors Daniel Graziotin and Fabian Fagerholm [studied more than 1300 developers](https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_10) to rate their happiness, assess factors that make them unhappy, and to see if software developer job satisfaction was truly linked to improved productivity. The duo used the Scale of Positive and Negative Experience (SPANE) and their results were published in [_Rethinking Productivity in Software Engineering_](https://link.springer.com/book/10.1007/978-1-4842-4221-6).\n\nTheir findings were surprisingly straightforward: Coders were a \"moderately happy\" group, as a whole, and were made unhappy by three primary things: being stuck while problem solving, time pressure, and working with bad code or with poor coding processes. A fourth reason related to information overload. \"(The)...current software tools may overload developers with information,\" the study found. The research went on to outline how unhappy developers were less productive, suffered from \"broken flow,\" had less motivation, and produced low quality code. And finally, after two different psychological tests done in labs, the authors were able to declare definitively that \"happy software developers are indeed more productive.\"\n\n## Get happy, but how?\n\nNow that science has validated what we *felt* had to be true all along, it’s time to step back and consider the factors that play into software developer job satisfaction.\n\nA good place to start is with the development process. In our [2021 Global DevSecOps Survey](/developer-survey/), we found almost 36% of respondents said their teams are doing DevOps or DevSecOps, up from 27% in 2020. And there’s a reason why DevOps is so popular: it’s not only most likely to yield better code quality and faster time to market but it also adds to developer job satisfaction. In fact, more than 13% of respondents said [DevOps](/topics/devops/) makes developers  happier or makes their team more attractive to potential new employees.\n\nBut one of the realities of DevOps is tools...lots of them. In our survey, 38% of respondents used five tool chains while nearly 28% used between five and 10 (and 56% said there were an average of five tools on each tool chain.) Five tool chains with five tools each means teams are dealing with 25 tools – that’s certainly building a case for information overload and potentially *very unhappy* developers.\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## The beauty of less\n\nSo if DevOps, streamlined, is the key to software developer job satisfaction, the answer is obvious: Adopting a DevOps platform that brings tools together in a single application for collaboration, visibility, and development velocity makes for happier devs.\n\nOur survey respondents seemed to agree. When we asked about the benefits of a DevOps platform, the answers were clear: Better DevOps overall, improved collaboration, easier automation, and visibility/traceability. Here’s what they said:\n\n_\"Reduced mean time to recovery (MTTR), quicker time to market, reduced lead time for fixes, and fewer change failures.\"_\n\n_\"More ownership of everything to do with the product.\"_\n\n_\"Reliability, repeatability, consistency, productivity.\"_\n\nIf it’s time for more efficient DevOps (and of course happier developers), take our quiz to understand your level of DevOps platform maturity. And if you want to understand the heavy toll too many tools can take on your team, dive into [how to avoid the DevOps tax](/topics/devops/use-devops-platform-to-avoid-devops-tax/).\n",[722,806,268],{"slug":1507,"featured":6,"template":681},"why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen","content:en-us:blog:why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen.yml","Why Software Developer Job Satisfaction Matters And How To Make It Happen","en-us/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen.yml","en-us/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen",{"_path":1513,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1514,"content":1520,"config":1525,"_id":1527,"_type":17,"title":1528,"_source":18,"_file":1529,"_stem":1530,"_extension":21},"/en-us/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook",{"title":1515,"description":1516,"ogTitle":1515,"ogDescription":1516,"noIndex":6,"ogImage":1517,"ogUrl":1518,"ogSiteName":667,"ogType":668,"canonicalUrls":1518,"schema":1519},"The software testing life cycle in 2021: A more upbeat outlook","When DevOps teams trip, it's almost always over software testing. But in our 2021 survey we found some signs the software testing life cycle might finally be moving forward.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664041/Blog/Hero%20Images/open-devops.png","https://about.gitlab.com/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The software testing life cycle in 2021: A more upbeat outlook\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-05-06\",\n      }",{"title":1515,"description":1516,"authors":1521,"heroImage":1517,"date":1522,"body":1523,"category":14,"tags":1524},[890],"2021-05-06","\nOur [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals.\n\nThe software testing life cycle can feel like the [DevOps](/topics/devops/) punching bag, and for good reason: For the last three years, [our annual survey participants have unanimously named/blamed test as the number one reason for release delays](/blog/what-blocks-faster-code-release/). In our latest survey, participants had some very pointed commentary about the software test life cycle:\n\n> \"Testing can be both slow in writing and running.\"\n>\n> \"Testing is not yet fully automated in the deployment cycle; hoping to improve that with our move from BitBucket + Jenkins/drone to GitLab.\"\n>\n> \"Testing delays everything.\"\n>\n> \"Some software delivery teams have delegated their testing to QA personnel instead of writing comprehensive end-to-end testing suites. These teams suffer from very long (several days) bottlenecks in shipping to production.\"\n\nBut for all the complaints, our [2021 Global DevSecOps Survey](/developer-survey/) did find some signs that the software test life cycle, like many other components of DevOps, is beginning to mature. For starters, almost 25% of survey respondents said they’ve achieved [full test automation](https://www.softwaretestinghelp.com/automation-testing-tutorial-1/), more than double the number reported last year. And 28% said their teams are at least halfway to full test automation.\n\n## Changing roles\n\n[In our 2020 survey](/developer-survey/previous/2020/) we found DevOps roles are changing, and this year that pattern seems to be continuing, even in testing. Roughly 34% of participants said devs are testing their own code (up from 31% last year) and 32% said code is tested as it’s written, a significant bump from 25% last year.\n\nAt the same time though, when we asked devs what they need to be **doing more of** the vast majority of responses mentioned testing, whether it was pen, smoke, A/B, manual or simply test automation. For all the forward momentum, 25% of teams are either just beginning to consider test automation or have none at all. \n\nAn improving picture, but testing is simply irritating to some of our respondents:\n\n> \"Automated testing is ignored ‘due to time constraints.’\"\n>\n> \"Testing? That's an interesting idea.\"\n>\n> \"We intended to do test-driven development (TDD) but it usually ends up being after the fact.\"\n>\n> \"I try to write my code with TDD when it's possible; it's complicated when writing React components, or when changing a function that is not tested with many side effects and many inputs and the tech lead forbids (me) to refactor it at the moment .... ='(.\"\n\n## A potential game-changer\n\nAlthough it sounds like *Space Odyssey* meets DevOps, there is another reason for optimism around software testing: [Artificial intelligence/machine learning](/blog/ai-in-software-development/) is on the rise now and what could be more perfect than bots running endless tests? Bots can be deployed in the thousands and they don’t take vacations, or even lunch breaks. \n\nThe appeal of endless testing was clear in [our survey responses this year](/developer-survey/). Just over 41% of respondents told us bots were testing their code and/or [AI/ML](/blog/ai-in-software-development/) was reviewing code before human intervention. That’s up dramatically from just 16% last year. All told, 25% of respondents use bots to test their code, 16% use AI/ML to review code before a human sees it, and 34% are exploring the idea of AI/Ml but haven’t done anything about it yet. Exactly one-quarter of respondents aren’t using AI/ML in test.\n\nSoftware testing is just one small part of what DevSecOps Survey covers. Our [2022 Global DevSecOps Survey](/developer-survey/) has the latest insights from over 5,000 DevOps professionals.\n",[722,806,894],{"slug":1526,"featured":6,"template":681},"the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook","content:en-us:blog:the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook.yml","The Software Testing Life Cycle In 2021 A More Upbeat Outlook","en-us/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook.yml","en-us/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook",{"_path":1532,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1533,"content":1538,"config":1543,"_id":1545,"_type":17,"title":1546,"_source":18,"_file":1547,"_stem":1548,"_extension":21},"/en-us/blog/gitlabs-2021-survey-uncovers-a-new-devops-maturity-model",{"title":1534,"description":1535,"ogTitle":1534,"ogDescription":1535,"noIndex":6,"ogImage":1517,"ogUrl":1536,"ogSiteName":667,"ogType":668,"canonicalUrls":1536,"schema":1537},"GitLab's 2021 Survey uncovers a new DevOps maturity model","Our 2021 Global DevSecOps Survey found dramatic advances in DevOps maturity including faster release/deployment cycles, increased automation and improved security postures.","https://about.gitlab.com/blog/gitlabs-2021-survey-uncovers-a-new-devops-maturity-model","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's 2021 Survey uncovers a new DevOps maturity model\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-05-04\",\n      }",{"title":1534,"description":1535,"authors":1539,"heroImage":1517,"date":1540,"body":1541,"category":14,"tags":1542},[890],"2021-05-04","\n_Our 2022 GitLab DevSecOps Survey has the latest insights from over 5,000 DevOps professionals. Download and [read the full survey](/developer-survey/)._\n\nIn the midst of a global pandemic and a new way of working, teams got serious about what matters most, creating what amounts to a new [DevOps maturity model](/stages-devops-lifecycle/). GitLab’s  just-released 2021 Global DevSecOps Survey found sharp increases in automation, release cadences, continuous deployments, and security postures, as well as a growing reliance on cutting edge technologies, including artificial intelligence and machine learning. Nearly 4300 people shared their struggles and successes, and demonstrated a commitment to DevOps maturity like we’ve never seen before.\n\nWhat does this new DevOps maturity model look like? Well for one thing, it looks like it’s working. We think the year over year growth statistics speak for themselves:\n\n* 60% of developers are releasing code 2x faster than before, thanks to DevOps – up 25% from (pre-pandemic) 2020.\n* 72% of security pros rated their organizations’ security efforts as “good” or “strong” – up 13% over 2020.\n* 56% of ops teams members said they are “fully” or mostly automated – up 10% from 2020.\n* Almost 25% of respondents claimed to have full test automation – up 13% from 2020.\n* 75% of teams are either using AI/ML or bots for test/code review, or they’re planning to – up 41% from 2020.\n* Last year dev, sec, and ops said they needed [better communication and collaboration skills](/blog/collaboration-communication-best-practices/) for their future careers. This year, after an intense period of enforced soft skills, their priorities have shifted dramatically to AI/ML (devs), subject matter expertise (sec), and advanced programming (ops). \n\n## A 2021 DevOps maturity model\n\nAs we found in last year’s survey, [DevOps roles continue to change](/blog/software-developer-changing-role/), with developers taking on tasks usually associated with test and ops, ops focusing on the cloud and infrastructure, and security continuing to be part of cross-functional teams. The evolving nature of DevOps is hardly surprising: Fully 43% of our survey respondents have been doing DevOps for between three and five years - that’s the sweet spot where they’ve known success and are well-seasoned. But that “sweet spot” didn’t keep them complacent. This was also the year where practitioners skipped incremental improvements and reached for the big guns: SCM, CI/CD, test automation, and a [DevOps platform](/solutions/devops-platform/) were the most popular additions to their DevOps practices. \n\nWhy do teams strive for a DevOps maturity model? Code quality, faster time to market and improved security were the top three reasons.\n\nTesting remains the DevOps problem child – for the third year in a row participants said test is the most likely reason for release delays. There is some light at the end of the tunnel, though: not only has the percentage of teams with full test automation more than doubled year over year, a growing number of teams are either already using or plan to use AI/ML. Industry experts believe [AI/ML could revolutionize software testing](\u003Chttps://insidebigdata.com/2021/01/27/how-ai-and-machine-learning-will-shape-software-testing/>), and our survey participants apparently agree. \n\nAlso feeling the love in the survey were advanced technologies like Kubernetes. In our [2020 survey](/blog/devsecops-survey-released/), only 38% of survey takers used Kubernetes; this year the percentage jumped to 46% and even participants not using K8s currently said they planned to soon.\n\n## Looking to the future\n\nLast year our survey takers planned to focus on basics like automation, CI/CD and overall DevOps. But it’s 2021 now, and those efforts toward a new DevOps maturity model have paid off. This year participants plan to invest in the cloud, followed by [artificial intelligence](/blog/ai-in-software-development/). Last year, AI rated only a very distant 8th place. \n\nOur 2022 GitLab DevSecOps Survey has the latest insights from over 5,000 DevOps professionals. Download and [read the full survey](/developer-survey/).\n",[722,806,894],{"slug":1544,"featured":6,"template":681},"gitlabs-2021-survey-uncovers-a-new-devops-maturity-model","content:en-us:blog:gitlabs-2021-survey-uncovers-a-new-devops-maturity-model.yml","Gitlabs 2021 Survey Uncovers A New Devops Maturity Model","en-us/blog/gitlabs-2021-survey-uncovers-a-new-devops-maturity-model.yml","en-us/blog/gitlabs-2021-survey-uncovers-a-new-devops-maturity-model",{"_path":1550,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1551,"content":1557,"config":1562,"_id":1564,"_type":17,"title":1565,"_source":18,"_file":1566,"_stem":1567,"_extension":21},"/en-us/blog/migrate-from-jenkins-update",{"title":1552,"description":1553,"ogTitle":1552,"ogDescription":1553,"noIndex":6,"ogImage":1554,"ogUrl":1555,"ogSiteName":667,"ogType":668,"canonicalUrls":1555,"schema":1556},"How we're improving migrations from Jenkins to GitLab CI/CD","Learn more about our Jenkins Importer category and see what's in the works for easier Jenkins migrations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679556/Blog/Hero%20Images/insights.png","https://about.gitlab.com/blog/migrate-from-jenkins-update","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we're improving migrations from Jenkins to GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-12-08\",\n      }",{"title":1552,"description":1553,"authors":1558,"heroImage":1554,"date":1559,"body":1560,"category":14,"tags":1561},[1483],"2020-12-08","\nTeams that want to migrate from Jenkins to [GitLab CI/CD](/topics/ci-cd/) can run into roadblocks in the migration process. After all, going from a complicated plugin environment to GitLab CI/CD isn't exactly an apples to apples comparison. Teams that want to make the switch to GitLab will need help to ease the transition – so what are we doing to make that transition easier?\n\nWe created a Jenkins Importer category direction to bring together documentation and issues around improving the Jenkins migration process. We'll go over a few of the projects that are in progress and our vision for the future of Jenkins migrations.\n\n## What is the Jenkins Importer category?\n\nThe [Jenkins Importer](/direction/verify/jenkins_importer/) category is a collection of tools and documentation to help teams migrate from their Jenkins environment to GitLab CI/CD as easily as possible. Since we're a company that works [public by default](https://handbook.gitlab.com/handbook/values/#public-by-default), we use these category direction pages for information related to upcoming products, features, and functionality, not necessarily for purchasing or planning purposes.\n\nUltimately, our goal is to make at least 80% of the automated tasks easy. Having a Jenkins Importer category helps us organize issues and epics around helping unblock teams from migrating to GitLab CI/CD. This category is currently at a \"minimal\" [level of maturity](/direction/maturity/), meaning the features might be available in the product but are not necessarily in production yet.\n\nWith our work being public, you can see our progress and make contributions or comments on these issues.\n\n## Jenkins Importer: Top priority\n\nOur main epic is about [implementing a wrapper](https://gitlab.com/groups/gitlab-org/-/epics/2779) around the Jenkinsfile Runner. A wrapper is all about creating a minimum viable change (MVC) that will enable teams to run their Jenkins stack within GitLab while they complete their migration.\n\nConverting a complicated Jenkins enterprise environment into GitLab can be especially complex. For some Jenkins users, they may have thousands of pipelines that need to be converted. The idea of a wrapper came from [a comment](https://gitlab.com/groups/gitlab-org/-/epics/2735#note_295172334) on a different issue around improving our [Jenkins migration documentation](https://docs.gitlab.com/ee/ci/migration/jenkins.html). This process can be used to run Jenkins builds in GitLab CI while migrating Jenkinsfiles to the GitLab CI/CD syntax.\n\n## Migrating from Jenkins: Other works in progress\n\nAs we continue to receive feedback from the community and [conduct research](https://gitlab.com/gitlab-org/ux-research/-/issues/765) on use cases, those findings will impact the maturity of this category. While we're focusing on a wrapper because it will have the most initial value, we have other vision items for the Jenkins Importer category as well, which are summarized below.\n\n### Importer for declarative and imperative Jenkins configuration\n\nThis [first issue is a proposal to write a tool](https://gitlab.com/gitlab-org/gitlab/-/issues/208276) that can read the newer declarative or imperative syntax (as opposed to JenkinsFiles, a Groovy DSL) and convert it to a valid `.gitlab-ci.yml` file.\n\n### Importer for scripted Jenkins configuration\n\nThis [second issue is a proposal for a translator](https://gitlab.com/gitlab-org/gitlab/-/issues/208275) that can turn scripted Jenkinsfiles written in Groovy into a YAML syntax.\n\nAt GitLab, everyone can contribute. If this category interests you and you'd like to know how we're making migrations easier, feel free to comment on the public issues. If you're interested in helping GitLab test the Jenkins wrapper, join our [public testing issue](https://gitlab.com/gitlab-org/gitlab/-/issues/215675) for instructions and to provide your feedback.\n\nLearn more about the benefits of single application CI/CD and see how GitLab and Jenkins compare head-to-head.\n\nCover image by [Kenrick Mills](https://unsplash.com/@kenrickmills?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/migrate?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[1193,1194],{"slug":1563,"featured":6,"template":681},"migrate-from-jenkins-update","content:en-us:blog:migrate-from-jenkins-update.yml","Migrate From Jenkins Update","en-us/blog/migrate-from-jenkins-update.yml","en-us/blog/migrate-from-jenkins-update",{"_path":1569,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1570,"content":1575,"config":1580,"_id":1582,"_type":17,"title":1583,"_source":18,"_file":1584,"_stem":1585,"_extension":21},"/en-us/blog/pre-filled-variables-feature",{"title":1571,"description":1572,"ogTitle":1571,"ogDescription":1572,"noIndex":6,"ogImage":947,"ogUrl":1573,"ogSiteName":667,"ogType":668,"canonicalUrls":1573,"schema":1574},"How pre-filled CI/CD variables will make running pipelines easier","Learn more about this future release and how pre-filled variables will save time and reduce errors.","https://about.gitlab.com/blog/pre-filled-variables-feature","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How pre-filled CI/CD variables will make running pipelines easier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-12-02\",\n      }",{"title":1571,"description":1572,"authors":1576,"heroImage":947,"date":1577,"body":1578,"category":14,"tags":1579},[1483],"2020-12-02","\n[CI/CD variables](/topics/ci-cd/) are a useful way to customize pipelines based on their environment. But what if you need to override a variable, or what if you need to run a pipeline manually? These scenarios can create problems.\n\n*   What if you don’t know what variables/values to put in?\n*   What happens if you make a mistake?\n\nHaving to enter variables and values manually is tedious and prone to error. Also, a user may not know all the different variables/values they need to enter. In GitLab 13.7, we’re introducing a feature that helps to solve these problems by generating pre-filled variables from your `.gitlab-ci.yml.` file when you run a pipeline.\n\n### What are CI/CD variables?\n\n[CI/CD variables](https://docs.gitlab.com/ee/ci/variables/) are dynamic values assigned to environments. These environment variables affect the way running processes behave on an operating system. Variables allow teams to customize jobs in GitLab CI/CD.\n\nThere are two places where teams can define variables:\n\n*   The `.gitlab-ci.yml.` file\n*   The GitLab Runner `config.toml.` file\n\nCI/CD variables can be very useful, but what if you need to override a variable or manually run a pipeline? You might do this if the results of a pipeline (for example, a code build) are required outside the normal operation of the pipeline. Teams may also opt for manual deployments to production and need to stop the pipeline early. Running a pipeline manually isn’t unusual, but [defining variables](https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html) and entering them in a manual pipeline hasn’t always been a totally smooth process.\n\nFirst, teams need to run a pipeline/job manually and then navigate into the overview. Then, they have to select all the required variables from a drop-down menu on the “Run Pipeline” page. If developers don’t know all the required variables by heart, they will need to check their references and switch back and forth. If there are numerous key/value pairs to enter, this can be especially tedious. \n\n### What are pre-filled variables?\n\nIn 13.7, we’re introducing a feature that will streamline this process. Now the “Run pipeline” form will [generate pre-filled variables](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) for your pipeline based on the variable definitions in your `.gitlab-ci.yml` file. The response to this feature from the GitLab community was enthusiastic.\n\n![pre-filled variables issue](https://about.gitlab.com/images/blogimages/pre-filled-variables.png)\nPeople are excited about pre-filled variables!\n\n### The benefits of pre-filled variables\n\nHaving variables pre-filled is all about increasing efficiency and reducing the small frustrations that make jobs more difficult than they need to be. \n\nPre-filled variables will *reduce:*\n\n*   Frustration with scrolling dropdown values\n*   Friction with choosing the wrong values\n*   Re-running and debugging pipelines due to wrong values\n*   Errors and click actions\n\n![Run Pipeline](https://about.gitlab.com/images/blogimages/Run-pipeline.gif)\nPre-filled variables in action\n\nFor teams that manually deploy to production, pre-filled variables will make it easier during that review step so that everyone with permissions can manually trigger the deployment pipeline. If the reviewer needs to make an exception they can override a variable, if necessary. \n\nPre-filled variables will help teams save time, reduce errors, and make the manual pipeline process a bit smoother. Do you think we're missing something or have ways that we can streamline the process even further? Leave a comment in [the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) and let us know what you think. Everyone can contribute.\n\n### Other future GitLab CI releases\n\nPre-filled variables are only one CI feature in the works. We release [new features](/upcoming-releases/) on the 22nd of every month, and everyone can contribute to these [public](https://handbook.gitlab.com/handbook/values/#public-by-default) issues. \n\n## More on CI/CD\n\n- [Want a more effective CI/CD pipeline? Try our pro tips](/blog/effective-ci-cd-pipelines/)\n- [Webcast: 7 CI/CD hacks](/webcast/7cicd-hacks/)\n- [How to use GitLab’s CI/CD pipeline templates](/blog/get-started-ci-pipeline-templates/)\n\nCover image by [Gerrie van der Walt](https://unsplash.com/photos/m3TYLFI_mDo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/pipes?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[110,995],{"slug":1581,"featured":6,"template":681},"pre-filled-variables-feature","content:en-us:blog:pre-filled-variables-feature.yml","Pre Filled Variables Feature","en-us/blog/pre-filled-variables-feature.yml","en-us/blog/pre-filled-variables-feature",{"_path":1587,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1588,"content":1594,"config":1599,"_id":1601,"_type":17,"title":1602,"_source":18,"_file":1603,"_stem":1604,"_extension":21},"/en-us/blog/cncf-five-technologies-to-watch-in-2021",{"title":1589,"description":1590,"ogTitle":1589,"ogDescription":1590,"noIndex":6,"ogImage":1591,"ogUrl":1592,"ogSiteName":667,"ogType":668,"canonicalUrls":1592,"schema":1593},"CNCF's 5 technologies to watch in 2021","We predict how CNCF's five tech trends to watch will impact cloud native and the tech industry over the next year and beyond.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680997/Blog/Hero%20Images/clouds-cover.jpg","https://about.gitlab.com/blog/cncf-five-technologies-to-watch-in-2021","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CNCF's 5 technologies to watch in 2021\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n        \"datePublished\": \"2020-11-24\",\n      }",{"title":1589,"description":1590,"authors":1595,"heroImage":1591,"date":1596,"body":1597,"category":14,"tags":1598},[802],"2020-11-24","\n\nLast week the Cloud Native Computing Foundation (CNCF) held [KubeCon + CloudNativeCon North America](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/). Even with conferences shifting from in-person to virtual, KubeCon still draws huge crowds and the entire industry's attention. Besides being one of the largest tech conferences of the year, KubeCon continues to show the cutting edge of technology at the forefront of the industry.\n\nToward the conclusion of the conference, [Liz Rice](https://www.cncf.io/spotlights/cncf-community-leader-spotlight-liz-rice/) - chairperson of the CNCF's Technical Oversight Committee (TOC) and VP of Open Source Engineering at Aqua Security - got on the virtual stage to share where the CNCF is going in the coming year and to talk about predictions for the industry as a whole. These predictions covered a vast landscape of new and emerging technologies and ideas. Some of the ideas are entirely within the bounds of the cloud native community, like service mesh, while others, like WebAssembly and eBPF, have even broader impact inside and outside of cloud native technology.\n\nIn the six years since the initial release of Kubernetes, the cloud native landscape has seen a proliferation of technologies and projects related to Kubernetes and cloud native in general. Rice even talks about this in [her closing remarks](https://kccncna20.sched.com/event/eoIl/keynote-predictions-from-the-technical-oversight-committee-toc-liz-rice-cncf-toc-chair-vice-president-open-source-engineering-aqua-security), discussing the much loved and much talked about CNCF landscape. After adding many more graduated projects this year, one of the first predictions is that the coming year will see some current sandboxed projects at the CNCF fail. As Rice explains, this is a natural consequence of the CNCF pushing for innovation because not every innovative project will find a use case in the \"real world\" that justifies the effort of bringing it to market alongside juggernauts like Kubernetes, Envoy, and etcd.\n\n## CNCF's 2021 predictions\n\nOne of the most exciting segments was Rice's five predictions for the technology industry at large - inside and outside of cloud native technologies. These five technologies to watch (or six depending on how you count them) span several emerging technology platforms and speak to the great diversity of needs and projects in the open source community. The TOC's five technology trends to watch include:\n\n1. Chaos engineering\n2. Kubernetes for the edge\n3. Service mesh\n4. Web assembly and eBPF\n5. The developer and operator experience\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Wdyt? What did we miss? \u003Ca href=\"https://t.co/ErA8jZ6lsS\">https://t.co/ErA8jZ6lsS\u003C/a>\u003C/p>— Liz Rice at KubeCon + CloudNativeCon 🇪🇺 (@lizrice) \u003Ca href=\"https://twitter.com/lizrice/status/1329867030284144640?ref_src=twsrc%5Etfw\">November 20, 2020\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Chaos engineering\n\nThe systems and applications we build are getting more and more complex and the human ability to accurately reason about how each component will interact and react becomes harder or impossible. [Chaos engineering](https://en.wikipedia.org/wiki/Chaos_engineering), first proposed and famously [practiced by Netflix's engineering team](https://netflixtechblog.com/tagged/chaos-engineering), takes that change to heart and accepts that complex enough systems are genuinely unpredictable. Once you've understood this aspect of complex systems, the best way to test and reason about their reliability is to perform experiments that best represent real-life, unpredictable events.\n\nWhile the concept of \"turn off a component and see how the system as a whole reacts\" makes sense on the surface, implementing such a methodology, especially in a large enterprise organization, can be daunting. Many projects and more than a few companies have been created to deal with this problem. It will be interesting to see if chaos engineering can move from the \"elite\" technology performers into a more mainstream engineering organization of every size and maturity level.\n\nAt GitLab, we have many customers already experimenting with or practicing chaos engineering. [Uma Mukkara](https://in.linkedin.com/in/uma-mukkara) and [Karthik Satchitanand](https://in.linkedin.com/in/karthik-satchitanand) from Maya Data presented on Chaos Engineering using GitLab templates and LitmusChaos at GitLab Commit in Brooklyn in 2019. We're also considering the many ways that chaos engineering could be more [deeply integrated](https://gitlab.com/groups/gitlab-org/-/epics/381) into GitLab as part of a single [DevOps](/topics/devops/) platform. Watch the video from Uma nad Karthik's GitLab Commit Brooklyn presentation below.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/ezhSg-t-PPM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Kubernetes for the edge\n\nEdge computing refers to an area of cloud computing where the infrastructure for computing, storage, and other requirements need to be placed in the field closer to users or their use cases. While cloud computing helps to centralize and create large data centers that benefit from scale, many if not most interactions with users occur far away from the data center and instead move to the edge.\n\nAs Kubernetes matures and transforms compute in the data center, more use cases for the core tenants of Kubernetes will emerge. And as those use cases expand in scope, we will continue to see new distributions or plugins to the Kubernetes ecosystem to support new use cases. Projects like [KubeEdge](https://kubeedge.io/en/), [K3s](https://k3s.io/), and others, bring the Kubernetes API and extensibility to more devices, even those on the edge.\n\nWith the onslaught of data, devices, and demand for performance, edge computing has become an essential component of many organizations' overall network topology. Bringing the flexibility and power of Kubernetes compute and processing options to this problem will continue to expand in the coming year. For example, there may even be a Kubernetes cluster running [in your car](https://www.youtube.com/watch?v=zmuOxFp3CAk&feature=emb_title) today.\n\n## Service mesh\n\nRice predicts service mesh will be a hot topic in 2021, and with good reason. There has been an explosion of service mesh projects, discussions, and drama throughout the cloud native community in the past year. There has been an enormous proliferation of service mesh projects and teams discussing how a service mesh can benefit their deployments in 2020.\n\nSimilar to chaos engineering, service mesh attempts to organize the growing complexity of systems into a clear and reasonable package. As teams move to a [microservices approach](/topics/microservices/) for application delivery, understanding the interaction and links between existing and new services becomes critical. Service mesh projects like [Istio](https://istio.io/), [Linkerd](https://linkerd.io/), and [Consul](https://www.consul.io/) have cropped up in the past few years. These tools help discover both known and new services and their connections. The goal of the projects is to create signal from noise, allowing humans to understand how those services interact and depend on one another.\n\nIn 2020, there was a lot of drama and discussion around the overall benefits and drawbacks of service mesh and the specific projects used to implement it. Now that there is a greater understanding among CNCF stakeholders about service mesh, we can expect the cloud native community to settle into a clear set of recommendations about when it is appropriate to implement a service mesh and how to make the right decisions about service mesh for your organization.\n\nThe most significant trend here will be with the ability of service mesh to not only discover services but secure them through policy enforcement. Additionally, the desire for observability will drive service meshes to become a critical cornerstone of observability in microservices environments.\n\n## Web assembly and eBPF\n\nIn this prediction, Rice rightly points out that the technologies of web assembly and eBPF are not - on the surface - related. [Web assembly](https://webassembly.org/), also called Wasm, is a new type of virtual machine brought to the browser. [eBPF](https://ebpf.io/) is a programmable interface for interacting with the Linux kernel. So why did the TOC and Rice decide to include these two different technologies in one prediction?\n\nWell, they share a common goal of sandboxing code when it runs. Sandboxing code, which means segmenting it from the parts of memory and the computer it doesn't need to get its job done, is a critical step toward allowing for secure code execution even of unknown sources. In the case of web assembly, that code is running in your browser. For eBPF, it could be running on a shared cloud-based Linux host. In both cases, these tools enable providers and security teams to effectively protect their code and data from prying eyes. This will remain a key objective for engineering teams for years to come, because we need to segment code better from a security perspective.\n\n### Securing code by segmenting processes\n\nMany of the most massive zero-day attacks we've seen in the past few years demonstrate that some traditional pieces of the stack that we \"take for granted\" should instead be prioritized. Today, the barriers of the application memory or even CPU space are still ripe for attack. So inventing new and more secure ways of segmenting processes from one another will be a trend to watch for in 2021 and beyond.\n\nAt GitLab we see security and protection as belonging to the same DevOps lifecycle as the rest of engineering. The [Secure](/stages-devops-lifecycle/secure/) and [Protect](/stages-devops-lifecycle/govern/) stages of the DevOps lifecycle will continue to impact the rest of the cycle and how engineering departments develop and release code faster and more securely. We will see continued consolidation throughout the industry to bring security and protection initiatives to the forefront of every developer's mind, enabling developers and security professionals alike to deploy with confidence.\n\n## The developer and operator experience\n\nSimilar to prioritizing function over UX, our own experience in developing, deploying, and maintaining our projects often takes a back seat to \"getting the job done.\" However, in much the same way, the developer experience and operator experience in their day-to-day tasks will be a key focus as technologies like Kubernetes enter a more mature phase.\n\nWe've already seen colossal consolidation and focus on the DevOps platform as a whole. It was just a year or two ago that we grudgingly accepted a disjointed set of poorly integrated tools, seeing it as unavoidable. Today, we see many DevOps companies and teams selling [enterprise tools](/enterprise/) that are focusing on improving the dev and ops experience by building more capability into our devices and bringing together a more [complete DevOps platform](/solutions/devops-platform/).\n\nThis is a mission that is obviously near and dear to our hearts at GitLab. Next year will bring a renewed focus on the dev and ops experience as more companies settle into the new normal of collaborating with teammates remotely, asynchronously, and automatically. This focus makes the DevOps platform we choose all the more critical to our engineering team's success, and as software defines the world we live in even more by the day, our organizations' overall success.\n\nDevelopers and operators will come to expect an integrated DevOps platform that allows for the dual goals of getting software build and shipped on day 0 and maintaining and operating that software on days 1, 2, and beyond.\n\n## What's next?\n\nA trend that is harder to quantify is the concept of [observablity](/blog/software-developer-changing-role/) and growing trends toward more open communities. The concept of service mesh, Kubernetes at the edge, and the operator experience all play into observability, but I suspect we'll see more discussion of it in the coming year. Also the acceleration of [5G technology](/blog/how-tomorrows-tech-affects-sw-dev/) will impact all computing at the edge - Kubernetes or not. Beyond 2021, trends in [AI in software development](/blog/ai-in-software-development/) may accelerate changes to how we all interact. What trends do you think the CNCF missed in outlining things to watch in 2021? If you have a strong opinion, I'd love to hear about it on [Twitter](https://twitter.com/twitter).\n",[723,1076,894],{"slug":1600,"featured":6,"template":681},"cncf-five-technologies-to-watch-in-2021","content:en-us:blog:cncf-five-technologies-to-watch-in-2021.yml","Cncf Five Technologies To Watch In 2021","en-us/blog/cncf-five-technologies-to-watch-in-2021.yml","en-us/blog/cncf-five-technologies-to-watch-in-2021",{"_path":1606,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1607,"content":1613,"config":1619,"_id":1621,"_type":17,"title":1622,"_source":18,"_file":1623,"_stem":1624,"_extension":21},"/en-us/blog/collaboration-communication-best-practices",{"title":1608,"description":1609,"ogTitle":1608,"ogDescription":1609,"noIndex":6,"ogImage":1610,"ogUrl":1611,"ogSiteName":667,"ogType":668,"canonicalUrls":1611,"schema":1612},"Improving DevOps and software development with communication and 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":1608,"description":1609,"authors":1614,"heroImage":1610,"date":1616,"body":1617,"category":14,"tags":1618},[1615],"Sara Kassabian","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",[974,806],{"slug":1620,"featured":6,"template":681},"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":1626,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1627,"content":1633,"config":1639,"_id":1641,"_type":17,"title":1642,"_source":18,"_file":1643,"_stem":1644,"_extension":21},"/en-us/blog/move-to-distributed-vcs",{"title":1628,"description":1629,"ogTitle":1628,"ogDescription":1629,"noIndex":6,"ogImage":1630,"ogUrl":1631,"ogSiteName":667,"ogType":668,"canonicalUrls":1631,"schema":1632},"Why you should move from centralized version control 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":1628,"description":1629,"authors":1634,"heroImage":1630,"date":1636,"body":1637,"category":14,"tags":1638},[1635],"Suri Patel","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",[973,1255,974],{"slug":1640,"featured":6,"template":681},"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":1646,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1647,"content":1653,"config":1658,"_id":1660,"_type":17,"title":1661,"_source":18,"_file":1662,"_stem":1663,"_extension":21},"/en-us/blog/migrating-your-version-control-to-git",{"title":1648,"description":1649,"ogTitle":1648,"ogDescription":1649,"noIndex":6,"ogImage":1650,"ogUrl":1651,"ogSiteName":667,"ogType":668,"canonicalUrls":1651,"schema":1652},"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":1648,"description":1649,"authors":1654,"heroImage":1650,"date":1655,"body":1656,"category":14,"tags":1657},[1635],"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",[973,1255,974],{"slug":1659,"featured":6,"template":681},"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":1665,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1666,"content":1672,"config":1677,"_id":1679,"_type":17,"title":1680,"_source":18,"_file":1681,"_stem":1682,"_extension":21},"/en-us/blog/future-proof-your-developer-career",{"title":1667,"description":1668,"ogTitle":1667,"ogDescription":1668,"noIndex":6,"ogImage":1669,"ogUrl":1670,"ogSiteName":667,"ogType":668,"canonicalUrls":1670,"schema":1671},"Future-proof your developer career","Roles are changing and AI is coming. We asked 14 DevOps practitioners, analysts, and GitLab execs how to future-proof your career.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679588/Blog/Hero%20Images/future-of-software-future-proof-your-career.png","https://about.gitlab.com/blog/future-proof-your-developer-career","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Future-proof your developer career\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-10-30\",\n      }",{"title":1667,"description":1668,"authors":1673,"heroImage":1669,"date":1674,"body":1675,"category":14,"tags":1676},[890],"2020-10-30","\n\n_This is the fourth and final part of our series on the future of software development. Part one examined [how the software developer role is changing](/blog/software-developer-changing-role/). Part two highlighted [“future” technologies likely to impact the way software is created](/blog/how-tomorrows-tech-affects-sw-dev/). Part three looked at [the role artificial intelligence (AI) will play in software development](/blog/ai-in-software-development/)._\n\nChanging roles, emerging technologies, and the promise (or threat) of artificial intelligence are colliding, creating a critical question for software developers: how should you future-proof your career?\n\nAnyone in the technology industry knows change is both swift and expected – remember [Moore’s Law](https://www.investopedia.com/terms/m/mooreslaw.asp)? But there’s change and then there’s a “big C” *Change* that would impact skills and potentially careers. The [World Economic Forum, writing on the Pluralsight blog](https://www.pluralsight.com/blog/career/tech-in-2025), shared a worrisome observation about the future: “Across nearly all industries, the impact of technological and other changes is shortening the shelf-life of employees’ existing skill sets... ”\n\nSo what skills will be sufficient to navigate the future? We asked 14 [DevOps](/topics/devops/) practitioners, analysts, and GitLab execs for their best advice.\n\n## Embrace the soft skills\n\nIn our 2020 [Global DevSecOps Survey](/developer-survey/), developers, security pros, ops team members, and testers were unanimous in their choice of the most important skills for the future: communication and collaboration. It’s not particularly surprising – DevOps team members are increasingly finding themselves working even more closely together and often in different or new areas of the company. Communication and collaboration in those cases can be the difference between success and failure.\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.”\n\nOne way developers can fine-tune collab skills is to use their open source skills within their organizations, a practice known as “inner sourcing,” says [Jose Manrique Lopez de la Fuente](https://www.linkedin.com/in/jose-manrique-lopez-de-la-fuente-b869884/), CEO at Bitergia, and also a [GitLab Hero](/community/heroes/). “You’re not doing open source alone,” Manrique says. “There are hundreds of developers worldwide also doing it. So, with those skills I learned working with other developers, how can I be transparent with people who are not only connected to my team? How can I get more involved with what’s going on in the company?” The more developers practice this skill, the easier it will get, he predicts.\n\n## It’s not just about tech\n\nAlthough this seems counter-intuitive, future-proofing your career doesn’t necessarily mean boning up on new technologies. In [our survey](/developer-survey/), 28% of developers said [AI was an important skill to know for the future (and they’re probably not wrong)](https://www2.deloitte.com/us/en/insights/focus/signals-for-strategists/ai-assisted-software-development.html), but most experts think it’s not wise to place all your energy in just a single specialty.\n\n“It’s best if you migrate your career from specialty to specialty trying to ride the wave,” Darwin says. “Take a look at what is picking up momentum but is not bleeding edge yet.” GitLab’s director of product management, CI/CD [Jason Yavorska](/company/team/#jyavorska) suggests polishing up the basics. “You want solid tech skills like trouble-shooting, a current knowledge of modern stacks and a lot of basic things,” Jason explains. “You want to be a little bit more of a generalist than an expert in one field.”\n\nThis is definitely a time to take step back and look at the bigger picture, suggests [Philip Lamb](https://www.linkedin.com/in/philliplamb/), global partner senior solutions architect – DevOps at Red Hat. He’s also a proponent of the power of generalization. “Focus less on specific tooling, software, and instead focus more on process and establishing a clear understanding of the sea changes DevOps brings,” he says. And don't forget that DevOps is going to look different for every organization.\n\n## Choose wisely\n\nBut if there’s one thing to keep in mind, above anything else, it’s this: “Avoid what AI is going to be good at,” Jason says. Forrester Research (and many others) think AI [could be creating code in 10 years or less](/blog/ai-in-software-development/). “AI and machine learning could be the most disrupting things to come to your career,” he explains. “If you’ve built your job out of basic things you could find yourself redundant. Focus on things you (as a human) are capable of.”\n",[806,831,935],{"slug":1678,"featured":6,"template":681},"future-proof-your-developer-career","content:en-us:blog:future-proof-your-developer-career.yml","Future Proof Your Developer Career","en-us/blog/future-proof-your-developer-career.yml","en-us/blog/future-proof-your-developer-career",{"_path":1684,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1685,"content":1691,"config":1696,"_id":1698,"_type":17,"title":1699,"_source":18,"_file":1700,"_stem":1701,"_extension":21},"/en-us/blog/ai-in-software-development",{"title":1686,"description":1687,"ogTitle":1686,"ogDescription":1687,"noIndex":6,"ogImage":1688,"ogUrl":1689,"ogSiteName":667,"ogType":668,"canonicalUrls":1689,"schema":1690},"How AI will change software development","AI has made self-driving cars possible, so what about self-writing code? We asked 14 DevOps practitioners, industry analysts and execs to share their take on how AI will impact software development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681709/Blog/Hero%20Images/future-of-software-ai.png","https://about.gitlab.com/blog/ai-in-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How AI will change software development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-10-28\",\n      }",{"title":1686,"description":1687,"authors":1692,"heroImage":1688,"date":1693,"body":1694,"category":14,"tags":1695},[890],"2020-10-28","\n\n_This is the third in our four-part series on the future of software development. Part one examines [the changing developer role](/blog/software-developer-changing-role/), part two takes a deep dive into [emerging technologies with the potential to impact development](/blog/how-tomorrows-tech-affects-sw-dev/), and part four shares [how to future-proof your developer career](/blog/future-proof-your-developer-career/)._\n\nArtificial intelligence has often been dismissed as a promising technology breakthrough that somehow remains out of reach, particularly when it comes to software development. The [role of AI in software development](/topics/devops/the-role-of-ai-in-devops/) has been written about for years and not much substantive has come of it.\n\nBut the stars may be aligning now. Developers are intrigued, and we can see that by looking at the growing popularity of the Python programming language. Stack Overflow’s [annual survey](https://insights.stackoverflow.com/survey/2020) shows Python’s rise in \"popularity\" and \"interest\" based on the number of questions members asked about it. It’s certainly the go-to language for [ML-powered chat bots](https://medium.com/better-programming/software-developer-trends-of-2020-and-beyond-d1b955bc46b8).\n\nAnd in our [2020 Global DevSecOps Survey](/developer-survey/), close to one-quarter of developers surveyed said that an understanding of AI/ML will be the most important skill for their future careers. And roughly 16% of testers said their teams are using bots right now or have an AI/ML tool in place for testing.\n\nSo if Tesla can create a self-driving car, can self-writing code be that far off? The short answer is no, at least according to the more than a dozen [DevOps](/topics/devops/) practitioners, industry analysts, and GitLab executives we spoke with about the future of software development. Here’s what they're thinking.\n\n## A gradual process\n\nAt GitLab AI feels like it will happen but gradually. \"Every set of software in the future is going to be the combination of some procedural code and some (AI) models,\" says GitLab CEO [Sid Sijbrandij](/company/team/#sytses). \"The models will eat more and more of the code over time.\" But Sid sees AI’s role as \"less of a distinct activity and more of an integrated call out to a library or a call out to a model.\"\n\nTo put it another way, senior developer evangelist [Brendan O’Leary](/company/team/#brendan) thinks it would be strange if AI weren’t playing a much more significant (and helpful) role in code development ten years from now. \"But this isn’t going to replace humans – it’s going to make the human role more critical to understand what’s important,\" Brendan says. He likens it to a detail-oriented second set of eyes that can sort through all the data quickly to focus coders on areas that need it. \"Computer-aided detection is really valuable in mammography because it’s hard to look for 1 millimeter specs of white,\" Brendan explains. \"Computer-aided detection is valuable because it surfaces the 'second look' areas to focus on. That’s the model I think we can expect when it comes to AI and software development.\"\n\n[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/)) sees a big benefit to a bot \"colleague\" that will not only ID problems but will suggest solutions. \"I'm waiting for a bot that says 'oh your code is wrong and this is how you fix it,'\" Carlos says. \"You're no longer stuck because the bot is going to run the test for you and fix it.\"\n\n## Meet the Turing Bots\n\nSo there’s clearly a backstop/code testing/QA role for AI in software development, but there is more to it than that, according to Forrester Research. In its September 2020 webinar, \"The Future of Software Development: How AI Will Automate More Than 70% of Software Development,\" [Diego Lo Giudce](https://www.linkedin.com/in/diego-lo-giudice-52232/detail/recent-activity/posts/) and [Mike Gualtieri](https://www.linkedin.com/in/mgualtieri/), both vice presidents and principal analysts, make the case that so called \"Turing Bots\" will be generating code from software artifacts in ten years, or less. The technologies driving the bots include autonomous testing, auto ML (for predicting), reinforcement learning, and machine coding, the webinar says.\n\nThat’s a bold prediction and a lot to unpack for today's DevOps teams. It will be a process and culture shift, certainly, but it will also require sweeping changes in the developer thought process. Forrester recommends developers start now to \"define more precise artifacts and patterns, including app requirements, UX design and solution architecture.\"\n\n## Now take a deep breath\n\nIt’s important to remember, though, that AI is only as good as the data fed to it by humans – it’s not a substitute *for* humans. [Jose Manrique Lopez de la Fuente](https://www.linkedin.com/in/jose-manrique-lopez-de-la-fuente-b869884/), CEO at Bitergia, and also a GitLab hero, puts it this way: \"I don’t believe that we won’t need developers any more,\" he says. \"Artificial intelligence is not intelligent.\"\n\n_Wondering if your skills will keep you relevant in a time of AI overlords? Don’t miss our look at skills critical to a DevOps team's future in the fourth part of our series on the future of software development._\n",[806,831,935],{"slug":1697,"featured":6,"template":681},"ai-in-software-development","content:en-us:blog:ai-in-software-development.yml","Ai In Software Development","en-us/blog/ai-in-software-development.yml","en-us/blog/ai-in-software-development",{"_path":1703,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1704,"content":1710,"config":1715,"_id":1717,"_type":17,"title":1718,"_source":18,"_file":1719,"_stem":1720,"_extension":21},"/en-us/blog/how-tomorrows-tech-affects-sw-dev",{"title":1705,"description":1706,"ogTitle":1705,"ogDescription":1706,"noIndex":6,"ogImage":1707,"ogUrl":1708,"ogSiteName":667,"ogType":668,"canonicalUrls":1708,"schema":1709},"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":1705,"description":1706,"authors":1711,"heroImage":1707,"date":1712,"body":1713,"category":14,"tags":1714},[890],"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",[806,1076,974],{"slug":1716,"featured":6,"template":681},"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":1722,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1723,"content":1729,"config":1734,"_id":1736,"_type":17,"title":1737,"_source":18,"_file":1738,"_stem":1739,"_extension":21},"/en-us/blog/software-developer-changing-role",{"title":1724,"description":1725,"ogTitle":1724,"ogDescription":1725,"noIndex":6,"ogImage":1726,"ogUrl":1727,"ogSiteName":667,"ogType":668,"canonicalUrls":1727,"schema":1728},"The software developer role and responsibilities are changing. Here's what to expect","From your job title to where you sit in the organization and what your priorities are, every single aspect of the software developer role is about to change. More than a dozen DevOps practitioners and analysts shared their views of the future. Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664054/Blog/Hero%20Images/future-of-software-developer-role-changing.png","https://about.gitlab.com/blog/software-developer-changing-role","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The software developer role and responsibilities are changing. Here's what to expect\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-10-20\",\n      }",{"title":1724,"description":1725,"authors":1730,"heroImage":1726,"date":1731,"body":1732,"category":14,"tags":1733},[890],"2020-10-20","\n_This is the first in our four-part series on the future of software development. Part two puts the spotlight on [\"future\" technologies that may impact how software is developed](/blog/how-tomorrows-tech-affects-sw-dev/). 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\nWhat is the role of a developer? Rapid technology advancements, sweeping changes in business priorities, and a seemingly insatiable demand for software have collided in ways that will likely mean substantive changes to the software developer's role over the next few years.\n\nNothing is static, of course, and in our [2020 Global DevSecOps Survey](/developer-survey/) we found that developers are already reporting new responsibilities – such as tasks normally associated with ops and security – while at the same time releasing software much faster and embracing new technologies including Kubernetes, [microservices](/topics/microservices/), and even AI.\n\nBut over the next few years even some fundamental things – like the meaning of \"developer\" or the role in the organization – are poised to change. Here's what more than a dozen DevOps practitioners and analysts see coming.\n\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\n## What's in a name?\n\nThanks to the explosion of demand for [enterprise software applications](/enterprise/), a wave of \"development democratization\" is about to hit professional developers, and that is going to mean a fundamental shift in what it means to *be* a developer, according to [a report from Deloitte Insights](https://www2.deloitte.com/us/en/insights/focus/signals-for-strategists/digital-transformation-moving-beyond-it.html). [Low-code and no-code development tools](/blog/low-code-no-code/) allow virtually anyone with a good idea to create some level of application, meaning a potentially unlimited number of citizen developers will be capable of doing at least basic application development. Software development won't be restricted to just pro developers anymore and this shift is well underway in the enterprise market because there simply [aren't enough coders to meet the demand](https://www.cnbc.com/2019/06/18/there-are-70000-open-tech-jobs-here-is-how-firms-are-hiring-for-them.html). Writing in a ComputerWeekly article, Gartner research director [Paul Vincent](https://www.linkedin.com/in/paulvincent/?originalSubdomain=uk) goes one step further and suggests there might be times [even professional developers choose to use a low-code tool](https://www.computerweekly.com/feature/Gartner-What-to-consider-before-adopting-low-code-development).\n\n## A new org chart\n\n_Goodbye IT department and hello line of business._ As the software stakes get higher and product managers continue to set software development goals, it makes sense that developers will end up embedded on business teams rather than technology teams. A report from Forrester Research looking at trends for 2020 refers to this shift as [the \"dev diaspora\"](https://www.ciodive.com/news/forresters-predictions-software-development/566257/) and predicts that after some bumps in the road it will improve productivity and release speed. The basic message: Software is critical to business success so should be located *with* the business rather than in the IT department.\n\n## New colleagues and culture\n\nWith developers moving \"into the business\" and a growing emphasis on citizen devs, it's clear not all teams will be filled with hardcore coders. Some certainly will be working alongside citizen developers. But others may also find \"team members\" in unexpected places, like their IDEs. Although artificial intelligence is still nascent in most enterprise development teams, some industry analysts are bullish that AI can bring speed, advice, structure, and perhaps even coding to the table in three to five years from now.\n\nHowever, no matter how quickly AI ends up as part of the pro developer work experience it's clear dev culture is going to have to change if \"development\" is no longer such a specialized skill.\n\n## Yet another shift left\n\nSecurity, test, and automation may have already shifted left so now get ready for customers to shift left, warns [Kenny Johnston](/company/team/#kencjohnston), senior director of product management, Ops at GitLab. \"If you want to have a complete view of [DevOps](/topics/devops/) you have to understand how your application is actually interacting with customers and you have to have that understanding from the early stages of development,\" says Kenny. Traditionally, developers have been largely absent from customer interactions, but that's going to change moving forward. GitLab's director of product management, CI/CD [Jason Yavorska](/company/team/#jyavorska) says one way to make customers real is for developers to take on a design mindset. \"You want to be thinking about the customer and building features together with the customer while both of you are connecting as humans.\"\n\nIf that's a step too far in the near term, Kenny has a medium-term strategy: Focus on what happens when something goes wrong. If developers want to write code that satisfies increasingly demanding customers, Kenny suggests starting with a simple question: \"What's the customer doing when the application fails?\"\n\n## Stop monitoring. Start observing\n\nA new focus on customers and the accompanying tightened feedback loops means more data than ever is likely to be heading to developers. That's not sustainable, says GitLab's senior developer evangelist [Brendan O'Leary](/company/team/#brendan). Constant alerting doesn't tell a developer much, which is why he sees teams moving away from monitoring and toward observability. \"You want to be able to observe how a complex system operates rather than monitoring it,\" he says. \"It's like the difference between Jane Goodall and a gorilla.\" Dr. Goodall can decode what she sees and put it in context, a practice that is tremendously valuable for devs (and ops pros for that matter) to establish. \"If we want to make technology easier to process we need to be able to get this information to developers in a meaningful way,\" he explains. \"We want to be able to show developers exactly what people normally do or where users get stuck in a particular area... all of that is better information than the data they have right now. We have to find a way to surface the information that matters.\"\n\n## Double down on open source\n\nMore than 60% of those who took our DevSecOps Survey are active participants in open source projects and DevOps practitioners expect that will continue to increase. At a time when the world is changing quickly, open source can be a way reticent developers can push themselves to learn about other parts of the business, says [Rafael Garcia](https://www.linkedin.com/in/jrafaelgarcia/), director of digital services at insurance provider Aflac. \"If you're actively engaging in open source that's one way of looking at cross-company projects,\" he says. \"Maybe there's a passion project that's outside of your core business roles or functions. It's a way of doing things that are outside your comfort zone.\"\n\nOpen source also provides a window into the way other companies operate, something developers need a better sense of in a world undergoing big changes, says [Jose Manrique Lopez de la Fuente](https://www.linkedin.com/in/jose-manrique-lopez-de-la-fuente-b869884/), CEO at Bitergia (and a [GitLab Hero](/community/heroes/)). Developers need to understand and cultivate the open source culture, he says. \"You don't have to start from scratch,\" says Manrique. And looking at how other companies manage their open source culture will reinforce that belief. \"It's not only about the skills or the components but also about the relationships with the maintainers of the components. You benefit if you can create a wider community.\"\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",[806,722,745],{"slug":1735,"featured":6,"template":681},"software-developer-changing-role","content:en-us:blog:software-developer-changing-role.yml","Software Developer Changing Role","en-us/blog/software-developer-changing-role.yml","en-us/blog/software-developer-changing-role",{"_path":1741,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1742,"content":1748,"config":1753,"_id":1755,"_type":17,"title":1756,"_source":18,"_file":1757,"_stem":1758,"_extension":21},"/en-us/blog/tech-debt",{"title":1743,"description":1744,"ogTitle":1743,"ogDescription":1744,"noIndex":6,"ogImage":1745,"ogUrl":1746,"ogSiteName":667,"ogType":668,"canonicalUrls":1746,"schema":1747},"How to use DevOps to pay off your technical debt","Technical debt is a universal problem with an equally universal solution – DevOps. Here's how DevOps can reduce the tech debt burden and help you deploy faster and more frequently.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681643/Blog/Hero%20Images/greenery.jpg","https://about.gitlab.com/blog/tech-debt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use DevOps to pay off your technical debt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2020-10-05\",\n      }",{"title":1743,"description":1744,"authors":1749,"heroImage":1745,"date":1750,"body":1751,"category":14,"tags":1752},[1615],"2020-10-05","\n\nOne of the primary resource constraints in the [DevOps](/topics/devops/) world is technical debt. Technical debt is a metaphor created by Ward Cunningham that compares the build-up of cruft (deficiencies in the internal quality of software systems) to the accumulation of financial debt, where the effort it takes to add new features is the interest paid on the debt, writes [Martin Fowler](https://martinfowler.com/bliki/TechnicalDebt.html).\n\nIt’s common for a busy developer to write code with known imperfections, but because the priority is to ship new features as quickly as possible, deliverables are often prioritized over correcting the inefficiencies in the process.\n\nOne of the major dilemmas with determining the value of spending precious time fixing cruft versus building new features is that the costs are not objectively measurable, says Fowler. Just like with paying off financial debt, the right call is largely circumstantial as opposed to absolute.\n\n\"Given this, usually the best route is to do what we usually do with financial debts, pay the principal off gradually,\" writes Fowler.\n\nBy cleaning up some of the cruft as you work on the new features, you ensure that the most relevant code is tidier for future iterations. When it comes to crufty, but stable, code, you can leave it alone. This method is similar to paying the monthly balance on a low interest rate loan – the impact is minimal.\n\n \"In contrast, areas of high activity need a zero-tolerance attitude to cruft, because the interest payments are cripplingly high,\" writes Fowler.\n\nOne way to start dealing with technical debt is to conduct a rough audit and triage your technical debt by \"interest rate\" – high interest rate cruft is addressed with the same priority as shipping new features, while medium-to-low interest rate cruft can be dealt with in a ratio that best suits your team’s situation, because dealing with your most urgent technical debt sooner rather than later will help you save resources in the long-term.\n\n## How tech debt accumulates in your workflow\n\nIt’s not just code that contains cruft. A lot of the time, we have cruft that slows down our engineering processes. When it comes to investing time and money into updating DevOps processes, it seems there is never enough of either resource.\n\n\"We don’t let our teams spend time on improving their process because we think it’s wasted effort,\" says [Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab. \"But if you can spend a day fixing some things that make your workflow inefficient, and you save an hour a week from now until eternity, that’s a big difference.\"\n\nTake for instance manual deployment versus the use of automated pipelines. We know that deploying manually takes an enormous amount of time, but the upfront cost of allocating time to building automated pipelines can seem daunting.\n\nIf your team is trapped in a time-consuming cycle of technical debt, take a peek at how Minnesota-based consulting firm, [BI Worldwide](/customers/bi-worldwide/) (BIW), was able to accelerate deployments by transitioning to GitLab. In the case study, the BIW Corporate Products Development Team explains how they were stuck in a rut of manual testing and manual deployments on their on-prem infrastructure. Their toolchains were complex and inefficient, which created a dense backlog.\n\n\"It was entirely time-consuming to apply all of those code changes,\" said Adam Dehnel, product architect, BIW, in the case study. As a result, deployments were infrequent and slow as too many features were crammed into each release.\n\nThe first step to increase the speed of their deployments was to update and modernize their processes.\n\n\"[BIW] had practices and tools in place at the time but were spending time on items that weren’t business differentiating features. They faced classic issues surrounding a lack of cross-team communication including inefficient mechanisms for intra-organization workflows and individualized toolsets.\"\n\nFirst, BIW made the painful transition from CVS to Git. Next, the company aimed to automate the build, test, and deployment process and built a toolchain with tools such as GitHub, Jenkins, JIRA, and Confluence.\n\nFor BIW, this complex toolchain was buggy. One thing that was not mentioned in this specific use case, but still merits recognition, is the hidden cost of maintaining all of these different tools.\n\n\"The argument to be made there is not only is it cost of using these various tools, but also that the more tools you have, there is the overhead cost of upgrading them, maintaining them, and integrating them,\" says Brendan. \"There’s a massive hidden cost behind the cost of doing business.\"\n\nIn the next iteration, BIW embraced the efficiency of an all-in-one tool by transitioning to GitLab.\n\nBIW went from a pre-Git pace of shipping a release every nine to 12 months to deploying nearly ten times a day using GitLab Ultimate, no doubt putting a serious dent in the technical debt that followed their slower, laborious release cycle.\n\n## Conserve valuable resources and pay off technical debt with DevOps\n\nIn a previous blog post, we examined [communication strategies to get non-technical stakeholders to buy-in to DevOps](/blog/devops-stakeholder-buyin/). DevOps can help you deploy faster and more frequently, giving your business an edge over the competition, but it is also a strategy for paying off your technical debt. By first taking into account inefficiencies in your code and engineering processes, you can make a rough triage of your team's technical debt. This type of audit is the first step to identifying cruft you can trim to help speed up your cycle time, clear your backlog, and modernize your engineering processes.\n\n## Read more\n\n- [Need DevOps buy-in? Here's how to convince stakeholders](/blog/devops-stakeholder-buyin/)\n- [A guide to cloud native storage for beginners](/blog/cloud-native-storage-beginners/)\n- [Want to iterate faster? Choose boring solutions](/blog/boring-solutions-faster-iteration/)\n\nCover Photo by [Vadim L](https://unsplash.com/@sk3tch?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/plants?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[676,1447,806,110],{"slug":1754,"featured":6,"template":681},"tech-debt","content:en-us:blog:tech-debt.yml","Tech Debt","en-us/blog/tech-debt.yml","en-us/blog/tech-debt",{"_path":1760,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1761,"content":1767,"config":1772,"_id":1774,"_type":17,"title":1775,"_source":18,"_file":1776,"_stem":1777,"_extension":21},"/en-us/blog/three-yaml-tips-better-pipelines",{"title":1762,"description":1763,"ogTitle":1762,"ogDescription":1763,"noIndex":6,"ogImage":1764,"ogUrl":1765,"ogSiteName":667,"ogType":668,"canonicalUrls":1765,"schema":1766},"3 YAML tips for better pipelines","Learn how to get the most out of your YAML configs.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681626/Blog/Hero%20Images/yaml-tips.jpg","https://about.gitlab.com/blog/three-yaml-tips-better-pipelines","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 YAML tips for better pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-10-01\",\n      }",{"title":1762,"description":1763,"authors":1768,"heroImage":1764,"date":1769,"body":1770,"category":14,"tags":1771},[1483],"2020-10-01","\n\nAt GitLab, we’re fans of YAML. But for all of its benefits, we’d be lying if we said YAML hasn’t caused its fair share of headaches, too.\n\n[YAML](https://yaml.org/) is used industry-wide for declarative configuration. YAML offers flexibility and simplicity, as long as you know the rules and limitations. Since YAML is platform-agnostic, knowing best practices around YAML configurations is a transferable skillset in a cloud native world.\n\n## What are the benefits of YAML?\n\nYAML is a data serialization language designed to be human-friendly. YAML is easy to use in a text editor, has a simple syntax that works across programming languages, and can store a lot of important configuration data (typically in a .yml or .yaml file).\n\n[YAML is data-oriented](https://blog.stackpath.com/yaml/) and has features derived from Perl, C, HTML, and others.\n\nBecause YAML is a superset of JSON, it has built-in advantages including comments, self-referencing, and support for complex data types.\n\nA [YAML file uses declarative configuration](https://www.codeproject.com/Articles/1214409/Learn-YAML-in-five-minutes) to describe a variety of structures, such as API data structures and even deployment instructions for virtual machines and containers, to name a few.\n\nYAML is comprehensive, widely-used, and works in every type of development environment.\n\n## YAML tip #1: Let other tools do the formatting for you\n\nYAML is one of those languages where it’s minimalism is both a blessing and a curse, depending on who you ask. It also relies on the syntactically significant whitespace that is a source of [heated debate](https://wiki.c2.com/?SyntacticallySignificantWhitespaceConsideredHarmful) among developers. For a language where formatting is a king, what can developers do to make sure they stay within the rules without having to analyze every single space and indentation?\n\nMany text editors and platforms have plugins or built-in tools to check YAML configuration syntax for you.\n\n*   [Atom](http://atom.io/), the open source text editor, comes with a default YAML mode.\n*   [Red Hat YAML support](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) provides YAML Language and Kubernetes syntax support to the [VS Code editor](https://code.visualstudio.com/).\n*   [OnlineYamlTools](https://onlineyamltools.com/edit-yaml) has a web-based editor that will do in a pinch. It also links to other helpful options such as converting JSON to YAML, etc.\n*   [SlickEdit](https://www.slickedit.com/products/slickedit/448-the-most-powerful-yaml-editor-in-the-world#:~:text=SlickEdit%20%2D%20The%20most%20powerful%20YAML,source%20diff%2C%20and%20much%20more.) is the self-described \"most powerful YAML editor in the world\" and has some helpful features to back it up (at a cost). SlickEdit offers a free trial.\n*   [Pretty YAML](https://packagecontrol.io/packages/Pretty%20YAML) is a plugin for Sublime Text 2 and 3 that allows you to format YAML files.\n\n[Linters](https://sourcelevel.io/blog/what-is-a-linter-and-why-your-team-should-use-it) are used in the development process to analyze code for stylistic and formatting errors, among other things. Teams adopt linters and other static tools by integrating them into their integrated development environment (IDE) of choice, and/or by running them as an additional step in their continuous integration (CI).\n\nIn GitLab, we have a [CI lint](https://docs.gitlab.com/ee/ci/lint.html#validate-basic-logic-and-syntax) that checks the syntax of your CI YAML configuration that also runs some basic logical validations.\n\nTo use the CI lint, paste a complete CI configuration (`.gitlab-ci.yml` for example) into the text box and click `Validate`:\n\n![GitLab CI lint](https://docs.gitlab.com/ee/ci/img/ci_lint.png)\n\n## YAML tip #2: Keep it simple\n\nIt’s easy to overwhelm the minimalism of a YAML file by including too many details, or by being inconsistent with formatting. When it comes to YAML, less is often more.\n\nIt isn’t necessary to specify every single attribute. `Job timeout` is an example of an attribute that can be left out, since this is something that is sometimes specified elsewhere. An example in GitLab is [interruptible](https://docs.gitlab.com/ee/ci/yaml/#interruptible), which is used to indicate that a job should be canceled if made redundant by a newer pipeline run. Since this defaults to `false` it’s not always necessary to include it.\n\nSome people indent gratuitously when writing YAML to help themselves visualize large chunks of data. To better visualize how data works together, it might be helpful to create a \"pseudo-config\" before committing the code to YAML. On the [Red Hat blog](https://www.redhat.com/sysadmin/yaml-tips), a pseudo-config is described as pseudo-code where you don't have to worry about structure or indentation, parent-child relationships, inheritance, or nesting. Just write the data down as you understand it.\n\n![Red Hat pseudo config](https://www.redhat.com/sysadmin/sites/default/files/inline-images/pseudoyaml.jpg)\n\nOnce you understand how the data correlates, then you can commit it to YAML.\n\nRegardless of how you define simplicity in your workflow, try to keep YAML configs uncluttered and include only the necessary data. And if you’re not sure what data is necessary, write out a pseudo-config to help you visualize it.\n\n\n\n## YAML tip #3: Reuse config when possible\n\nStarting from scratch is a lot of wasted effort, and YAML is no exception. One of the best parts of YAML is its reusabilty, and reusing config is a way to keep files consistent within an organization.\n\nOne way to [avoid duplicated configuration](https://docs.gitlab.com/ee/ci/yaml/#include) is by using the `include` keyword, which allows the inclusion of external YAML files. For example, global default variables for all projects that don’t need to be modified for every file. The `include` keyword helps to break down a YAML configuration into multiple files and boosts readability, especially for long files. It’s also possible to have template files stored in a central repository and projects included in their configuration files.\n\n`extends` is a great way to reuse some YAML config in multiple places, for example:\n\n```\n.image_template:\n  image:\n    name: centos:latest\n\ntest:\n  extends: .image_template\n  script:\n    - echo \"Testing\"\n\ndeploy:\n  extends: .image_template\n  script:\n    - echo \"Deploying\"\n```\n\nYAML has a handy feature called [anchors](https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#anchors), which lets you easily duplicate content across your document. Anchors can be used to duplicate/inherit properties, and is a perfect example to be used with [hidden jobs](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs) to provide templates for your jobs. When there is duplicate keys, GitLab will perform a reverse deep merge based on the keys.\n\n```\n.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'\n  image: ruby:2.6\n  services:\n    - postgres\n    - redis\n\ntest1:\n  <\u003C: *job_definition           # Merge the contents of the 'job_definition' alias\n  script:\n    - test1 project\n\ntest2:\n  <\u003C: *job_definition           # Merge the contents of the 'job_definition' alias\n  script:\n    - test2 project\n```\n\nOne big caveat to anchors: You can’t use anchors across multiple files when leveraging the `include` feature.\n\nInstead of building pipelines from scratch, [CI/CD pipeline templates](/blog/get-started-ci-pipeline-templates/) simplify the process by having parameters already built-in. At GitLab, pipelines are defined in a `gitlab-ci.yml` file. Because our CI/CD templates come in over 30 popular languages, chances are good that we have the template you need to get started in our [CI template repository](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates).\n\nTemplates can be modified and are created to fit many use cases. To see a large `.gitlab-ci.yml` file used in an enterprise, see the [.gitlab-ci.yml file for GitLab](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).\n\nWhether you’re a YAML lover, YAML novice, or using YAML against your will, knowing some tips and tricks can make your development process a better experience. Do you have any YAML tips or recommendations? Feel free to comment down below.\n\nCurious about GitLab CI/CD and want to show off your YAML skills? [Try GitLab free for 30 days](/free-trial/).\n\nCover image by [Harits Mustya Pratama](https://unsplash.com/@haritsmustya?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/greenhouse?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n## Related content\n[GitLab CI/CD pipeline configuration reference](https://docs.gitlab.com/ee/ci/yaml)\n\n[Unlock better DevOps with GitLab CI/CD](https://about.gitlab.com/blog/better-devops-with-gitlab-ci-cd/)\n\n[Pipeline efficiency](https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html)\n",[110,806],{"slug":1773,"featured":6,"template":681},"three-yaml-tips-better-pipelines","content:en-us:blog:three-yaml-tips-better-pipelines.yml","Three Yaml Tips Better Pipelines","en-us/blog/three-yaml-tips-better-pipelines.yml","en-us/blog/three-yaml-tips-better-pipelines",{"_path":1779,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1780,"content":1786,"config":1792,"_id":1794,"_type":17,"title":1795,"_source":18,"_file":1796,"_stem":1797,"_extension":21},"/en-us/blog/devops-stakeholder-buyin",{"title":1781,"description":1782,"ogTitle":1781,"ogDescription":1782,"noIndex":6,"ogImage":1783,"ogUrl":1784,"ogSiteName":667,"ogType":668,"canonicalUrls":1784,"schema":1785},"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":1781,"description":1782,"authors":1787,"heroImage":1783,"date":1788,"body":1789,"category":14,"tags":1790},[1615],"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",[806,1791,974],"user stories",{"slug":1793,"featured":6,"template":681},"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":1799,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1800,"content":1806,"config":1812,"_id":1814,"_type":17,"title":1815,"_source":18,"_file":1816,"_stem":1817,"_extension":21},"/en-us/blog/get-started-ci-pipeline-templates",{"title":1801,"description":1802,"ogTitle":1801,"ogDescription":1802,"noIndex":6,"ogImage":1803,"ogUrl":1804,"ogSiteName":667,"ogType":668,"canonicalUrls":1804,"schema":1805},"How to use GitLab’s CI/CD pipeline templates","Learn how pipeline templates and Auto DevOps can get you up and running on GitLab CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667139/Blog/Hero%20Images/CI-pipeline-templates.jpg","https://about.gitlab.com/blog/get-started-ci-pipeline-templates","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use GitLab’s CI/CD pipeline templates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-09-23\",\n      }",{"title":1801,"description":1802,"authors":1807,"heroImage":1803,"date":1808,"body":1809,"category":14,"tags":1810},[1483],"2020-09-23","\nWriting deployment pipelines from scratch is a real pain in the branch. We want to make the [continuous integration](/topics/ci-cd/) experience more automatic so teams can get up and running quickly with [GitLab CI/CD](/topics/ci-cd/).\n\nAn easy way to get started is with GitLab’s CI/CD pipeline templates. Pipeline templates come in **more than 30** popular programming languages and frameworks. We’ll show you how to use these pipeline templates for your specific needs.\n\nFor an even more automatic continuous integration experience, we also offer [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) that does much of the legwork for you. Auto DevOps runs on pipelines automatically when a [Dockerfile or matching buildpack](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-build) exists, and identifies dependencies automatically.\n\n## What are CI pipeline templates?\n\n[Pipelines](https://docs.gitlab.com/ee/ci/pipelines/) are an integral component of both continuous integration (CI) and [continuous delivery (CD)](/topics/continuous-delivery/), and continuous deployment (the other \"CD\"). A deployment pipeline consists of two things:\n\n*   Jobs, which define _what_ to do. For example, jobs that compile or test code.\n*   Stages, which define _when_ to run the jobs. For example, stages that run tests after stages that compile the code.\n\nPipelines consist of one or more stages that run in order and can each contain one or more jobs that run in parallel. These jobs (or scripts) get run by agents, such as a [GitLab Runner](https://docs.gitlab.com/runner/).\n\nAt GitLab, pipelines are defined in a `gitlab-ci.yml` file. [CI/CD templates](https://docs.gitlab.com/ee/ci/examples/#cicd-templates) incorporate your favorite programming language or framework into this YAML file. Instead of building pipelines from scratch, CI/CD templates simplify the process by having parameters already built-in.\n\nYou can choose one of these templates when you create a `gitlab-ci.yml` file in the UI.\n\n![GitLab CI pipeline templates](https://docs.gitlab.com/ee/ci/img/add_file_template_11_10.png)\n\nBecause our CI/CD templates come in more than 30 popular languages, the chances are good that we have the template you need to get started in our [CI template repository](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates).\n\n## What is Auto DevOps?\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) is a GitLab-exclusive feature that provides predefined CI/CD configurations that automatically detect, build, test, deploy, and monitor your applications. Rather than just accessing a template, Auto DevOps is a setting within your GitLab instance that is [enabled by default](https://docs.gitlab.com/ee/topics/autodevops/#enabled-by-default).\n\nOur [product vision for Auto DevOps](/direction/delivery/auto_devops/) is that everything is fully connected as part of one great GitLab experience. The term Auto DevOps actually comes from the different parts that are automated by Auto DevOps:\n\n*   \"Auto CI\" – Compile and test software based on best practices for the most common languages and frameworks.\n*   \"Auto review\" – Automatic analysis tools like Code Climate.\n*   \"Auto deploy\" – Based on [Review Apps](/stages-devops-lifecycle/review-apps/) and incremental rollouts on Kubernetes clusters.\n*   \"Auto metrics\" – Collect statistical data from all the previous steps in order to guarantee performances and optimization of the whole process.\n\nAuto DevOps provides great defaults for all the stages and makes use of CI templates. You can [customize Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/customize.html) to meet your needs, and [manage Auto DevOps with GitLab APIs](https://docs.gitlab.com/ee/topics/autodevops/customize.html#extend-auto-devops-with-the-api).\n\nLearn more about Auto DevOps, check out this video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/0Tc0YYBxqi4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Other CI/CD resources\n\nGitLab also provides [CI/CD examples](https://docs.gitlab.com/ee/ci/examples/) so you can learn how to implement GitLab CI/CD for your specific use case. In addition to template files, you can find repositories with sample projects, and step-by-step tutorials for a variety of scenarios, including:\n\n*   [DevOps and Game Dev with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/)\n*   [Test and deploy a Ruby application with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/)\n*   [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/)\n*   ... And many others\n\nWith CI/CD templates and our Auto DevOps product feature, teams can start reaping the benefits of continuous integration without all of the manual configurations. For teams managing sometimes _hundreds_ of projects, it’s not realistic or doable to start from scratch. And with GitLab, you don’t have to.\n\nCurious about our best-in-class continuous integration? [Try GitLab free for 30 days](/free-trial/).\n\n## Related reads\n\n*   [\"A beginner's guide to continuous integration\"](/blog/a-beginners-guide-to-continuous-integration/)\n\n*   [\"Want a more effective CI/CD pipeline? Try our pro tips\"](/blog/effective-ci-cd-pipelines/)\n\n*   [\"3 CI/CD challenges to consider\"](/blog/modernize-your-ci-cd/)\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/laboratory?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[110,1811,806],"UI",{"slug":1813,"featured":6,"template":681},"get-started-ci-pipeline-templates","content:en-us:blog:get-started-ci-pipeline-templates.yml","Get Started Ci Pipeline Templates","en-us/blog/get-started-ci-pipeline-templates.yml","en-us/blog/get-started-ci-pipeline-templates",{"_path":1819,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1820,"content":1826,"config":1831,"_id":1833,"_type":17,"title":1834,"_source":18,"_file":1835,"_stem":1836,"_extension":21},"/en-us/blog/cloud-native-storage-beginners",{"title":1821,"description":1822,"ogTitle":1821,"ogDescription":1822,"noIndex":6,"ogImage":1823,"ogUrl":1824,"ogSiteName":667,"ogType":668,"canonicalUrls":1824,"schema":1825},"A guide to cloud native storage for beginners","Choosing a cloud native development strategy is a smart step in DevOps, but storage can be a challenge. Here’s what you need to consider.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681560/Blog/Hero%20Images/cloudnative.jpg","https://about.gitlab.com/blog/cloud-native-storage-beginners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A guide to cloud native storage for beginners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-09-10\",\n      }",{"title":1821,"description":1822,"authors":1827,"heroImage":1823,"date":1828,"body":1829,"category":14,"tags":1830},[890],"2020-09-10","\n\n[DevOps](/topics/devops/) and cloud native go hand-in-hand but that doesn’t mean the journey is straightforward, particularly when it comes to storage. Here’s everything you need to know about cloud-native storage if you’re just getting started. \n\n## What is cloud-native software development?\n\nBoiled down, the term [cloud native](/topics/cloud-native/) simply means taking advantage of the power of the cloud and doing so from the beginning of the software development lifecycle. Flexibility, speed, and “always on” capabilities make the cloud an ideal place for [modern software development](https://www.infoworld.com/article/3281046/what-is-cloud-native-the-modern-way-to-develop-software.html).\n\nAlthough [containers aren’t limited to just the cloud](https://containerjournal.com/features/what-do-containers-have-to-do-with-being-cloud-native-anyway/), they are a key part of cloud native software development because they make it simple to move chunks of code from cloud to cloud using the same set of tools and processes. Containers can be created, moved or deleted with just the click of a mouse. [Kubernetes](/solutions/kubernetes/) is an increasingly popular open source tool for managing containers.\n\n## Why storage is the stumbling block\n\nSo far, so good, but what about storage? The features that make containers so ideal for cloud native (flexible, portable, disposable) are the same things that make them a storage nightmare. Developers finished with containers can just kill them – but for most apps to work, they need access to reliable storage that can’t be eliminated. \n\nAnd that’s the big hiccup when it comes to cloud native storage, says [Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab. “Almost every app in existence needs database storage,” Brendan explains. “But in a cloud native world things come and go but storage can’t do that. Storage has to stick around and solving for that is the hardest part of cloud native. That’s the thing we need to conquer next.”\n\nThe [Cloud Native Computing Foundation](https://www.cncf.io/) says the goal is to create [\"persistent information\"](https://www.cncf.io/blog/a-complete-storage-guide-for-your-kubernetes-storage-problems/) that exists no matter what’s going on around it. Ideally the CNCF recommends that information not be stored in what it calls \"volatile\" containers.\n\n## Solutions on the horizon\n\nThe good news is that a number of companies are trying to solve the tricky problem of cloud native storage. Here’s a quick look in no particular order (Cockroach and Rancher are GitLab partners):\n\n* [OpenEBS]( https://openebs.io) is a Kubernetes-based tool to create stateful applications using Container Attached Storage.\n* Also Kubernetes-based, [Rook](https://rook.io) offers self-managed, scaling, and healing storage services.\n* [Cockroach Labs](https://www.cockroachlabs.com/) uses Distributed SQL to make databases portable and scalable.\n* [Rancher Longhorn](https://longhorn.io) offers persistent storage for Kubernetes.\n\n## Final considerations\n\nA Gartner Group report, “Top Emerging Trends in Cloud-Native Infrastructure”, advises clients to “choose storage solutions aligned with container-native data service requirements and the standard storage interface, [Container Storage Interface (CSI)](https://www.architecting.it/blog/container-storage-interface/). CSI is an API that lets container orchestration platforms like Kubernetes seamlessly communicate with stored data via a plug-in. \n\nAnd finally, there’s no shame in choosing something straightforward, Brendan suggests, particularly if you’re just getting started in the Kubernetes world. “You can go with a cloud provider’s data storage options,” he says. “That’s still cloud native but it’s even simpler to just use the tools that exist. Don’t try to reinvent the wheel.”\n\nCover image by [Joshua Coleman](https://unsplash.com/@joshstyle) on [Unsplash](https://unsplash.com)\n{: .note}\n",[723,1076,852],{"slug":1832,"featured":6,"template":681},"cloud-native-storage-beginners","content:en-us:blog:cloud-native-storage-beginners.yml","Cloud Native Storage Beginners","en-us/blog/cloud-native-storage-beginners.yml","en-us/blog/cloud-native-storage-beginners",{"_path":1838,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1839,"content":1845,"config":1852,"_id":1854,"_type":17,"title":1855,"_source":18,"_file":1856,"_stem":1857,"_extension":21},"/en-us/blog/efficient-code-review-tips",{"title":1840,"description":1841,"ogTitle":1840,"ogDescription":1841,"noIndex":6,"ogImage":1842,"ogUrl":1843,"ogSiteName":667,"ogType":668,"canonicalUrls":1843,"schema":1844},"How to carry out effective code reviews","From time management to unblocking, discover the secrets of more efficient code reviews.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678861/Blog/Hero%20Images/pre-commit.jpg","https://about.gitlab.com/blog/efficient-code-review-tips","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to carry out effective code reviews\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Phil Hughes\"}],\n        \"datePublished\": \"2020-09-08\",\n      }",{"title":1840,"description":1841,"authors":1846,"heroImage":1842,"date":1848,"body":1849,"category":14,"tags":1850},[1847],"Phil Hughes","2020-09-08","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-09-15.\n{: .alert .alert-info .note}\n\nLike most companies, code review at GitLab is a major part of our workflow. But it's clear from the results of our [2020 Global DevSecOps Survey](/developer-survey/) that code review can be a major reason for delayed releases and overall frustration. A vast majority of companies conduct code reviews (some even on a daily basis) but that doesn't mean it isn't a potential time sink.\n\n## How to perform a code review?\n\nBut code reviews can be done efficiently, and I know this since I've been a maintainer for 3 years. Here's a look at my top four tips for code review based on a tried and true routine that allows me to do effective code reviews and merge code quickly and efficiently to aid in others not being blocked by me. Of course, this is what works for *me* – your mileage may vary. Here's how I do it:\n\n### Tips for code review no.1 - Time management\n\nAn early start to my day makes it easy to start reviewing merge requests first thing. I set myself a time to start reviewing and I will keep at it until my GitLab \"to do\" list no longer has any merge requests that need reviewing. Mornings work for me; it's the time of the day when I can focus the most and get the reviews done with minimal distractions.\n\nGetting to reviews after this time is hard. I have other work that needs doing as well so once I've reviewed all merge requests on my list I leave anything new until the next day. Of course, as with all rules, it ends up getting broken. **Depending on the size of merge requests, I may make sure I review them before my day ends to make sure anyone in other timezones aren't blocked by me.**\n\n### Tips for code review no.2 - Unblock others first\n\nIt's not great for the author of a merge request to have to wait X hours/days before they get feedback. The sooner they get feedback, the sooner the merge request can be merged and shipped. Making authors wait just creates uncertainty and may mean that other work gets held up.\n\nThis is why I find it important for me to review a merge request as quickly as possible. At GitLab we have a [2  day Service Level Objective (SLO)](/handbook/engineering/workflow/code-review/#review-response-slo) for feedback from reviewers. For myself, I always try to do better than that and respond within a day.\n\n### 3. Tips for code review no.3 - Focus on the code, not the feature\n\nThis is going to be a point that could create a lot of discussion: Instead of focusing on the feature, focus on the code.\n\nA lot of the merge requests I review are across different groups, with features that I don't fully understand or with features I have no way to test. I could spend a lot of my time reading into the feature and the issue to understand what it is, but that means spending more time not reviewing everyone else's code. Also, if I did this with **every** merge request, it would be hard for me to keep to my time limit.\n\nWho is better to review the feature itself then? The product designer (UX) or the product manager both understand the feature being worked on and are better suited to help find bugs or guide the feature in the correct way. It is important that someone in the UX team review the feature to make sure it matches the designs and vision they had created for the feature. If a merge request has no UX review by the time I get to reviewing it, I will normally ask the author (or ask a product designer myself) to have the UX reviewed _before_ I merge the merge request.\n\nHowever, this point is also something I don't _always_ stick to. If a merge request is touching an area that I am familiar with and I can tell from the code that a bug exists, I will test it locally and provide as much feedback as I can to help the author understand the bug. The more you – as a reviewer – work with the code, the easier finding bugs through the code becomes. I have been working on the GitLab codebase for over 4 years, so seeing where bugs could arise through looking at the code has become natural to me.\n\n### Tips for code review no.4 - Seek to understand: Ask questions\n\nIt is easy to suggest changes to the code that I am reviewing, however sometimes what I suggest may not be right. It is important that instead of just suggesting a change, you always try to ask if the author thinks it is the right change. Having a conversation around a change helps both the reviewer and the author understand the existing code as well as the code being suggested. Maybe the suggestion had already been tried by the author. Being open to talk about it helps get to the final solution.\n\nSometimes however suggestions for changes happen around legacy code, i.e., code that has existed for a long time without being updated to match our documentation. In these cases, the conclusion may end up being that a technical debt issue be created. This is ok. We should strive for [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions) first but also understand that a more optimal solution may be required in the future.\n\n## To sum it up\n\nReviewing code efficiently is a skill that gets learnt the more you do it. Spending time coming up with a workflow that works for you is just as important. Over the years I have been reviewing code, I have stuck to these tips as closely as possible. Yet, I am far from perfect; I am constantly learning about new and different ways to optimise my workflow for code review. I would love to hear other tips and workflows. It is through discussions that we can improve and push ourselves to be the best that we can be.\n",[1851,935,1115],"frontend",{"slug":1853,"featured":6,"template":681},"efficient-code-review-tips","content:en-us:blog:efficient-code-review-tips.yml","Efficient Code Review Tips","en-us/blog/efficient-code-review-tips.yml","en-us/blog/efficient-code-review-tips",{"_path":1859,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1860,"content":1866,"config":1872,"_id":1874,"_type":17,"title":1875,"_source":18,"_file":1876,"_stem":1877,"_extension":21},"/en-us/blog/a-tale-of-two-editors",{"title":1861,"description":1862,"ogTitle":1861,"ogDescription":1862,"noIndex":6,"ogImage":1863,"ogUrl":1864,"ogSiteName":667,"ogType":668,"canonicalUrls":1864,"schema":1865},"A tale of two file editors","How UX Research revealed unexpected patterns in how people use two GitLab file editors: the single-file editor and the Web IDE.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668339/Blog/Hero%20Images/a-tale-of-two-editors.jpg","https://about.gitlab.com/blog/a-tale-of-two-editors","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A tale of two file editors\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2020-09-01\",\n      }",{"title":1861,"description":1862,"authors":1867,"heroImage":1863,"date":1869,"body":1870,"category":14,"tags":1871},[1868],"Emily von Hoffmann","2020-09-01","\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-11-13.\n{: .alert .alert-info .note}\n\nThis study began the way many do – with a conundrum and a theory. \n\nThe [Create: Editor](/handbook/product/categories/#editor-group) group originally had the goal of deprecating the single-file editor in favor of the new and improved [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/). But after looking into usage data, we discovered that [the single-file editor was being used at higher rates](https://www.youtube.com/watch?v=3iPNyfVNO1U&feature=youtu.be) than the Web IDE, and in fact had quadruple the page views. This was a concerning discovery with the potential of becoming a real inflection point, raising questions like: Do we have a discoverability problem, or do we have a usability problem? Has our investment in the Web IDE been moving us in the wrong direction? \n\n![Web IDE pageviews](https://about.gitlab.com/images/blogimages/web-ide-pageviews.png){: .medium.center} \n\n![Single-file editor pageviews](https://about.gitlab.com/images/blogimages/single-file-editor-pageviews.png){: .medium.center}\n\nAs you can see above, the single-file editor significantly outperforms the Web IDE in terms of page views. The single-file editor also receives more visitors who are coming to and from merge requests.  \n\n## Our theory\n\nWe initially thought the single-file editor got more usage than the Web IDE due to discoverability problems. Since people should be able to accomplish everything they need within the Web IDE, maybe they just don’t know it exists. Or, maybe the “edit” button on the single-file editor seems like the obvious choice for what people want to do, whereas “Web IDE” sounds more complicated. There’s also always a nagging concern that people have tried the Web IDE and found it to be a bad experience, opting instead to stick with the alternative. \n\n## Our research plan\n\nWe developed a survey to hammer out whether people know how to edit a file in GitLab, why they choose the editor they do, and why, if ever, they choose the other one. \nFor reference, here’s what they both look like: \n\n### Exhibit A: Single-file editor \n\n![Gif of Single-file editor in action](https://about.gitlab.com/images/blogimages/single-file-editor-ezgif.gif){: .shadow.center}\n\n### Exhibit B: Web IDE \n\n![Gif of Web IDE in action](https://about.gitlab.com/images/blogimages/web-ide-ezgif.gif){: .shadow.center} \n\n## Results\n\nAfter reviewing the survey results, we started seeing clear patterns that indicate people actually have distinct use cases for each editor. They’re not using the single-file editor because they can’t find the Web IDE; they’re purposefully selecting an editor based on the complexity of what they need to accomplish. \nPeople prefer the single-file editor when they need to make very simple changes to a single file. It’s aptly named in that sense! Alternatively, people choose the web IDE when they want to edit multiple files, or when they want to make changes that require context from other files. These changes might include hotfixes, creating templates, and making changes related to GitLab CI files.  \n\nWe also learned that people want the ability to edit in context. Today, people choose an editing mode and then switch between screens to navigate to other project areas, which isn’t the best experience. What people really want is the ability to toggle editors and easily access navigation while in the Web IDE:\n\n> \"Let me toggle between editors (e.g. if I start with Editor and realize I need to edit another file, I can switch to Web IDE – with any changes made carried over).\"\n\n## What’s next\n\nI love this study because it so clearly demonstrates the value of research. Had we gone ahead with our original theory, we would have been solving a perceived discoverability problem that people aren’t really having. Instead, we disproved our theory and have several proposed improvements already in the works. \nInstead of removing the single-file editor in favor of promoting the Web IDE, we’ll explore a simplified editing workflow that [consolidates the Edit and Web IDE buttons](https://gitlab.com/gitlab-org/gitlab/-/issues/221247) so that a dropdown allows people to choose their preferred mode. You can see mockups for the next potential iterations below.\n\n| Description | Mock |\n| ------ | ------ |\n| Web IDE option chosen (default) | ![Web IDE chosen by default](https://about.gitlab.com/images/blogimages/web-ide-chosen-by-default.png) |\n| Edit option chosen | ![Edit chosen by default](https://about.gitlab.com/images/blogimages/file-chosen-by-default.png) |\n| Dropdown | ![Dropdown lets you choose](https://about.gitlab.com/images/blogimages/dropdown-choose-your-editor.png) |\n\nWhat do you think about the proposed change? Come talk to us on [Twitter](https://twitter.com/gitlab/), and join our [UX research program](/community/gitlab-first-look/) to participate in future studies. \n\n## Read more about UX at GitLab\n\n- [How holistic UX design increased GitLab.com free trial signups](/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups/)\n- [How we created a dark UI for GitLab's Web IDE](/blog/creating-a-dark-ui-for-gitlabs-web-ide/)\n- [Designing in an all-remote company](/blog/designing-in-an-all-remote-company/)\n\n[Katherine Okpara](/company/team/#katokpara) contributed to this post.\n\nCover image by Gastón Blaquier on [Unsplash](https://unsplash.com/photos/_foeAxTQ5H0).",[677,676],{"slug":1873,"featured":6,"template":681},"a-tale-of-two-editors","content:en-us:blog:a-tale-of-two-editors.yml","A Tale Of Two Editors","en-us/blog/a-tale-of-two-editors.yml","en-us/blog/a-tale-of-two-editors",{"_path":1879,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1880,"content":1886,"config":1891,"_id":1893,"_type":17,"title":1894,"_source":18,"_file":1895,"_stem":1896,"_extension":21},"/en-us/blog/ten-devops-terms",{"title":1881,"description":1882,"ogTitle":1881,"ogDescription":1882,"noIndex":6,"ogImage":1883,"ogUrl":1884,"ogSiteName":667,"ogType":668,"canonicalUrls":1884,"schema":1885},"DevOps terminology: 10 terms that might surprise you","From Yoda to yaks and even baklava, here are 10 DevOps terms we’re betting you’ve never heard of.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681526/Blog/Hero%20Images/devopsterms.jpg","https://about.gitlab.com/blog/ten-devops-terms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOps terminology: 10 terms that might surprise you\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-08-25\",\n      }",{"title":1881,"description":1882,"authors":1887,"heroImage":1883,"date":1888,"body":1889,"category":14,"tags":1890},[890],"2020-08-25","\n\nYou call yourself a [DevOps professional](/topics/devops/build-a-devops-team/) but do you know the definitions of yak shaving, Yoda conditions or baklava code?\n\nWe didn’t think so.\n\n## Benefits of DevOps\n\nDevOps outpaces the old software development methodologies like waterfall simply because it’s more efficient. Here are eight obvious DevOps wins:\n\n* Deployment is faster\n\n* Product quality is better\n\n* Automation simplifies the whole process\n\n* There’s flexible, continuous delivery\n\n* Scalability is even easier to achieve\n\n* Teams are transparent and communicative\n\n* There are faster fixes for bugs and other problems\n\n* It gives space to constantly iterate\n\nRegardless of your role on a business or a technical side, there are DevOps benefits for everyone.\n\n## DevOps terms and team communication\n\nA basic understanding of DevOps terms is important when it comes to optimal team communication. Otherwise, there are a lot of blank, blinking faces in the crowd. But even more important than simply understanding the terminology is consciously practicing good communication about DevOps and iterating on your team’s communication style.\n\nNew ideas, tools, and processes are constantly cropping up in the DevOps space, which means there is new terminology to learn. Great team communication involves continuously helping each other keep up with new knowledge and ensuring an environment of continuous learning.\n\n## DevOps terms glossary\n\nHere’s a look at our [DevOps](/topics/devops/) glossary with a focus on 10 DevOps terms even seasoned pros might not have encountered. And if you think there are some obscure ones we missed, please tell us about it [here](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/8878). We are working on a comprehensive GitLab guide to DevOps terms.\n\n### Devops term 1: Baklava code\n\n[Baklava](https://en.wikipedia.org/wiki/Baklava) is a dessert made up of many layers of thin phyllo dough – which is notoriously difficult to work with. Baklava code is the same: Lots of thin layers of code which makes it too fragile to stand up to real world use.\n\n### DevOps term 2: Dark launch\n\nA dark launch usually refers to a partial or incomplete release of a feature or features without any announcement. This under-the-radar release is a way to gather performance and testing data without the pressure of public input, because the features haven’t actually been talked about.\n\n### DevOps term 3: Dead code\n\nCode is considered \"dead\" if it lives in a program but actually doesn’t do anything and/or contribute to results or performance. Generally [dead code should be removed](https://refactoring.guru/smells/dead-code) as it’s a potential waste of space and computational power.\n\n### DevOps term 4: Everything-as-code\n\nEverything-as-code takes [infrastructure-as-code](https://searchitoperations.techtarget.com/definition/Infrastructure-as-Code-IAC) and goes one step further: Literally everything is treated as code including the infrastructure, virtual machines, and deployment configuration, to name a few. Everything-as-code is made possible by cloud native, proponents of it say it boosts traceability, repeatability, and testing. \n\n### DevOps term 5: Fear-driven development\n\nForget [FOMO](https://www.urbandictionary.com/define.php?term=Fomo), fear-driven development is what happens when project managers raise the stakes by moving up deadlines or laying people off. \n\n### DevOps term 6: NoOps\n\nIt’s DevOps without the \"Ops\" or what could happen if automation eliminates traditional ops tasks. Some see NoOps as the highest evolution of a successful DevOps practice while others don’t see it that way at all. NoOps joins a slew of other Ops-related terms including [GitOps](https://thenewstack.io/what-is-gitops-and-why-it-might-be-the-next-big-thing-for-devops/), [CIOps](https://dzone.com/articles/kubernetes-anti-patterns-lets-do-gitops-not-ciops), and more.\n\n### DevOps term 7: Rubberducking\n\nThis novel way of debugging code was made famous in the book [The Pragmatic Programmer](https://www.amazon.com/Pragmatic-Programmer-journey-mastery-Anniversary/dp/0135957052/ref=sr_1_1?dchild=1&keywords=the+pragmatic+programmer&qid=1598365813&sr=8-1). A programmer carries around a rubber duck and discovers that by explaining the code to the duck, line by line, the errors made themselves obvious. Translated for the real world, and practiced at GitLab, it means talking through your code with another developer which helps make flaws or logical errors more obvious.\n\n### DevOps term 8: Spaghetti code\n\nIf someone tells you your code is like spaghetti don’t take it as a compliment. Spaghetti code is all over the map, often with too many [GOTO statements](https://www.geeksforgeeks.org/goto-statement-in-c-cpp/). It’s poorly organized and often lacks any kind of traditional structure. \n\n### DevOps term 9: Yak shaving\n\nDuring a global pandemic when many are working from home, it’s safe to assume yak shaving is happening frequently, and it’s definitely a term that is used [outside of programming](https://americanexpress.io/yak-shaving/). In general, it means doing something that leads to something else but has nothing to do with the original goal. Programmers use it to refer to interminable tasks that must be done before a project can move forward, as in, \"I’ll get to that once I’ve shaved the yak.\"\n\n### DevOps term 10: Yoda conditions\n\n*Code you I will Luke Skywalker.* Yoda conditions refers to non-traditionally written code, i.e., code written as [Yoda](https://starwars.fandom.com/wiki/Yoda) speaks. Once you put yourself in the mindset it’s possible to understand what you’re looking at, but, just like Luke Skywalker experienced, it can take a while to get the hang of this.\n\n_Some of these are terms in use at GitLab, but in our research we stumbled across [the Coding Horror blog](https://blog.codinghorror.com/new-programming-jargon/) created by Jeff Atwood and we found a few new-to-us terms including Yoda conditions. Jeff refers to his list as the \"top 30 Stack Overflow new programming jargon entries.\"_\n\n## Growth of a DevOps culture\n\nA DevOps culture doesn’t grow simply because an organization decides to implement it. It takes daily, focused effort and cultivation. Some things organizations can do to foster the growth of a DevOps culture are to keep leadership in the loop, openly communicate across the team, and create a roadmap of shared goals and individual responsibilities to help achieve them. Understanding the lingo helps too!\n\nCover image by [Raphael Schaller](https://unsplash.com/@raphaelphotoch) on [Unsplash](https://unsplash.com)\n{: .note}\n",[806,676,1255],{"slug":1892,"featured":6,"template":681},"ten-devops-terms","content:en-us:blog:ten-devops-terms.yml","Ten Devops Terms","en-us/blog/ten-devops-terms.yml","en-us/blog/ten-devops-terms",{"_path":1898,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1899,"content":1905,"config":1911,"_id":1913,"_type":17,"title":1914,"_source":18,"_file":1915,"_stem":1916,"_extension":21},"/en-us/blog/boring-solutions-faster-iteration",{"title":1900,"description":1901,"ogTitle":1900,"ogDescription":1901,"noIndex":6,"ogImage":1902,"ogUrl":1903,"ogSiteName":667,"ogType":668,"canonicalUrls":1903,"schema":1904},"Want to iterate faster? Choose boring solutions","We’ve released 106 times in 106 months, proof that boring solutions do work when it comes to software development. Here are some of our favorites.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681499/Blog/Hero%20Images/pencils2.jpg","https://about.gitlab.com/blog/boring-solutions-faster-iteration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want to iterate faster? Choose boring solutions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-08-18\",\n      }",{"title":1900,"description":1901,"authors":1906,"heroImage":1902,"date":1907,"body":1908,"category":14,"tags":1909},[890],"2020-08-18","\n\n*bor-ing* | *bȯr-iŋ*\n\n_Definition of boring: causing weariness and restlessness through lack of interest : causing boredom : tiresome_ –– Merriam-Webster\n\nAt GitLab we’re boring and we’re proud of it. \"Use the simplest and most boring solutions for a problem, and remember that 'boring' should not be conflated with 'bad' or technical debt,\" our [handbook](/handbook/) says. \"The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors.\"\n\nAlthough this may seem like counterintuitive behavior at a fast moving software startup, boring solutions are actually grounded in both science and history. [Boyd’s Law of Iteration](https://blog.codinghorror.com/boyds-law-of-iteration/) proves that faster iteration is superior to the quality of iteration. We feel like our history of releasing 106 times in 106 months also proves this point. We’ve managed [to iterate so quickly month after month](/blog/observations-on-how-to-iterate-faster/) *because* we’ve chosen the boring solution.\n\nIf this isn’t enough to convince your team to choose the boring solution more often, we’ve rounded up a slew of boring choices we’ve made to help you make the case (and maybe speed up your software delivery).\n\n## Issue labels\n\nAn early boring solution was the choice to use issue labels to power lists on issue boards. Instead of creating a new system, the boring solution was to use what we had to make a small iteration and get entirely new functionality. (Candidly - this design decision has become a huge pain point, but it’s still a great example of a boring solution) –– [William Chia](/company/team/#williamchia), senior product marketing manager, cloud native & [GitOps](/solutions/gitops/)\n\n## Skip the new UI\nWe created documentation around using [curl](https://curl.haxx.se) against API endpoints instead of creating a new user interface. –– [Nicholas Klick](/company/team/#nicholasklick), backend engineering manager, Configure\n\nWe chose to use a JSON Web Token to authenticate with Vault vs. building out a new UI or CLI. –– [Jackie Meshell](/company/team/#jmeshell), senior product manager, Release:Release Management\n\n## Embrace a small change\nWe recently added awareness [if a security scanner isn’t enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/214392) from the project-level security dashboard. Previously there was no way to know this without going to the Configuration page. While it’s a small change, we’ve received good feedback so far, and hopefully encourages customers to take more advantage of our Gold/ Ultimate offering (and keep their applications safer!) –– [Becka Lippert](/company/team/#beckalippert), product designer, Secure\n\n## Boring = less confusing\nWe spent some time and research deciding among multi-select dropdowns, single-select dropdowns, and plain dropdowns. It was a simple but effective process and prompted team member [Austin Regnery](/company/team/#aregnery), product designer, Manage:Compliance, to comment, “Before joining GitLab I remember reading [this issue](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/443) and being really impressed by both the boring solution and data-driven decision making.\n\n## Boring can also make work easier\nWe made it easier to read the title of an issue without having to scroll back to the top of the page. We initially proposed only the title would stick, but then we did a quick solution validation and found out the MVC was to include the issue status. We paired the first iteration back from a solution that would include other objects (like MRs, epics, etc.) and chose to scope it down just to issues. We also pushed back on making other elements sticky (like the tab nav) [in the first iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/216880). –– [Mike Long](/company/team/#mikelong), product design manager, Plan & Manage\n\n## If boring doesn’t work, abandon it\nIn GitLab’s early days, we used [Gitolite](https://gitolite.com/gitolite/index.html) and the SSH key list. They were boring solutions. They were not elegant but allowed us to focus on adding value. When it no longer worked, we [changed it](/blog/gitlab-without-gitolite/). –– [Sid Sijbrandij](/company/team/#sytses), CEO\n\n## Who needs fancy?\n\nAnd if there’s any doubt that we won’t reach for something shiny when something simple will do, we’ll leave you with these two anecdotes.\n\nWe use SQL for the CI job queue. –– [Stan Hu](/company/team/#stanhu), engineering fellow\n\nAnd, when we made the decision to move from Azure to GCP, we used the most boring solution ever – a checklist (no, really, a checklist) to help us make the process seamless. We made 140 changes to that checklist, all told, but after that careful process, [we were able to migrate from Azure to GCP with no serious issues](/blog/gitlab-journey-from-azure-to-gcp/).\n\n*Read more about faster software delivery:*\n\nPro tips for a faster [CI/CD pipeline](/blog/effective-ci-cd-pipelines/)\n\nKeep your [Kubernetes runners moving](/blog/best-practices-for-kubernetes-runners/)\n\nGet [faster and more flexible pipelines](/blog/directed-acyclic-graph/)\n\nCover image by [Frank Vessia](https://unsplash.com/@frankvex?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[676,1910,995],"releases",{"slug":1912,"featured":6,"template":681},"boring-solutions-faster-iteration","content:en-us:blog:boring-solutions-faster-iteration.yml","Boring Solutions Faster Iteration","en-us/blog/boring-solutions-faster-iteration.yml","en-us/blog/boring-solutions-faster-iteration",{"_path":1918,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1919,"content":1925,"config":1930,"_id":1932,"_type":17,"title":1933,"_source":18,"_file":1934,"_stem":1935,"_extension":21},"/en-us/blog/developer-security-divide",{"title":1920,"description":1921,"ogTitle":1920,"ogDescription":1921,"noIndex":6,"ogImage":1922,"ogUrl":1923,"ogSiteName":667,"ogType":668,"canonicalUrls":1923,"schema":1924},"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":1920,"description":1921,"authors":1926,"heroImage":1922,"date":1927,"body":1928,"category":14,"tags":1929},[802],"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",[722,894,974],{"slug":1931,"featured":6,"template":681},"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":1937,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1938,"content":1944,"config":1949,"_id":1951,"_type":17,"title":1952,"_source":18,"_file":1953,"_stem":1954,"_extension":21},"/en-us/blog/kubernetes-terminology",{"title":1939,"description":1940,"ogTitle":1939,"ogDescription":1940,"noIndex":6,"ogImage":1941,"ogUrl":1942,"ogSiteName":667,"ogType":668,"canonicalUrls":1942,"schema":1943},"Understand Kubernetes terminology from namespaces to pods","Kubernetes can be a critical piece of successful DevOps but there's a lot to learn. We explain the terms and share a hands-on demo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670635/Blog/Hero%20Images/kubernetesterms.jpg","https://about.gitlab.com/blog/kubernetes-terminology","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understand Kubernetes terminology from namespaces to pods\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-07-30\",\n      }",{"title":1939,"description":1940,"authors":1945,"heroImage":1941,"date":1946,"body":1947,"category":14,"tags":1948},[890],"2020-07-30","\n\n_If you're brand new to Kubernetes, you'll want to start with our [Kubernetes 101 guide](/blog/kubernetes-101/)._\n\nKubernetes and containers are often seen as two key elements in a [successful DevOps practice](/topics/devops/). But there's no question that Kubernetes can be intimidating to those not familiar with it. In fact, our [2020 Global DevSecOps Survey](/developer-survey/) found just 38% of respondents are actively using Kubernetes today while 50% are not. Anecdotally though, interest in Kubernetes is very high:\n\n_\"We are on the path to get our monolithic server into a sert of microservices and the goal is to use Kubernetes to help on this side.\"_\n\n_\"We're trying to get there.\"_\n\n_\"It's a priority for our platform team.\"_\n\nThis past spring staff distribution engineer [Jason Plum](/company/team/#WarheadsSE) and senior distribution engineer [Gerard Hickey](/company/team/#ghickey) walked attendees at GitLab's company-wide meeting Contribute through something they called _Kubernetes 102_ that looked at the practical building blocks required for a cloud-native application on [Kubernetes](https://kubernetes.io). As Jason puts it in the [video](https://www.youtube.com/watch?v=jdKXBJLHP8I&feature=emb_title), \"what we're trying to do here is to not just say, 'Look at all the magic we do' but actually explain the things we're doing right.\" Although this was a \"laptops out\" demo, here's a look at the key concepts and Kubernetes terminology you'll need to understand followed by a link to the entire presentation if you'd like to dive right in.\n\n## Start with containers\n\nA container is not a jail, but a jail is a container, Jason explains. \"A container is a way of packaging an application so that it is portable. It's contained, hence (the term) 'container' and it's immutable. It's the runtime requirements to actually execute and package that up in an immutable form that you can hand to someone.\"\n\nBut containers can have a tendency to get out of hand so you need something to help keep track. That's where Kubernetes comes in, Jason says in the presentation. \"So what is Kubernetes at a high level? I've seen orchestrator, I've seen management system and I've seen coordinator. Kubernetes is all of those things.\"\n\nKubernetes weaves both containers and software-defined networking together, creating \"a platform you can deploy onto with a clear syntax,\" Jason says. \"That syntax is replicable and not vendor bound so that you can deploy it anywhere that supports the official behaviors. Its job is to start containers, keep them running and make sure they're still running. That's what its job is really about.\"\n\n## Unpacking the moving parts\n\nIf you want to get more familiar with Kubernetes, it helps to understand the unique terminology, Jason stresses. Here are key terms that will help to explain the processes involved in running Kubernetes:\n\n**Namespaces**: In Kubernetes, [the namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) is effectively your working area. It's like a project in GCP or a similar thing in AWS.\n\n**Pods**: [A pod](https://kubernetes.io/docs/concepts/workloads/pods/) is effectively a unit of work. It is a way to describe a series of containers, the volumes they might share, and interconnections that those containers within the pod may need. You can have a pod that has a single container in it (or more than one container). Pods are flexible, too: Update one and it becomes version two, and version one is taken out, giving you a rolling update. As Jason spells out, \"It gives us a way to say, 'I always want to have three and still be able to migrate an application live from one version to another version without having downtime.'\n\n**Service**: Kubernetes \"has a concept of [a service](https://kubernetes.io/docs/concepts/services-networking/service/),\" Jason says. \"It can be thought of as like a load balancer for pods. It knows which pods are alive, healthy, and ready to respond so that when we try to access whatever pod we want to get to instead of to connect to the deployment and getting the one we get, and then always asking that pod for work.\"\n\n**Ingress**: This works with the service to make sure everything ends up in the right place. [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) can also provide load balancing.\n\n**ConfigMaps**: This is an API object for storing information in key-value pairs. \"A [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) is very useful for doing things like pre-stashing environment variables or files that can actually be mounted directly into pods without actually having to have an actual file system somewhere,\" Jason says, adding that they're not meant for confidential data.\n\n**Secrets**: [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) are an object and a place to store confidential information as the name implies.\n\nNow that you have the Kubernetes terminology down, watch the entire presentation here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/jdKXBJLHP8I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Read more about Kubernetes**:\n\n* [Keep your Kubernetes runners moving](/blog/best-practices-for-kubernetes-runners/)\n\n* Set up GitLab CI/CD on [Google Kubernetes Engine](/blog/gitlab-ci-on-google-kubernetes-engine/) in 15 minutes!\n\n* Create a [Kubernetes cluster](/blog/gitlab-eks-integration-how-to/) on Amazon EKS\n\nCover image by [Matti Johnson](https://unsplash.com/@matti_johnson) on [Unsplash](https://unsplash.com)\n{: .note}\n\n## Read more on Kubernetes:\n\n- [How to install and use the GitLab Kubernetes Operator](/blog/gko-on-ocp/)\n\n- [Threat modeling the Kubernetes Agent: from MVC to continuous improvement](/blog/threat-modeling-kubernetes-agent/)\n\n- [How to deploy the GitLab Agent for Kubernetes with limited permissions](/blog/setting-up-the-k-agent/)\n\n- [A new era of Kubernetes integrations on GitLab.com](/blog/gitlab-kubernetes-agent-on-gitlab-com/)\n\n- [What we learned after a year of GitLab.com on Kubernetes](/blog/year-of-kubernetes/)\n",[1076,806,723],{"slug":1950,"featured":6,"template":681},"kubernetes-terminology","content:en-us:blog:kubernetes-terminology.yml","Kubernetes Terminology","en-us/blog/kubernetes-terminology.yml","en-us/blog/kubernetes-terminology",{"_path":1956,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1957,"content":1963,"config":1969,"_id":1971,"_type":17,"title":1972,"_source":18,"_file":1973,"_stem":1974,"_extension":21},"/en-us/blog/rust-programming-language",{"title":1958,"description":1959,"ogTitle":1958,"ogDescription":1959,"noIndex":6,"ogImage":1960,"ogUrl":1961,"ogSiteName":667,"ogType":668,"canonicalUrls":1961,"schema":1962},"A guide to Rust programming language","Rust is a well-loved programming language but it is a mindset shift from options like C++. Here's a tutorial and an inside look at Rust code and its capabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681441/Blog/Hero%20Images/rust.jpg","https://about.gitlab.com/blog/rust-programming-language","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A guide to Rust programming language\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-07-21\",\n      }",{"title":1958,"description":1959,"authors":1964,"heroImage":1960,"date":1965,"body":1966,"category":14,"tags":1967},[890],"2020-07-21","\n\n## What is Rust?\n\nRust is an open source programming language that has been the \"most loved language\" on developer community Stack Overflow's annual survey for the last four years. While it's a popular language in that sense, only a very, _very_ small number of developers actually use Rust language today – a July 2020 look at the PYPL PopularitY of Programming Languages Index ranks it at number 18 with just .81% interest. (For comparison Python is at nearly 32% and Java is over 17%.)\n\nSo why the intense love of the Rust programming language? To put it simply, Rust coding was created to solve problems present in other languages and if you can take the time to unlock its (admittedly difficult) secrets, you're rewarded with cleaner, faster, and most importantly, safer code. Rust code resolves pain points that you see in countless other programming languages with far fewer downsides. Utilizing Rust allows developers to decide when they no longer need memory at the time of compilation which creates more efficiency around memory usage.\n\n[Antony Saba](/company/team/#asaba), a senior security engineer with Strategic Security at GitLab, recently talked about Rust during a company-wide series of meetings ([Contribute 2020](/events/gitlab-contribute/)). He speaks from experience as his last employer was a Rust-based company. \"Okay, so what's Rust's promise?\" Saba asked. \"Rust's promise is that it should be easier, and everybody should be able to fearlessly write at a systems level and not have to worry about memory safety or thread safety, or at least worry about it in the way that is supported by the language and the tools.\"\n\nLet's unpack what that means.\n\n## History of Rust programming language\n\nThe [open source Rust community](https://www.rust-lang.org) describes the language as fast, reliable and productive. \"Hundreds of companies around the world are using Rust in production for fast, low-resource cross-platform solutions,\" the organization says. Firefox and DropBox are two well-known users of Rust today, and Mozilla (creator of Firefox) was the first original supporter of Rust.\n\n### Who created Rust?\n\nRust code was originally developed as an open source project by software developer Graydon Hoare while working at Mozilla Research in 2006 and has been maintained by the Rust Foundation since 2021. It’s now one of the top drivers of the Rust programming language. \n\nThink of Rust as the answer to a data-rich problem that will likely need lots of computational cycles. Mozilla's [Rust documentation](https://research.mozilla.org/rust/) specifically calls out the language as ideal for \"game engines, operating systems, file systems, browser components and simulation engines for virtual reality.\"\n\n## Benefits of programming in Rust\n\nThe top benefit of Rust coding is its adept memory management. Although there are other programming languages that emphasize memory safety like Rust code, Rust handles the concept differently in that it doesn’t use a garbage collector as other programming languages do. Instead, Rust uses a borrow checker to track variable scope and object lifetime while simultaneously administering high-quality memory safety and stopping concurrent data races. \n\nThe benefits of programing in Rust don’t stop at memory management. It’s fast and reliable for creating web apps and creating cross-platform applications, and it can integrate with preexisting code. \n\nOne of the other major benefits of Rust programming language is that it is well-suited for projects that demand extremely high performance. Its ability to process large amounts of data and CPU-intensive operations makes it a strong competitor in the developer space. \n\nOther Rust feature benefits offer a list of features that makes it stand out from other programming languages. Here are some of the features:\n\n1. It’s more user-friendly.\n2. You’ll find high-quality documentation about the language.\n3. It has a better resolution of memory errors and concurrent programs than C and C++ languages.\n4. It’s incredibly fast and highly secure compared to other languages.\n\n## The Rust ecosystem\n\nThe [JetBrains 2021 Developer Ecosystem Report](https://www.jetbrains.com/lp/devecosystem-2021/rust/) found that Rust developers have mostly been using it for less than six months, and often reach for the language for \"hobby\" or personal projects. What are devs primarily writing with Rust? The report found command line interface tools, systems programming and web development were the most popular options.\n\nMany companies have started using Rust, though. In 2020, [Discord switched from Go to Rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust), and Shopify, Dropbox, AWS and many others use it as well. \n\n## The basics of Rust programming language\n\nRust is a bit of a hybrid, according to Mozilla's Rust documentation. Rust offers developers the syntax advantages of high-level languages with the \"control and performance of a low-level language,\" the documentation explains.\n\nRust is a statically typed language rather than a dynamic one. Though developers like to argue the merits of both, Rust, like popular TypeScript, eliminates the frustration of \"dynamic typing.\" Data is constrained and checked by a compiler so confusion is minimized. Rust programming also makes it very hard to ignore errors – Steve Donovan, author of [\"A Gentle Guide to Rust,\"](https://stevedonovan.github.io/rust-gentle-intro/) jokes it can be hard not to think the compiler is shouting at you when you make a mistake.\n\nDonovan identifies Rust's key principles as:\n\n* Strictly enforcing safe borrowing of data\n* Functions, methods, and closures to operate on data\n* Tuples, structs, and enums to aggregate data\n* Pattern matching to select and destructure data\n* Traits to define behaviour on data\n\n## Types of Rust coding\n\nRust treats values by breaking them down into \"types\" in order to handle the data appropriately. According to MIT's guide to Rust, there are a number of types that can be split into scalar or integer types. Scalar types will likely be familiar to those who work with other programming languages: characters, Booleans, floating-point numbers and integers. They all represent a single value. Compound types are what they sound like – multiple types together.  \n\n## Who uses Rust?\n\nAll of the guardrails mentioned lead to a language that can create fast-moving code with few things that slow it down. There's no runtime or garbage collection, making coding in Rust ideal for applications where memory usage is at a premium (like embedded devices). But if there is a place where Rust really stands out, it's security. Donovan points out that Rust is \"safe by default,\" unlike C or C++. No one can corrupt memory by default, he writes.\n\n## The Rust programming language and productive coding\n\nAfter three years of coding in Rust, Antony was quick to say he's probably more productive with the language than any other.\n\n\"I really do feel like Rust was the most productive language I've ever used,\" he says. \"Once you are doing everything in that functional style, you're writing less code, but it's still clearer, because you don't have temporary variables. They're a thing that you don't really end up using when you're writing code that way. So, to me, it's those little things that I get the productivity out of.\"\n\n## Rust can be touchy, but rewarding\n\nProductive, sure, but there's a learning curve with Rust.\n\n\"It's true the borrow checker is the hardest part,\" Antony says. \"But the thing is, once you get past that, there is a serious dopamine hit when that program compiles, because it means now you only have your own logic errors to deal with. Part of that pain is explicitly some of the things that you assume, and some of the little white lies that you tell yourself when you're starting, especially with a C program. Because when you start your C program, it's like, 'all right, I have a couple command line parameters, I don't really want to write all my functions just to pass them, so I'm just going to declare a couple global variables and shove them in there, and I'll clean it up later.' Right? It's one of those little lies we tell ourselves. But you can't have immutable global variables in Rust. It just won't let you. You have to wrap it – you may as well just do the functions right. They're going to use your command-line arguments. It's the same with thread safety. You kind of have to do that upfront, and you don't get to make that assumption.\"\n\n## Looking to the future of the Rust programming language\n\nRust has a bright future, even if it might not be as widespread as other languages, Antony explains. \"I don't think it's ever going to be as popular as Go, just because Google is Google, and there's a lot of places that Go is really good for,\" he says. \"But for those places where you really want that fearless development, I think it'll continue to have a strong hold there.\"\n\nWatch Antony's Rust demo in full here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/INT_rGJr6JQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Read more about programming languages:**\n\nCan we solve the [COBOL programmer shortage?](/blog/cobol-programmer-shortage/)\n\nWhy we use [Ruby on Rails](/blog/why-we-use-rails-to-build-gitlab/) to build GitLab\n\nHow [Modern C and C ++ work](/blog/conan-c-cpp-package-management-integration/)\n\nCover image by [Zsolt Palatinus](https://unsplash.com/@sunitalap) on [Unsplash](https://unsplash.com)\n{: .note}\n",[852,894,1968],"tutorial",{"slug":1970,"featured":6,"template":681},"rust-programming-language","content:en-us:blog:rust-programming-language.yml","Rust Programming Language","en-us/blog/rust-programming-language.yml","en-us/blog/rust-programming-language",{"_path":1976,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1977,"content":1983,"config":1990,"_id":1992,"_type":17,"title":1993,"_source":18,"_file":1994,"_stem":1995,"_extension":21},"/en-us/blog/devsecops-security-standardization",{"title":1978,"description":1979,"ogTitle":1978,"ogDescription":1979,"noIndex":6,"ogImage":1980,"ogUrl":1981,"ogSiteName":667,"ogType":668,"canonicalUrls":1981,"schema":1982},"DevSecOps basics: 5 steps to standardize (and then scale) security","DevSecOps is incomplete without speed and scale. Standardize security to make it happen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663613/Blog/Hero%20Images/devsecops-security-standardization.jpg","https://about.gitlab.com/blog/devsecops-security-standardization","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOps basics: 5 steps to standardize (and then scale) security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2020-07-20\",\n      }",{"title":1978,"description":1979,"authors":1984,"heroImage":1980,"date":1986,"body":1987,"category":14,"tags":1988},[1985],"Vanessa Wegner","2020-07-20","\n_This is the fifth in our five-part series on [DevSecOps](/topics/devsecops/) basics. Part one offers nine tips to truly [shift left](https://about.gitlab.com/blog/efficient-devsecops-nine-tips-shift-left/). Part two outlines the steps needed to create [silo-free collaboration](https://about.gitlab.com/blog/achieve-devsecops-collaboration/). Part three looks at the importance of [automated security testing](https://about.gitlab.com/blog/devsecops-security-automation/). And part four details how to create a [strong security culture](https://about.gitlab.com/blog/security-culture-devsecops/)._\n\nStandardizing security policies comes in a variety of forms: regulatory compliance, access controls, acceptable use policies, security as code, and automation, to name a few. Ultimately, the idea is that your security team knows exactly what policies and methods have been used or applied to each project. \n\nThe goals of standardization are consistency, traceability, and repeatability. By consistently using the same security methods across all work, security knows what has been protected and what hasn’t. This helps them apply additional measures where necessary, and makes them aware of any needed exceptions. Ensuring that security methods are repeatable helps to expand adoption and scale security to the entire organization or enterprise. \n\n## Building a standardized security program\n\nA holistic security program should be composed of different levels of policies and compliance. Some policies should be company-wide, such as an [acceptable use policy](https://whatis.techtarget.com/definition/acceptable-use-policy-AUP), some will fulfill regulations like the [GDPR](https://gdpr-info.eu/) or [CCPA](https://oag.ca.gov/privacy/ccpa), and some will be specific to certain organizations within your business. \n\n### Standardizing security in DevOps\n\n[DevSecOps can be executed sustainably](/solutions/security-compliance/) at scale with standardized security practices. Here are five ways to standardize security across all of your development projects.\n\n#### Educate\n\nProvide security training and education to every employee. Companywide security initiatives [help to build a security culture](https://about.gitlab.com/blog/security-culture-devsecops/) and empower employees to take responsibility for security in their own work. Standardized training also spreads awareness of mandatory policies and alerts employees to the actions taken to both secure day-to-day operations and protect their customers. \n\n#### Coordinate\n\nCoordinate a predefined set of security requirements among dev, sec, and ops that can be coded into your pipeline and applied to every project. These can ensure regulatory compliance, foster secure coding practices, trigger red flags or notifications, and educate employees on security best practices.\n\n#### Authenticate\n\nAccess controls are a critical component of any security framework, and should be continually monitored and evaluated. By keeping close tabs on who needs access to what, you’re able to build a solid wall around your most critical processes and assets. This eliminates unnecessary access to sensitive data, and helps streamline tracing, recovery, and remediation efforts when something goes wrong. Access control policies also help defend your business by enhancing authentication requirements.\n\n#### Integrate\n\nEmbed scan and test tools within your development pipeline. Static and dynamic application security testing (SAST and DAST, respectively) can be set to run at every code commit and in the review app. Other tools and tests include IAST, fuzzing, licence compliance, container scanning, and dependency scanning (among others). Embedding tools directly into the pipeline allows you to know exactly what the code has been evaluated for, and also what the code has not been checked for. \n\n#### Automate\n\nIn DevSecOps, automation is the true key to standardized security practices as it allows for fast, secure development at scale. There are a number of ways to automate security within and around your development pipeline – the trick is to find an appropriate balance between automation and manual intervention. Automated policies should serve as guardrails that guide development smoothly from one security check to the next, but they should also allow for exceptions when needed. These guardrails should automatically generate reports from code scans and consolidate them into a [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) for review. This helps to minimize human error and any false positives or negatives, allows for consistent vulnerability reporting, and can be used to measure a team’s performance against secure coding expectations. Automation also helps to prevent overly complex security programs by reducing ad-hoc policies and redundant work.\n\n## The best security programs will change\n\nSecurity will never be a set-it-and-forget-it practice. The threat landscape is constantly changing, external regulations will continue to evolve, and internal business requirements will always keep you on your toes. While setting standards for security will help your team manage the workload, these standards need to be constantly re-evaluated and updated. Outdated security practices will undermine even the most solid programs, so it’s important to use part of the time saved from standardizing and automating to plan for the future. \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* [Case Study: How Jasper Solutions offers “DevSecOps in a box” with GitLab”](https://about.gitlab.com/customers/jasper-solutions/)\n* [How to capitalize on GitLab Security tools with external CI](https://docs.gitlab.com/ee/integration/jenkins.html)\n* [How to overcome toolchain security challenges with GitLab](https://about.gitlab.com/blog/toolchain-security-with-gitlab/)\n\nCover image by [Andrew Ridley](https://unsplash.com/@aridley88) on [Unsplash](https://unsplash.com/photos/jR4Zf-riEjI)\n{: .note}\n",[806,894,1255,1989],"zero trust",{"slug":1991,"featured":6,"template":681},"devsecops-security-standardization","content:en-us:blog:devsecops-security-standardization.yml","Devsecops Security Standardization","en-us/blog/devsecops-security-standardization.yml","en-us/blog/devsecops-security-standardization",{"_path":1997,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1998,"content":2004,"config":2009,"_id":2011,"_type":17,"title":2012,"_source":18,"_file":2013,"_stem":2014,"_extension":21},"/en-us/blog/ci-cd-changing-roles",{"title":1999,"description":2000,"ogTitle":1999,"ogDescription":2000,"noIndex":6,"ogImage":2001,"ogUrl":2002,"ogSiteName":667,"ogType":668,"canonicalUrls":2002,"schema":2003},"A surprising benefit of CI/CD: Changing development roles","DevOps and CI/CD make for faster code release, but they're also causing sweeping changes in dev and ops roles and responsibilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668027/Blog/Hero%20Images/cicd.jpg","https://about.gitlab.com/blog/ci-cd-changing-roles","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A surprising benefit of CI/CD: Changing development roles\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-07-16\",\n      }",{"title":1999,"description":2000,"authors":2005,"heroImage":2001,"date":2006,"body":2007,"category":14,"tags":2008},[890],"2020-07-16","\n\nWhen it comes to [CI/CD](/topics/ci-cd/) and [DevOps](/topics/devops/), the benefits are obvious: Get it right and cleaner code is released (a lot) faster.\n\nBut our [2020 Global DevSecOps Survey](/developer-survey/previous/2020/) found more subtle – and far less talked about – benefits. [CI/CD](https://docs.gitlab.com/ee/ci/) doesn't just allow developers to move faster and do more, it also allows them (and their operations counterparts) **to do less**. The automation required by CI/CD has drastically reduced the manual tasks involved in software development. With fewer time-consuming tasks, Dev and Ops roles and responsibilities are changing, in some cases dramatically.\n\nBut don't just take our word for it. We asked our 2020 survey takers to tell us in their own words how their roles and responsibilities are changing.\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## The back story\n\nTo understand the impact of CI/CD and DevOps, it helps to have the full picture. In our 2020 survey 83% of developers said they're releasing code faster than ever before. In fact, nearly 60% of them deploy multiple times a day, once a day, or once every few days (that's 15 percentage points higher than in 2019). Just in the last year about 21% of developers said their teams added CI to their process, while just over 15% brought in continuous deployment.\n\nThe benefits of these processes are clear, the developers told us:\n\n\"We've set up automated processes to build, test, and deploy code using a mixture of our own tools and open source tools.\"\n\n\"(We now have) automated tests, automated deployment on code review approval.\"\n\n\"A templatized CI/CD process has significantly sped up build and deploy times to multiple environments in multiple clouds.\"\n\n\"Automated testing using GitLab CI has meant less overhead when reviewing code and quicker and safer deploys.\"\n\n\"Automated testing and continuous integration have made our deployments safer and more optimized. Now everyone in the team has the permission to deploy the code.\"\n\n\"CI and CD tremendously reduced time for build and deploy applications and eliminated problems with the build environment.\"\n\n\"Automation has made one-click testing and deployment possible for us.\"\n\n\"Deployment has become a non-task. Bootstrapping new projects is 10x faster because of the reusable infrastructure.\"\n\n\"We reduced our CI build queue time by 75%, which allowed developers to have test results faster and allows QA to have build artifacts to test faster.\"\n\n\"Automation within the CI/CD pipeline (including test automation and the actual CD automation part) has significantly increased the delivery speed of our team.\"\n\nOne developer shared something that really resonated with us. In the pre-CI/CD world the developer had to submit a ticket to seven different departments before \"button press\" (deployment), a process that used to take six weeks. Now with automation, it takes just two hours.\n\n## Off the list\n\nWith all the changes brought by CI/CD we wondered what developers no longer have to do in order to release code. It's safe to say it was a long list! The number one change was no longer needing to do manual testing, followed closely by dropping manual deployments.\n\n\"There's no need to manually merge my code and push to staging and then production.\"\n\n\"(We don't have to) sync the code between multiple Devs – Git does it well.\"\n\n\"(I no longer have to) manually test, argue about code style, and update dependencies.\"\n\n\"We don't have to code our product to work with different platforms. We can just code our product and integrate it with a tool to work with different platforms.\"\n\n\"I never create a ticket to ask Ops to deploy.\"\n\nDevs aren't the only ones not doing things they used to. Operations team members also reported radically changing roles. Nearly 40% said their development lifecyle is \"mostly\" automated, meaning they're free now to tackle different responsibilities. Over half of them are managing cloud services, while 42% said they're now primarily managing hardware and infrastructure.\n\nThis is how they described their roles today:\n\n\"We build out and improve the CI/CD platform.\"\n\n\"I'm a Jack of all trades.\"\n\n\"Right now it's 60% new project work and 40% operations/fire-fighting/developer support.\"\n\n\"We ensure reliability and availability, improve developer efficiency, automation, tools, and observability.\"\n\n\"I keep the lights on.\"\n\n\"(I'm responsible for) anything between dev and ops. From planning to deployment but not monitoring and maintaining apps in production.\"\n\n## Lines are blurring\n\nSo at the end of the day what do these DevOps-driven changes mean for the software development lifecycle? For starters, roles are blurring. Over one-third of developers told us they define and/or create the infrastructure their apps run on and 14% monitor and respond to that infrastructure – both of these tasks were traditionally the responsibility of the operations team. In fact, nearly 70% of ops pros said their developers were able to provision their own environments.\n\nDev and ops roles are starting to converge but at the same time developers are doubling down on tasks they consider critical to improving code quality (and thus the speed of code release). Just shy of 50% of developers told us they are now conducting [code reviews](https://docs.gitlab.com/ee/development/code_review.html) weekly but a growing body of anecdotal evidence – based on write-in responses – show that for many teams daily code reviews are a reality, something that would not have been possible if they were bogged down with manual testing and deployments.\n\nGoing forward, the \"free time\" created by [CI/CD automation](https://docs.gitlab.com/ee/topics/autodevops/) won't go to waste, developers told us. A majority want to push their teams to do way more testing of all types (functional, A/B, unit, security) and of course to automate those processes.\n\nWhat should you be doing that you're not doing now?\n\n\"We want to shift left on testing.\"\n\n\"We want to write more test cases to cover 100% of everything.\"\n\n\"We want better code reviews, faster code reviews and more code reviews.\"\n\n\"We should be doing everything better.\"\n\n**Read more about CI/CD and DevOps:**\n\n- Just getting started? Get our [CI/CD guide for beginners](/blog/beginner-guide-ci-cd/)\n\n- [The pain (and promise) of code reviews](/blog/beginner-guide-ci-cd/)\n\n- [Why there is never enough testing](/blog/what-blocks-faster-code-release/)\n\nCover image by [Jason Wong](https://unsplash.com/@jasonhk1920) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[110,806,722],{"slug":2010,"featured":6,"template":681},"ci-cd-changing-roles","content:en-us:blog:ci-cd-changing-roles.yml","Ci Cd Changing Roles","en-us/blog/ci-cd-changing-roles.yml","en-us/blog/ci-cd-changing-roles",{"_path":2016,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2017,"content":2023,"config":2028,"_id":2030,"_type":17,"title":2031,"_source":18,"_file":2032,"_stem":2033,"_extension":21},"/en-us/blog/security-culture-devsecops",{"title":2018,"description":2019,"ogTitle":2018,"ogDescription":2019,"noIndex":6,"ogImage":2020,"ogUrl":2021,"ogSiteName":667,"ogType":668,"canonicalUrls":2021,"schema":2022},"DevSecOps basics: how to build a security culture in 6 steps","How to build a DevSecOps culture in your workplace. Get there faster by creating a strong security culture.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663608/Blog/Hero%20Images/security-culture-devsecops.jpg","https://about.gitlab.com/blog/security-culture-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOps basics: how to build a security culture in 6 steps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2020-07-15\",\n      }",{"title":2018,"description":2019,"authors":2024,"heroImage":2020,"date":2025,"body":2026,"category":14,"tags":2027},[1985],"2020-07-15","\n_This is the fourth in our five-part series on [DevSecOps](/topics/devsecops/) basics. Part one offers nine tips to truly [shift left](/blog/efficient-devsecops-nine-tips-shift-left/). Part two outlines the steps needed to create [silo-free collaboration](/blog/achieve-devsecops-collaboration/). And part three looks at the importance of [automated security testing](/blog/devsecops-security-automation/)._\n\n## Are you responsible for security?\n\nEven if it’s not in your title or job description, the answer is yes. Every employee is responsible for the security of their work. Unfortunately, many organizations don’t make this clear and don’t enforce it as policy. As vulnerabilities pile up on the desks of security engineers, developers wonder what’s taking so long – how many times does code have to be fixed before it’s deemed secure? [DevSecOps](/solutions/security-compliance/) flips traditional security on its head, but needs a strong security culture for sustainable success.\n\n## What is security culture?\n\nA security culture means that everyone – from board members to interns – must care about security and take actions to maintain it. Security should be considered in every piece of work and at every decision. \n\nThis may seem counterintuitive and not the efficiency promised by [DevSecOps](https://about.gitlab.com/solutions/security-compliance/). But by embedding security into every employee’s actions, the security team’s workload is streamlined and the end product is more secure. This is what companies mean when they talk about shifting security left: Bringing security forward in the software development life cycle to improve planning, test more code, and build accountability among non-security team members. \n\n## How to make security culture your default state\n\nUnless you’ve included security in every employee’s onboarding, creating a widespread security culture mindset will be challenging. Employees will need to think differently, behave differently, and eventually turn those changes into habits so that security becomes a natural part of their day-to-day work. \n\n### Step 1: Culture change starts at the top\n\nIf your organization has left security to \"the team,\" moving to a security culture will require board members and executives to be very involved in this change. Once execs are on board, work with thought leaders across the company to develop a security awareness and training program. Set the tone by making security a company-wide initiative, letting everyone know that security is top priority regardless of job function or organization. \n\n### Step 2: Awareness, education, and mutual understanding\n\nGive employees training on how they should incorporate security practices into everything they do. Transparency is key to building trust, so it’s important that employees understand why security is necessary and how they can contribute to the overall goal. On the other side, educate security practitioners about the demands placed on the business and [DevOps practices](/topics/devops/). This will help them help you create policies that move security and development forward together. \n\n### Step 3: Appoint security champions in dev \n\nSome employees will adopt security enthusiastically. Recruit those people to champion awareness and adoption among their peers. It may be helpful to provide your security champions extra resources and educational opportunities to boost their knowledge and make them an accessible resource for those around them. \n\n### Step 4: Encourage cross-functional collaboration\n\nTeam members should feel comfortable reaching out across functions, asking questions, and sharing (non-sensitive) information. DevSecOps breaks down silos to create a more efficient process, but it also does this to improve communication and build camaraderie between teams. If security is made into a multi-team effort, employees will feel encouraged to jump on the secure work bandwagon. \n\n### Step 5: Give developers the tools they need\n\nSecurity behaviors will be more readily adopted if they fit seamlessly into the developer’s workflow. [Security as code](/blog/how-to-security-as-code/) plays a big role here: Developers can produce more secure work when policies, tests, and scans are integrated into the pipeline and code itself. Excessive tool-switching will negate the benefits of shifting left, so it’s best to maintain efficiency by keeping your tech stack as simple as possible.\n\n### Step 6: Automate when appropriate\n\nAutomation is crucial for scaling security and will make adoption even easier for non-security employees. Within the developer’s workflow, static [application security](/topics/devsecops/) tests can be run against every code commit. Those scans can automatically produce a work ticket or [populate a security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/). \n\n## Culture change: Worth the challenge\n\nSecurity isn’t an option: It’s a requirement. Security culture will always be worth the effort. Making security a top priority for the people in your organization will fortify your tech defenses and help you innovate in ways that will (hopefully) withstand the ever-changing threat landscape. \n\n_How efficient are your DevSecOps practices? [Take our DevSecOps Maturity Assessment to find out.](https://about.gitlab.com/resources/devsecops-methodology-assessment/)_\n\n**Learn more about DevSecOps:**\n* [How to harden your GitLab instance](/blog/gitlab-instance-security-best-practices/)\n\n* [Why DevSecOps must start with automated security testing](/blog/devsecops-security-automation/)\n\n* [How to capitalize on GitLab Security tools with external CI](https://docs.gitlab.com/ee/integration/jenkins.html)\n\nCover image by [Lindsay Henwood](https://unsplash.com/@lindsayhenwood) on [Unsplash](https://unsplash.com/photos/7_kRuX1hSXM)\n{: .note}\n",[806,894,995],{"slug":2029,"featured":6,"template":681},"security-culture-devsecops","content:en-us:blog:security-culture-devsecops.yml","Security Culture Devsecops","en-us/blog/security-culture-devsecops.yml","en-us/blog/security-culture-devsecops",{"_path":2035,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2036,"content":2042,"config":2047,"_id":2049,"_type":17,"title":2050,"_source":18,"_file":2051,"_stem":2052,"_extension":21},"/en-us/blog/gitops-next-big-thing-automation",{"title":2037,"description":2038,"ogTitle":2037,"ogDescription":2038,"noIndex":6,"ogImage":2039,"ogUrl":2040,"ogSiteName":667,"ogType":668,"canonicalUrls":2040,"schema":2041},"Is GitOps the next big thing in automation?","We polled our community on Twitter to ask about GitOps. Here is what we found.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681428/Blog/Hero%20Images/iac-gitops-blog-post_with-gl-logo.png","https://about.gitlab.com/blog/gitops-next-big-thing-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Is GitOps the next big thing in automation?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-07-14\",\n      }",{"title":2037,"description":2038,"authors":2043,"heroImage":2039,"date":2044,"body":2045,"category":14,"tags":2046},[1483],"2020-07-14","\n\nInfrastructure management isn’t a new problem. After all, AWS has been publicly available since 2006. While the software development lifecycle is mostly automated, infrastructure remains a largely manual process that requires specialized teams. Infrastructure needs to be elastic, and automation would make that a much easier process than it is today.\n\n[GitOps](/topics/gitops/) is an emerging technology term that could be the answer many infrastructure teams have been searching for. At its core, GitOps is a process that helps teams automate IT infrastructure through processes they already use in application development.\n\nIt’s a framework we’re excited about. Naturally, we took it to Twitter.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Where are YOU at with \u003Ca href=\"https://twitter.com/hashtag/GitOps?src=hash&ref_src=twsrc%5Etfw\">#GitOps\u003C/a>?\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1277595216468418560?ref_src=twsrc%5Etfw\">June 29, 2020\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## What is GitOps?\n\nWhat makes [GitOps](/solutions/gitops/) unique is that it’s not a single product, plugin, or platform. Before we dive into what we can learn from these results, let’s define what exactly GitOps _is_.\n\nAt GitLab, we define GitOps as this:\n\n>GitOps is an operational framework that takes [DevOps](/topics/devops/) best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.\n\nGitOps happens in the same version control system as application development, enabling teams to collaborate more in a central location while benefiting from all the [built-in features of Git](https://devops.com/an-inside-look-at-gitops/). Infrastructure teams that practice GitOps use configuration files stored as code ([infrastructure as code](/topics/gitops/infrastructure-as-code/)).\n\nInfrastructure teams then take IaC and make changes using [merge requests](/blog/future-merge-requests-realtime-collab/) (MRs). Once changes are reviewed and approved, they are deployed using a CI/CD pipeline. With infrastructure changes codified, repeatable, and traceable, it leaves less room for human error and gets everyone on the same page.\n\n>GitOps = IaC + MRs + CI/CD\n\nWe thought it would be interesting to reach out to our Twitter followers to see just how many people are exploring this framework, or maybe haven’t heard of it at all. Here’s what we gleaned from our poll.\n\n## 23.8% use GitOps today\n\nWhile we have to admit that GitLab followers are probably going to be a sophisticated group, numbers like this are still very encouraging. If almost a quarter of respondents are using this new framework, it tells us that GitOps is a viable way of automating infrastructure.\n\n## 10.6% plan to implement GitOps\n\nImplementing a new process can be difficult, even for the most organized teams. GitOps allows for greater collaboration, but that is not necessarily something that comes naturally. For infrastructure teams used to making quick, manual changes, this new process is a big departure. If more than 10% of respondents are looking to get started with GitOps, we can help them understand what goes into adopting the new framework.\n\n## 11.6% have looked but not committed to GitOps\n\nThis kind of “shopping cart abandonment” differs from the type we’re most familiar with, but it has some similarities. For those that have heard of GitOps, what prevented them from implementing it and what hurdles did they anticipate?\n\nGitOps principles can be applied to all types of infrastructure automation, including VMs and containers, and can be very effective for teams looking to manage [Kubernetes clusters](/solutions/kubernetes/). But there might be some confusion on whether Kubernetes is required for GitOps (it’s not). Still, over 11% of respondents are familiar with GitOps but may not understand how it can apply to them.\n\n## 54% haven’t explored GitOps yet\n\nSince GitOps is still emerging, it’s not surprising that more than half of the respondents haven’t explored it yet. GitOps is an exciting topic because it offers automation using many of the same tools organizations already use, but before committing to a brand new process, it’s important for organizations to know how it works.\n\nCollaboration is part of what makes DevOps so effective, and [GitOps brings that same spirit of code collaboration into the infrastructure provisioning process](/topics/gitops/gitops-gitlab-collaboration/). Managing infrastructure through the same version control system used for application development brings a new level of transparency across the entire organization.\n\nAs we continue to explore GitOps, information like this poll lets us know where the community is in the adoption of new processes. Could GitOps be the next big thing in automation?\n\nIf you’d like to learn more about GitOps and how it works, check out this panel with GitOps experts from [Weaveworks](https://www.weave.works), [HashiCorp](https://www.hashicorp.com), [Ansible](https://www.ansible.com), and GitLab where we discuss:\n\n*   How GitOps is changing the landscape of infrastructure management\n*   What successful GitOps looks like\n*   What teams need to get started on their GitOps journey\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>  \nWatch GitLab's [GitOps expert panel](/why/gitops-infrastructure-automation/) webcast\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\n**Read more about infrastructure:**\n\n[Why GitOps should be the workflow of choice](/blog/why-gitops-should-be-workflow-of-choice/)\n\n[How to use GitLab and Ansible to create infrastructure as code](/blog/using-ansible-and-gitlab-as-infrastructure-for-code/)\n\n[How infrastructure teams use GitLab and Terraform for GitOps](/topics/gitops/gitlab-enables-infrastructure-as-code/)\n",[110,806,268],{"slug":2048,"featured":6,"template":681},"gitops-next-big-thing-automation","content:en-us:blog:gitops-next-big-thing-automation.yml","Gitops Next Big Thing Automation","en-us/blog/gitops-next-big-thing-automation.yml","en-us/blog/gitops-next-big-thing-automation",{"_path":2054,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2055,"content":2061,"config":2066,"_id":2068,"_type":17,"title":2069,"_source":18,"_file":2070,"_stem":2071,"_extension":21},"/en-us/blog/devsecops-security-automation",{"title":2056,"description":2057,"ogTitle":2056,"ogDescription":2057,"noIndex":6,"ogImage":2058,"ogUrl":2059,"ogSiteName":667,"ogType":668,"canonicalUrls":2059,"schema":2060},"Automated security testing for DevSecOps","We share four fool-proof ways to bring your security automation to the next level and five reasons why it's critical.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662504/Blog/Hero%20Images/devsecops-automated-security.jpg","https://about.gitlab.com/blog/devsecops-security-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automated security testing for DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2020-07-08\",\n      }",{"title":2056,"description":2057,"authors":2062,"heroImage":2058,"date":2063,"body":2064,"category":14,"tags":2065},[1985],"2020-07-08","\n\n_This is the third in our five-part series on getting started with [DevSecOps](/topics/devsecops/). Part one gives you nine ways to [shift security left](/blog/efficient-devsecops-nine-tips-shift-left/). Part two outlines the steps needed to create [silo-free collaboration](/blog/achieve-devsecops-collaboration/)._\n\nNearly 83% of developers in [GitLab’s 2020 DevSecOps survey](/developer-survey/) say they’re releasing code faster today than ever before thanks to [DevOps](/topics/devops/). About 65% also say security is shifting left in their organizations. How far left is that shift? Not that far: Over 60% of developers don’t actually run static [application security](/topics/devsecops/) testing (SAST) scans, and 73% don’t conduct dynamic application security testing (DAST) scans.\n\nThis needs to change.\n\nSecurity is often a bottleneck to faster releases but it is much too risky to minimize or ignore. DevSecOps promises to bring security  forward in the software development lifecycle (SDLC). This can be done a number of ways but automated security testing streamlines adoption and scalability. A respondent to this year’s DevSecOps Survey summarized it nicely:\n\n> Automated testing and continuous integration have made our deployments safer and more optimized. Now everyone in the team has the permission to deploy the code.\n\n## The need for security automation and good security practices\n\nThere is an attempted cyber-attack [every 44 seconds](https://us.norton.com/blog/emerging-threats/cybersecurity-statistics#:~:text=There%20isn't%20concise%20data,people%20being%20hacked%20per%20year.) on average. \n\n_Every. 44. Seconds._ \n\nThis also equates to approximately 2,200 daily attacks resulting in about 800,000 people being hacked each year. Unfortunately, no one has the time, patience, or bandwidth to keep their eyes and hands ready to stop or address cyber attacks on the horizon. That’s why security automation tools exist.\n\nAnd consider this: cyber attackers aren’t doing everything by hand – they employ automation too. This means security processes also [need automation to keep up](https://www.checkpoint.com/cyber-hub/cyber-security/security-automation/#:~:text=Security%20automation%20is%20the%20automation,scale%20to%20handle%20growing%20workloads.). \n\nA security automation solution can include real-time monitoring tools that constantly manage security vulnerabilities and take automatic action where needed. It’s like adding a second pair of invisible hands to the team to help prevent and resolve security issues. Increased security measures can save any organization time and money and avoid the loss of sensitive files. \n\n\n## 4 Ways to automate security in software development\n\n[Automation](https://docs.gitlab.com/ee/topics/autodevops/) comes in all shapes and sizes. Scans and policies can be programmed manually or come as set operations out of the box; scans can be triggered automatically at code commit or manually initiated; and these scans can result in automated remediation and reports or they can require human intervention. Here are four ways automated security testing can be integrated into your software development practices:\n\n1. Automate security scans for every code change by [running SAST scans](https://docs.gitlab.com/ee/user/application_security/sast/index.html). For ease of assessment, results should be sorted by the priority level of the vulnerability.\n\n1. Scan results should automatically initiate a work ticket or issue, or may stop a build depending on the policy in place. These results should be presented to the developer – in the workspace or IDE in use to avoid context switching – for instant remediation.\n\n1. Policies are automatically applied upon code commit with the option to capture and approve exceptions as needed.\n\n1. Analyze running web applications for known vulnerabilities [using DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/). In GitLab, DAST scans can be automated by [including the CI job in your existing .gitlab-ci.yml file](https://docs.gitlab.com/ee/user/application_security/dast/#configuration), or by [using Auto DAST](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-dast).\n\n\n\n## 5 Benefits of automated security\n\nIn addition to making jobs easier across development, security, and operations, automated security testing will help your team produce a safer and better-quality result.\n\n1. **Reduced human error.** Across all functions, automation reduces human error by taking the manual work out of tedious processes that rely on excessive attention to detail.\n\n1. **Early security intervention.** By placing security earlier in the SDLC, threats and vulnerabilities can be detected and addressed faster – hopefully before there’s even a chance that they’re exposed.\n\n1. **Streamlined vulnerability triage.** Automated scan reports can present the threat level of any vulnerability so that developers and security engineers alike can decide which must be addressed immediately and who is responsible for resolving the problem.\n\n1. **Repeatable security checks.** Any automated task should be repeatable, which means that all code can be reviewed and assessed the same way every time. This creates a trusted and secure environment and code base, and also helps reviewers identify patterns when results are presented in a consistent manner.\n\n1. **Responsibility clarification.** Automation takes uncertainty out of DevSecOps. Shifting security can cause confusion about who is responsible for what. But automated scans can present remediation options for the party responsible _at that stage of development_.\n\nBut it is also important to find a productive balance between automated security testing and manual work. For example, trying to automate overly rigorous policies may prove detrimental to business objectives and may not be realistically achieved – it’s important to find a balance between policy compliance and efficiency. It’s also key that automation doesn’t obstruct visibility. Make sure there is still a trail of operations to review if necessary – automated processes should still generate reports of what was done, when, and why the action was triggered. Last, but certainly not least: Automation is **not** meant to replace human beings. It is a tool meant to make their work more efficient and help them produce better results for the team, the business, and the customer.\n\n## Security automation vs. security orchestration\n\nThough they are different concepts, security automation and security orchestration perform similar functions. One serves the other to make security processes more efficient. \n\nSecurity automation focuses on automating individual tasks (possibly with AI technology) to simplify essential processes for security analysts. On the flip side, security orchestration connects tools in use alongside automation and streamlines the whole security procedure. Orchestration drives efficient automation.\n\n## Types of security automation tools\n\nTo keep track of security incidents (and prevent them in the future), teams use security automation tools and different types of security scanning. A few common types of security automation tools include:\n\n- Security Information and Event Management (SIEM): SIEMs help to automatically collect data across multiple sources and use it to give contextual background about security incidents.\n- Security Orchestration, Automation, and Response (SOAR): SOAR takes SIEM a step further than just contextual data collection and adds automated response options to the mix. SOAR alerts security analysts to problems and shuts down cyber threats automatically. \n- Extended Detection and Response (XDR): This proactive, automated solution combines SIEM, SOAR, and other security options into one managed source.\n\n## How security automation works with security analysts\n\nA human can’t do all of the necessary security work, nor can a security automation tool. It’s a symbiotic relationship to ensure that an organization feels the least amount of negative impact from a cyber attack possible. \n\nA security analyst, responsible for vulnerability management by identifying and resolving security flaws and conducting [audits](https://about.gitlab.com/blog/what-you-need-to-know-about-devops-audits/), gets a lot of help from automation. An automated security system can make someone aware of a problem and even help to resolve it while removing manual time constraints.\n\n**Read more about DevSecOps:**\n* [Efficient DevSecOps: 9 tips for shifting left](https://about.gitlab.com/blog/efficient-devsecops-nine-tips-shift-left/)\n* [Want better DevSecOps? Try cross-functional collaboration](https://about.gitlab.com/blog/achieve-devsecops-collaboration/)\n* [Compliance made easy with GitLab](https://about.gitlab.com/blog/compliance-made-easy/)\n* [How application security engineers can use GitLab to secure their projects](https://about.gitlab.com/blog/secure-stage-for-appsec/)\n\nCover image by [Daniele Levis Pelusi](https://unsplash.com/@yogidan2012) on [Unsplash](https://unsplash.com/photos/Pp9qkEV_xPk)\n{: .note}\n\n\n\n",[806,894,1255,1989],{"slug":2067,"featured":6,"template":681},"devsecops-security-automation","content:en-us:blog:devsecops-security-automation.yml","Devsecops Security Automation","en-us/blog/devsecops-security-automation.yml","en-us/blog/devsecops-security-automation",{"_path":2073,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2074,"content":2079,"config":2084,"_id":2086,"_type":17,"title":2087,"_source":18,"_file":2088,"_stem":2089,"_extension":21},"/en-us/blog/challenges-of-code-reviews",{"title":2075,"description":2076,"ogTitle":2075,"ogDescription":2076,"noIndex":6,"ogImage":1498,"ogUrl":2077,"ogSiteName":667,"ogType":668,"canonicalUrls":2077,"schema":2078},"The challenges of code reviews","The 2020 DevSecOps Report discovers that developers are bogged down by code reviews. Are they worth the trouble?","https://about.gitlab.com/blog/challenges-of-code-reviews","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The challenges of code reviews\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2020-07-03\",\n      }",{"title":2075,"description":2076,"authors":2080,"heroImage":1498,"date":2081,"body":2082,"category":14,"tags":2083},[1635],"2020-07-03","\n\n## Code review and quality challenges\n\nCode reviews are stressful. As a merge request owner, you're giving others an inside look at your abilities and thought processes. As a reviewer, there’s something quite daunting about serving as the last stop before code is merged to the main branch. When teams face uncertain processes, lengthy wait times, and lack of buy-in, an inherently difficult task can soon feel Sisyphean. In GitLab’s [2020 Global DevSecOps Survey](/developer-survey/previous/2020/), over 3600 software professionals shared their thoughts on code reviews, and the results reinforce that code reviews are a challenging aspect of software development.\n\n_Our [2022 Global DevSecOps Survey](/developer-survey/) has the latest insights from over 5,000 DevOps professionals. You can also compare it with [previous year surveys](/developer-survey/previous/)_\n\n## Why is code review important?\n\nCode reviews enable developers to more easily identify bugs, because they’re assessing the code with a fresh perspective. Shipping clean code decreases the likelihood of errors nestling into the main branch. Teams turn to code reviews as a way to share knowledge, mentor newer developers, and ease the burden of development. When everyone reviews code, there is no longer a single point of failure that can halt delivery and risk missing releases or business goals.\n\nStudies show that [code reviews increase collaboration](https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/), because the process of working together to improve code quality creates a shared ownership of the codebase. Developers work towards a common goal rather than feel proprietary attachment to their lines.\n\n## Code reviews according to developers\n\nIn the 2020 DevSecOps Report, developers candidly shared their views on code reviews, with many highlighting the challenges of ensuring code quality standards. Here’s a look at what developers said about code reviews.\n\n| **How frequently does your team conduct code reviews?** |\n| Weekly |  48.9% |\n| Bi-weekly |  13.6% |\n| Monthly |  9.5% |\n\nMost respondents do code reviews weekly, indicating that teams are committed to making them part of their workflow.\n\n| **How do code reviews happen?** |\n| Messaging chat |  40.8% |\n| Offline |  28.6% |\n| Other |  20.9% |\n| Video |  9.7% |\n\nDocumentation is an important part of a successful code review. Authors should be able to refer to a checklist or assessment that highlights areas of improvement or excellence. Respondents indicated that the majority of code reviews occur in messaging chat or offline, which may enable written documentation.\n\n| **How do you prefer to do code reviews?** |\n| IDE | 44% |\n| Browser |  41.4% |\n| Code/text editor |  14.6% |\n\nConducting code reviews in integrated development environments and browsers is unsurprising, because there’s a low barrier to entry in participating and collaborating with others.\n\nMany respondents shared their thoughts about the specific challenges they face when doing code reviews.\n\n_“Code reviews can take a long time due to the lack of reviewers.”_\n\nWithout enough reviewers, code reviews can become overwhelming for the few people who make time for this task. Code reviews become a burdensome activity that can prevent certain team members from meeting goals and delivering.\n\n_“As an all-remote company, we haven't yet solved the problem of needing reviews from people in much different time zones and working hours. We have a strict code review process, and it often takes several days for the reviewer to respond to requests for review. Planning takes a while, and our code review process, while awesome, takes some time.”_\n\nWorking in a distributed team can have drawbacks, especially when waiting for domain experts or maintainers to review code. While processes are important in establishing workflow, it’s equally important not to slow down team members with process.\n\n_“Our code review process is disorganized. It took more time when reviewing the code and testing than expected.”_\n\nOn the other hand, not having an established review process can lead to stress, confusion, and pressure. Team members may dread code reviews due to the disorganization, which can lead to insufficient assessment.\n\n_“Some experts do not understand the importance of code review and regard it as a secondary task.”_\n\nWhen some team members do not value code review, they may deprioritize it and be reluctant participants. Collaboration is a key component in ensuring successful code reviews, and lack of buy-in can slowly erode morale.\n\n## Are code reviews worth it?\n\nBased on the frustration level found in the 2020 DevSecOps Survey, it’s hard not to wonder whether code reviews are worth the trouble. But all complaints aside, it’s clear that the review process is helpful.\n\n| **How valuable are code reviews?** |\n| Very valuable | 61.9% |\n| Moderately valuable |  33.3% |\n| They have no effect |  3.7% |\n\nCode reviews are worth the difficulties, because they help teams collaborate to maintain a clean codebase, learn from each other to develop new skills, and ensure that innovative solutions solve complex problems. In order for team members to feel like code reviews are valuable, IT leaders must invest time in establishing processes to ensure that everyone has the tools and knowledge to succeed.\n\n## Ready to learn more about code reviews?\n\nHere are a few resources to help you alleviate the challenges of code review.\n\n**[Read GitLab’s mandatory code review process →](https://docs.gitlab.com/ee/development/code_review.html)**\n\n**[Learn how to troubleshoot delays with GitLab’s Code Review Analytics tool →](/blog/troubleshoot-delays-with-code-review-analytics/)**\n\n**[Discover better code reviews GitLab style →](/blog/better-code-reviews/)**\n\n**[What blocks faster code releases? It starts with testing\n →](/blog/what-blocks-faster-code-release/)**\n\n**[Read about GitLab’s experience with Reviewer Roulette →](/blog/reviewer-roulette-one-year-on/)**\n",[1115,722,806],{"slug":2085,"featured":6,"template":681},"challenges-of-code-reviews","content:en-us:blog:challenges-of-code-reviews.yml","Challenges Of Code Reviews","en-us/blog/challenges-of-code-reviews.yml","en-us/blog/challenges-of-code-reviews",{"_path":2091,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2092,"content":2098,"config":2105,"_id":2107,"_type":17,"title":2108,"_source":18,"_file":2109,"_stem":2110,"_extension":21},"/en-us/blog/compliance-made-easy",{"title":2093,"description":2094,"ogTitle":2093,"ogDescription":2094,"noIndex":6,"ogImage":2095,"ogUrl":2096,"ogSiteName":667,"ogType":668,"canonicalUrls":2096,"schema":2097},"How to build a compliance program with ease","Compliance audits should not cause headaches. Learn how building compliance programs and carrying compliance audits effectively using GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667086/Blog/Hero%20Images/blog-compliance.jpg","https://about.gitlab.com/blog/compliance-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to build a compliance program with ease\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Saumya Upadhyaya\"},{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-07-02\",\n      }",{"title":2093,"description":2094,"authors":2099,"heroImage":2095,"date":2102,"body":2103,"category":14,"tags":2104},[2100,2101],"Saumya Upadhyaya","Dov Hershkovitch","2020-07-02","The implimentation of a compliance program requires organizations to adopt processes that help comply with regulatory and legal requirements. GitLab makes it easy to wrestle the \"compliance beast\" but to understand what that really means it helps to take a look at this very complex and challenging area.\n\n## An effective compliance program: lots of moving parts\n\nCompliance processes are often costly, manual and cumbersome to implement and maintain. Even organizations that are advanced in compliance maturity still maintain compliance processes within spreadsheets, file storage systems (such as Google Drives or Dropbox) and emails, making wading through the documentation required to prove compliance extremely painful.\n\nFurther compounding this pain is the number of third party applications an organization uses to operate its business. The use of these tools and services add complexity because they’re all subject to the underlying policies and procedures the company has established. This means auditing not just your own organization’s processes, but those of your vendors.\n\nHowever, compliance is essential. With regulatory scrutiny being high, increasing cyber security breaches and the high costs of non compliance manifesting in the form of revenue loss, business disruptions, fines, damage to brand image, impacted stock prices and so on - the need for compliance is not lost on organizations. In fact, non compliance penalties [can be much lower](https://www.justice.gov/opa/pr/antitrust-division-announces-new-policy-incentivize-corporate-compliance) when an organization can demonstrate the presence of an effective compliance program.\n\n## Why is achieving an effective compliance program so difficult?\n\nIn spite of organizations acknowledging the importance of compliance, achieving an effective compliance program seems elusive.\n\nCurrently, there is a lot of administrative overhead associated with compliance. The task that gives most compliance professionals a headache is finding the documentation or evidence they need. With most organizations still using a combination of spreadsheets, drives and emails to manage their compliance programs and the added complexity of demonstrating compliance within their third-party tools or services, it is increasingly difficult for compliance teams to scale.\n\nIt can be even more daunting trying to keep track of the growing regulatory compliance requirements and internal controls to manage these requirements. In the cases where organizations have introduced additional Governance, Risk and Compliance (GRC) tools within their organizations, these tools are not integrated into their development and operational tools - thereby creating yet another compliance silo.\n\nDevelopment and operations teams perceive compliance-related activities as slowing down their velocity, creating an inherent friction with the compliance teams, thereby making compliance processes even slower and less effective.\n\n## Building your compliance program\n\nAny well defined compliance program requires internal controls that allow:\n\n1. Defining rules and policies aligned with your organizational or regulatory/legal requirements\n1. Generating and maintaining the evidence of policy adherence\n1. Enforcing the defined rules and policies\n1. Demonstrating compliance with easy-to-access and readable reports and evidence artifacts\n1. Ongoing risk assessments to detect and mitigate gaps in compliance\n\nAny compliance program that does not bring together all of these controls incurs the administrative overhead of maintenance. Organizations often run the risk of overspending on a disparate set of tools, creating data silos resulting in them being no better than when they started their compliance process.\n\n## GitLab makes compliance easy\n\nBeing a single application where developers, security and operations professionals congregate, GitLab is well positioned to automate your compliance processes to answer questions that may arise from your auditors or leadership teams.\n\n1. With [granular user roles and permissions](https://docs.gitlab.com/ee/user/permissions.html), GitLab allows you to enforce segregation of duties. You can easily define your organization’s policies regarding credentials, security scanning, and rules for approvers. Granular permission control also allows you to enforce approvers for determining what goes into production\n1. With [application security](/solutions/security-compliance/) being part of the pipeline, GitLab helps you to automate your information security compliance requirements\n1. GitLab helps you define [custom projects](https://docs.gitlab.com/ee/user/project/working_with_projects.html#project-templates) (such as HIPAA, SOX etc) to track adherence to various different compliance frameworks in a single place. Within the projects, GitLab issues and merge requests are also the central places to collaborate, maintain documents, track chain of custody and overrides, without maintaining these on disparate tools. Additionally, you can define a common set of policies to be applied to a set of projects labeled with a specific compliance framework (such as HIPAA, SOX etc)\n1. You can meet the traceability requirements for audits - such as user actions, permission changes, approval changes, logins, password changes and so on via [Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html)\n1. GitLab also provides a consolidated view of various compliance signals such as merge request approvals in the [compliance dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html). Going forward, this compliance dashboard aims to provide compliance insights in a consolidated view with all relevant signals such as segregation of duties, framework compliance, license compliance, pipeline and MR results. The compliance dashboard will continue to evolve to include more data to save compliance professionals time when managing their GitLab compliance posture.\n\nLearn more about our Compliance Solution [here](/solutions/compliance/).\n\n## What’s next\n\nOur [vision for Compliance Management](/direction/dev/#manage-1) is strong. Watch Matt Gonzales, Senior Product Manager for the compliance group, talk about our vision.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XFilPpXwVzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nConsider joining the [Compliance Special Interest Group](https://gitlab.com/gitlab-org/ux-research/-/issues/532) to help shape our direction for compliance management within GitLab.\n\n*Read more about compliance and GitLab:*\n\n[Compliance-as-code explained](/blog/get-started-compliance-as-code/)\n\n[How we chose our compliance framework](/blog/choosing-a-compliance-framework/)\n\n[Tracking agreements in GitLab just got easier](/blog/make-tracking-agreements-simple-compliance-dashboard/)\n\nCover image by joaosilas on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[806,995],{"slug":2106,"featured":6,"template":681},"compliance-made-easy","content:en-us:blog:compliance-made-easy.yml","Compliance Made Easy","en-us/blog/compliance-made-easy.yml","en-us/blog/compliance-made-easy",{"_path":2112,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2113,"content":2119,"config":2124,"_id":2126,"_type":17,"title":2127,"_source":18,"_file":2128,"_stem":2129,"_extension":21},"/en-us/blog/achieve-devsecops-collaboration",{"title":2114,"description":2115,"ogTitle":2114,"ogDescription":2115,"noIndex":6,"ogImage":2116,"ogUrl":2117,"ogSiteName":667,"ogType":668,"canonicalUrls":2117,"schema":2118},"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":2114,"description":2115,"authors":2120,"heroImage":2116,"date":2121,"body":2122,"category":14,"tags":2123},[1985],"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",[1447,974,806,894],{"slug":2125,"featured":6,"template":681},"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":2131,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2132,"content":2137,"config":2142,"_id":2144,"_type":17,"title":2145,"_source":18,"_file":2146,"_stem":2147,"_extension":21},"/en-us/blog/many-meanings-multicloud",{"title":2133,"description":2134,"ogTitle":2133,"ogDescription":2134,"noIndex":6,"ogImage":1498,"ogUrl":2135,"ogSiteName":667,"ogType":668,"canonicalUrls":2135,"schema":2136},"Understand the many meanings of multicloud","In our 2020 DevSecOps Survey we uncovered a number of different definitions of 'multicloud.' Here's how to make sense of it all.","https://about.gitlab.com/blog/many-meanings-multicloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understand the many meanings of multicloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-06-30\",\n      }",{"title":2133,"description":2134,"authors":2138,"heroImage":1498,"date":2139,"body":2140,"category":14,"tags":2141},[890],"2020-06-30","\n\nWhat does multicloud mean? We've heard – and used – the term '[multicloud](/topics/multicloud/)' for a while now but, like most industry terms, it can be defined differently by different groups. So in our just released [2020 Global DevSecOps Survey](/developer-survey/) we asked 3652 people from 21 countries across 19 job categories what multicloud actually means to them.\n\nThe majority of respondents (36%) said multicloud means the ability to deploy some applications on Azure, some on AWS, and some on Google. Almost 35% said they thought it meant deploying applications across multiple cloud providers with different components on different clouds. And finally almost 29% said it meant being able to move an app from one cloud provider to another.\n\nIt got even more interesting when we asked them to describe how multicloud is used in their organizations. A clear majority aren't doing \"multicloud\" yet - their teams use one cloud provider only, or none at all. (For context, over 18% of survey respondents said their organizations are not currently using any cloud provider.)\n\n_We don't use multi cloud here. Not yet._\n\n_We will deploy to the cloud the customer requires. But the whole application sits on one cloud._\n\n_We don't, on purpose, because we do not subscribe to the vendor lock-in argument and therefore multi-cloud would require more resources than we feel it is worth._\n\nOthers took the term multicloud literally, saying their teams use several different platforms.\n\n_We have moved workloads from one provider to another to address performance issues._\n\n_Multiple clouds used for different purposes and some on prem hyperconverged thrown into the mix._\n\n_We use different cloud providers for different projects._\n\n_We use Digital Ocean + GCP + AWS_\n\nAnd some took multicloud further.\n\n_We're switching between providers while testing new functionalities for our innovative apps._\n\n_We built our own PaaS based on Kubernetes. This system could be deployed/provisioned on any K8S ready public cloud provider or to any other compatible hosting system._\n\n_For us \"multicloud\" means simultaneously using multiple cloud providers, not just ability to migrate apps between them._\n\n_We avoid vendor lock-in by being able to run on any cloud seamlessly_\n\n## Defining the stages of multicloud\n\nSo is there a single definition of multicloud? The answer is yes, but... Our CEO [Sid Sijbrandij](/company/team/#sytses) argues that multicloud isn't something static but rather a series of staged workflows that mean different things to organizations depending on where they are in their DevOps journey. His [maturity model](https://medium.com/gitlab-magazine/multi-cloud-maturity-model-2de185c01dd7) consists of seven stages, starting with everything on a single cloud and ending with true data portability in multiple clouds.\n\n[William Chia](/company/team/#williamchia), senior product marketing manager for cloud native and GitOps, suggests starting by asking the question \"Where are your workloads running?\" For many organizations the answer will be one workload is running on one cloud and another workload might be running in a different cloud – the team is using multiple clouds. This is an early stage of maturity on the journey to multicloud adoption. \n\nA team might want to be able to deploy the same workload to different clouds, a step that would help avoid vendor lock-in, provide backup coverage in case of failures, and perhaps offer some leverage that might help with costs, William explains. But there's a serious trade-off in that step because the engineering resources required to create a platform to deploy to multiple clouds are significant.\n\n\"The Utopian goal of getting to a place where you can have the same workloads on multiple clouds easily is not necessarily desirable for everyone or even the majority of people,\" William says. \"It costs a lot to do that and you need to have the engineering staff who understand both clouds. There's a high cost to multicloud.\"\n\nThe final stages of multicloud, which William says today represents just a small fraction of companies today, is where the same application is deployed to different clouds and workloads as well as data for can be dynamically shifted between multiple clouds. \n\nSo the often-used term \"multicloud\" does legitimately have evolving definitions and that will likely continue as DevOps matures. One step on the multicloud journey that unlocks powerful benefits with little overhead is the jump to [work***flow*** portability](/topics/multicloud/). While most companies aren't close to the highest reaches of multicloud maturity, almost any company can get started down the path. It's clear that the best implementations take into consideration the tradeoffs and choose right amount of multicloud for the task at hand.\n\n**Read more about multicloud:**\n\n[Leverage GitLab CI/CD to get the most out of multicloud](/blog/gitlab-ci-cd-is-for-multi-cloud/)\n\n[The role cloud-agnostic DevOps can play](/blog/ci-cd-the-ticket-to-multicloud/)\n\n[Seven best practices for multicloud security](/blog/multi-cloud-security/)\n",[1115,722,806],{"slug":2143,"featured":6,"template":681},"many-meanings-multicloud","content:en-us:blog:many-meanings-multicloud.yml","Many Meanings Multicloud","en-us/blog/many-meanings-multicloud.yml","en-us/blog/many-meanings-multicloud",{"_path":2149,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2150,"content":2156,"config":2161,"_id":2163,"_type":17,"title":2164,"_source":18,"_file":2165,"_stem":2166,"_extension":21},"/en-us/blog/efficient-devsecops-nine-tips-shift-left",{"title":2151,"description":2152,"ogTitle":2151,"ogDescription":2152,"noIndex":6,"ogImage":2153,"ogUrl":2154,"ogSiteName":667,"ogType":668,"canonicalUrls":2154,"schema":2155},"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":2151,"description":2152,"authors":2157,"heroImage":2153,"date":2158,"body":2159,"category":14,"tags":2160},[1985],"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",[1447,974,806,894],{"slug":2162,"featured":6,"template":681},"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":2168,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2169,"content":2174,"config":2179,"_id":2181,"_type":17,"title":2182,"_source":18,"_file":2183,"_stem":2184,"_extension":21},"/en-us/blog/what-blocks-faster-code-release",{"title":2170,"description":2171,"ogTitle":2170,"ogDescription":2171,"noIndex":6,"ogImage":1498,"ogUrl":2172,"ogSiteName":667,"ogType":668,"canonicalUrls":2172,"schema":2173},"What blocks faster code releases? It starts with testing","Our 2020 DevSecOps Survey found testing was the number one reason for release delays, but planning and code reviews were also challenges. Here’s what you need to know.","https://about.gitlab.com/blog/what-blocks-faster-code-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What blocks faster code releases? It starts with testing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-05-29\",\n      }",{"title":2170,"description":2171,"authors":2175,"heroImage":1498,"date":2176,"body":2177,"category":14,"tags":2178},[890],"2020-05-29","\nOur [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals.\n\nFirst, the good news: do DevOps right and you’ll release code faster. In fact, 83% of our [2020 Global DevSecOps Survey](/developer-survey/) respondents said code heads out the door more quickly thanks to a successful DevOps practice.\n\nBut we also asked survey takers what was most likely to delay their code, and their responses highlighted some of the toughest challenges DevOps practitioners face. When it comes to delays, 47% said testing was the culprit, while 39% said planning, and 28% said code review.\n\nAt a time when faster software releases are perhaps even more critical than ever before, it may be helpful for your organization to take a hard look at what blocked our 3652 respondents from 21 countries across 19 job categories. Test, planning, and code reviews are essential steps in DevOps, but as our survey responses show, they can easily turn into black holes of time and frustration.\n\n## The trouble with testing\n\nLet’s just say it: Testing is hard. A key component of successful DevOps, testing is apparently the hill many teams die on – repeatedly. In [our 2019 survey](/blog/global-developer-report/) 49% of all respondents pointed their fingers squarely at test as the primary cause of delays, and it’s discouraging that the percentage was only slightly smaller this year.\n\n_\"We are slow and do not test very well. We do Big Bang deployments.\"_\n\nThe trouble with testing boils down to essentially two issues: there are never enough tests done and automating testing is tricky. We asked developers to assess their tasks and to tell us what they should be doing but are not. The vast majority of them said they weren’t doing enough testing, period.\n\n_\"Not enough tests (or none) and then the code doesn’t work in production. Some collaborators have poor IT skills.\"_\n\n_\"Too little testing done too late.\"_\n\n_\"We need more test cases to cover 100% of everything.\"_\n\nJust 12% of survey takers told us their teams had full test automation and about 25% said they either have nothing set up or are only beginning the automation journey.\n\nThere are a few glimmers of hope. For starters, teams that have cracked the test automation code told us about the concrete benefits.\n\n_\"We do [TDD (test driven development)](https://www.agilealliance.org/glossary/tdd/). QA and dev act as a team. We have automated tests running parallel with developing code.\"_\n\nAnd 16% of survey respondents either have a \"bot\" reviewing their code or have an AI/ML tool in place for testing. It's early days for AI-powered testing, clearly, but the results are intriguing.\n\n## The truth about planning\n\nTesting may be technically challenging but planning is also a significant stretch for many development teams. A developer shared that work happened \"without much planning\" and that was a common refrain.\n\nOne reason for a perceived or real lack of planning could lie in the fact that many software teams use hybrid development methodologies, each of which have their own (not necessarily compatible) planning practices. Feedback from survey takers seemed to support this.\n\n_\"Planning is in the form of some teams doing waterfall and others doing 'wagile.''\"_\n\n_\"Planning is somewhat heavyweight and a little less than agile.\"_\n\nFor many of our survey takers, there was just overall frustration with the planning process.\n\n_\"Poor planning leads to a lot of doubling back.\"_\n\n## The paradox of code reviews\n\nThere is no question code reviews are critical to DevOps success. Almost 50% of all our respondents conduct them weekly and a significant percentage do them twice a week or even daily. But they’re also a source of frustration when it comes to getting code out the door quickly. Code reviews at some companies can require too many people, or not enough people, or too much \"paperwork.\"\n\n_\"We have a strict code review process and it often takes several days for the reviewer to respond to requests for review.\"_\n\n_\"Code review takes time and every developer has to explain how he achieved what he did.\"_\n\n_\"Code reviews can take a long time due to the lack of reviewers.\"_\n\nCode reviews are cumbersome but 95% of our respondents said they’re either very or moderately valuable for ensuring code quality and security. The trick is to just figure out how to streamline them, and one survey taker offered his organization’s strategy: \"Each merge request is code reviewed by a peer; there is no team code review.\"\n\nOur [2022 Global DevSecOps Survey](/developer-survey/) has the latest insights from over 5,000 DevOps professionals. You can also compare it with [previous year surveys](/developer-survey/previous/)\n",[1115,722,806],{"slug":2180,"featured":6,"template":681},"what-blocks-faster-code-release","content:en-us:blog:what-blocks-faster-code-release.yml","What Blocks Faster Code Release","en-us/blog/what-blocks-faster-code-release.yml","en-us/blog/what-blocks-faster-code-release",{"_path":2186,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2187,"content":2193,"config":2198,"_id":2200,"_type":17,"title":2201,"_source":18,"_file":2202,"_stem":2203,"_extension":21},"/en-us/blog/using-gitlab-web-ide-gitlab-ci-cd",{"title":2188,"description":2189,"ogTitle":2188,"ogDescription":2189,"noIndex":6,"ogImage":2190,"ogUrl":2191,"ogSiteName":667,"ogType":668,"canonicalUrls":2191,"schema":2192},"How to make small changes using GitLab’s Web IDE","A quick three minute demo shows how teams can deliver better apps faster using GitLab CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678812/Blog/Hero%20Images/web-ide-cover.jpg","https://about.gitlab.com/blog/using-gitlab-web-ide-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to make small changes using GitLab’s Web IDE\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-05-28\",\n      }",{"title":2188,"description":2189,"authors":2194,"heroImage":2190,"date":2195,"body":2196,"category":14,"tags":2197},[1483],"2020-05-28","\n\nIt’s not enough to say something is quick and easy. To have a better understanding of some of the benefits of using [GitLab CI/CD](/topics/ci-cd/), it’s much better to _show_ you.\n\nIn a [short video](https://www.youtube.com/watch?v=6207TKNGgJs&feature=emb_logo), [Itzik Gan-Baruch](/company/team/#iganbaruch) technical marketing manager, demonstrates how to submit a code change using GitLab Web IDE. In three minutes, teams can submit a code change and commit it, trigger a CI pipeline to scan for any errors, and ship the updated application to users.\n\n## Getting started with GitLab Web IDE\n\nAll code that gets automatically tested and deployed to production has a human at its source. In GitLab 10.7, we released the [first iteration of our Web Integrated Development Environment (IDE)](/blog/introducing-gitlab-s-integrated-development-environment/) after observing how non-developers struggled with editing multiple files and committing those changes. Since we believe that [everyone can contribute](/company/mission/#mission), building an editor that was integrated with GitLab that made it easier for anyone to contribute seemed like a natural fit. To access the Web IDE, just click the button from any GitLab project.\n\n![Web IDE](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_1.png){: .shadow.medium.center}\n\nThe Web IDE button\n{: .note.text-center}\n\nIn this simple project with a job application, you can use the Web IDE to make a code change and push it to a feature branch. Select the file you would like to change from the menu on the left.\n\n![Selecting a file](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_2.png){: .shadow.medium.center}\n\nSelecting a file from the Wed IDE\n{: .note.text-center}\n\nOnce you’ve modified the text in that file, add a commit message and create a new branch. Click `Commit` to create a merge request.\n\n![Commit](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_3.png){: .shadow.medium.center}\n\nCommit to create a merge request\n{: .note.text-center}\n\nYour commit generates a merge request, and from here you can add an assignee, tie this code change to a specific milestone, add labels, or add any additional information regarding the change.\n\n![Modify merge request](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_4.png){: .shadow.medium.center}\n\nSubmit merge request\n{: .note.text-center}\n\nA new [continuous integration pipeline](/features/continuous-integration/) is triggered automatically. Click on the pipeline to see the stages.\n\n![Pipeline](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_5.png){: .shadow.medium.center}\n\nClick on the pipeline from the merge request\n{: .note.text-center}\n\nIn this project, the pipeline needed zero-configuration because it was generated through GitLab's [Auto DevOps](/direction/delivery/auto_devops/) capability. The pipeline has stages and a few jobs within each stage.\n\n![Auto DevOps pipeline](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_6.png){: .shadow.medium.center}\n\nA CI pipeline automatically configured with GitLab Auto DevOps\n{: .note.text-center}\n\nFirst, it builds a Docker image for the code and pushes it to the container registry. From there, it begins tests and scans jobs that run in parallel to help speed up the pipeline.\n\n![Pipeline jobs](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_7.png){: .shadow.medium.center}\n\nClick on a job within the pipeline stage to get more information\n{: .note.text-center}\n\nBy clicking on a job within the stage, you can see what happens.\n\n![dependency scan](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_8.png){: .shadow.medium.center}\n\nDependency scanning details\n{: .note.text-center}\n\nOnce all tests are completed, all test results will be added to the merge request that was created. The merge request is really the key to using GitLab as a code collaboration and [version control platform](/topics/version-control/). It’s simply a request to merge one branch into another.\n\n![merge requests](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_9.png){: .shadow.medium.center}\n\nMerge requests for this project\n{: .note.text-center}\n\n[Review Apps](/stages-devops-lifecycle/review-apps/) are a way to visualize the changes that were made. Click `View app` once the pipeline has completed to access the staging environment.\n\n![Review apps](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_10.png){: .shadow.medium.center}\n\nSelect `View app` to access a staging environment once a pipeline completes.\n{: .note.text-center}\n\nIn this environment, only changes that were made in the merge request will be displayed. This link can be sent to others so they can view the changes from a web browser.\n\n![staging environment](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_12.png){: .shadow.medium.center}\n\nThe Review App for this project\n{: .note.text-center}\n\nFrom the merge request, you can see the test results, including changes to code quality and the security scans. This scan detected 20 new vulnerabilities. If you’d like more information, just click `Expand` on the right.\n\n![pipeline test results](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_13.png){: .shadow.medium.center}\n\nPipeline test results\n{: .note.text-center}\n\nOnce the results have been expanded, you can click on each one to get more details.\n\n![SAST scan](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_14.png){: .shadow.medium.center}\n\nSAST vulnerabilities detected\n{: .note.text-center}\n\nBy clicking on one of these results, you can see the file that caused the vulnerability as well as the problematic lines of code.\n\n![security report](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_15.png){: .shadow.medium.center}\n\nSecurity report\n{: .note.text-center}\n\nFrom this menu, you can choose to dismiss the vulnerability or create an issue so that someone can fix it. Details from the test will be added to the issue automatically.\n\n![new issue](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_16.png){: .shadow.medium.center}\n\nA new issue created to investigate a vulnerability\n{: .note.text-center}\n\nFrom your original merge request, you can collaborate with others and have them take a look at the proposed changes.\n\n![collaborate on merge request](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_17.png){: .shadow.medium.center}\n\nTag someone in a merge request to have them see your changes\n{: .note.text-center}\n\nOnce you’ve gathered feedback and all pipelines have passed, click the `merge` button to trigger a new pipeline to deploy your application to production\n\n![Web IDE](https://about.gitlab.com/images/blogimages/CI_demo_blog_May_28/CI_demo_18.png){: .shadow.medium.center}\n\nClick `merge` to trigger a deployment pipeline\n{: .note.text-center}\n\nThis workflow shows how anyone can contribute code without using a command line. The Web IDE makes it easy for anyone to make changes without introducing additional risks or quality issues, all from the GitLab interface.\n\nTo see this three-minute demo in real-time, just watch the video below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/6207TKNGgJs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[110,1255,1968],{"slug":2199,"featured":6,"template":681},"using-gitlab-web-ide-gitlab-ci-cd","content:en-us:blog:using-gitlab-web-ide-gitlab-ci-cd.yml","Using Gitlab Web Ide Gitlab Ci Cd","en-us/blog/using-gitlab-web-ide-gitlab-ci-cd.yml","en-us/blog/using-gitlab-web-ide-gitlab-ci-cd",{"_path":2205,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2206,"content":2212,"config":2217,"_id":2219,"_type":17,"title":2220,"_source":18,"_file":2221,"_stem":2222,"_extension":21},"/en-us/blog/solve-devsecops-challenges-with-gitlab-ci-cd",{"title":2207,"description":2208,"ogTitle":2207,"ogDescription":2208,"noIndex":6,"ogImage":2209,"ogUrl":2210,"ogSiteName":667,"ogType":668,"canonicalUrls":2210,"schema":2211},"How GitLab CI helps solve common DevSecOps challenges","How single application continuous integration helps team automate and collaborate.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681305/Blog/Hero%20Images/ci-use-case-web-header.png","https://about.gitlab.com/blog/solve-devsecops-challenges-with-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab CI helps solve common DevSecOps challenges\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-05-12\",\n      }",{"title":2207,"description":2208,"authors":2213,"heroImage":2209,"date":2214,"body":2215,"category":14,"tags":2216},[1483],"2020-05-12","\n\nCollaboration is an important part of [DevSecOps](/solutions/security-compliance/). Effective collaboration requires visibility, not only into the work being done by other members of the team, but also into the processes that help the team produce that work in the first place. It can be hard to gauge bottlenecks, solve problems, fix bugs, or work agilely if everyone is juggling their own set of tools or siloed within their own environments.\n\n\n## DevSecOps challenges\n\nOne of the reasons that we frequently discuss toolchain complexity is that it can hinder development speed in significant ways. [In a survey conducted by Forrester](/resources/whitepaper-forrester-manage-your-toolchain/) of over 250 IT professionals, 45% said they were using three or more tools for software delivery. Of those using three tools or more, **two-thirds were using eleven or more tools per toolchain**. While using multiple tools isn’t a bad thing in itself, it adds layers of complexity to processes that are already pretty complicated.\n\nIntegrated toolchains require regular maintenance. If teams rely on a [plugin environment](/blog/plugin-instability/), there are also dependencies that need to be monitored and updated. For teams using microservices, they may also have to contend with 20 different pipelines, each with hundreds of shell script outputs. Dealing with [brittle pipelines](https://harness.io/2018/09/4-reasons-your-jenkins-pipelines-are-brittle/) is a common challenge, and for those using plugins it can be difficult to assess whether the pipeline itself is broken vs. the actual software artifact or build that’s being tested.\n\nFrom an operations perspective, managing multiple toolchains is time-consuming. When problems or errors arise and need to be sent back to the developer, it becomes difficult to troubleshoot because the code isn’t fresh in their mind (also known as context switching). Instead of focusing on building applications, developers worry about environments. Instead of focusing on infrastructure optimization, operations teams have to put out fires.\n\nDevSecOps teams need to be able to collaborate, and visibility is a key component in helping teams work better together. By simplifying the toolchain, it reduces barriers to communication and gives [DevOps access](/topics/devops/) to the entire software development lifecycle (SDLC). When teams can build, test, and deploy with single sign-on simplicity, they can solve problems and share knowledge all in one place.\n\nGitLab’s [complete DevOps platform](/solutions/devops-platform/), delivered as a single application, offers built-in CI/CD so that teams can test and deploy all from one interface. Instead of logging into multiple tools, everyone has access to the same information.\n\n## Benefits of GitLab CI/CD\n\n1. **Eliminate siloes:** A complicated toolchain isolates teams and tools, creating bottlenecks in the development lifecycle. GitLab brings dev, sec, and ops together in one interface.\n2. **Greater visibility:** With full visibility across the entire SDLC, teams can solve problems faster with fewer roadblocks.\n3. **Increased efficiency:** Instead of managing a brittle plugin environment or maintaining multiple tools, teams can focus on more productive tasks.\n4. **Industry-leading CI/CD:** Teams don't have to sacrifice functionality for convenience. GitLab's CI/CD offers everything teams need for cloud native application development and was [voted a leader in CI by the Forrester Wave](/analysts/forrester-cloudci19/).\n\nTo learn more about single application CI/CD, download our eBook and see how we compare to other CI tools.\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>  \nThe benefits of single application CI/CD eBook - [Read here](/why/use-continuous-integration-to-build-and-test-faster/)!\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",[110,1255],{"slug":2218,"featured":6,"template":681},"solve-devsecops-challenges-with-gitlab-ci-cd","content:en-us:blog:solve-devsecops-challenges-with-gitlab-ci-cd.yml","Solve Devsecops Challenges With Gitlab Ci Cd","en-us/blog/solve-devsecops-challenges-with-gitlab-ci-cd.yml","en-us/blog/solve-devsecops-challenges-with-gitlab-ci-cd",{"_path":2224,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2225,"content":2230,"config":2235,"_id":2237,"_type":17,"title":2238,"_source":18,"_file":2239,"_stem":2240,"_extension":21},"/en-us/blog/working-with-performance-metrics",{"title":2226,"description":2227,"ogTitle":2226,"ogDescription":2227,"noIndex":6,"ogImage":1206,"ogUrl":2228,"ogSiteName":667,"ogType":668,"canonicalUrls":2228,"schema":2229},"How application performance monitoring metrics helps developers","Automatically detect and monitor Kubernetes Clusters and deployed applications from the GitLab interface with application performance metrics (APM).","https://about.gitlab.com/blog/working-with-performance-metrics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How application performance monitoring metrics helps developers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Saumya Upadhyaya\"},{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-05-07\",\n      }",{"title":2226,"description":2227,"authors":2231,"heroImage":1206,"date":2232,"body":2233,"category":14,"tags":2234},[2100,2101],"2020-05-07","\n[Application Performance Metrics](/direction/monitor/platform-insights/), also referred to as GitLab Metrics, is designed for developers who need to understand the impact of the changes they are making on performance, and DevOps engineers/operators who are tasked with keeping the production systems up and running. GitLab Metrics, which is at [viable maturity](/direction/maturity/#monitor), can automatically detect and monitor Kubernetes clusters deployed via GitLab. The GitLab Metrics tool can also monitor all of your custom application metrics so that you can see how your entire system is behaving and performing without leaving the familiar GitLab interface.\n\nGitLab has application performance monitoring tightly and automatically integrated into the DevOps process, which allows you to move seamlessly from development to production with confidence. GitLab Metrics is just one part of the [GitLab Monitoring solution](/direction/monitor/). When the whole suite of GitLab Monitoring tools is used together, we can help you decrease the frequency and severity of production incidents.\n\n## What’s under the hood?\n\nGitLab Metrics is powered by [Prometheus](https://prometheus.io/). Prometheus is quickly becoming the de facto standard for metrics for the cloud native community, because it rises to the top for monitoring Kubernetes and the available integrations cover the major elements of the cloud native ecosystem.\n\n## How to use GitLab Metrics?\n\nGitLab Metrics can be used in two ways.\n\nFirst, you can use Prometheus as a [managed application](https://docs.gitlab.com/ee/update/removals.html) within GitLab. Prometheus can be installed into your GitLab managed Kubernetes cluster with one click.\n\n![System Metrics](https://about.gitlab.com/images/blogimages/blog-metrics-system-metrics.png){: .shadow}\nHow the system metrics dashboard looks to users.\n{: .note.text-center}\n\nWhen integrated with Prometheus and Kubernetes, GitLab Metrics includes the following powerful capabilities:\n* [Default metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#getting-metrics-to-display-on-the-metrics-dashboard) collected from Prometheus, such as memory and core usage for the pod and canary deployment, Knative invocations, NGINX, AWS ELB, HA Proxy metrics, etc.\n* [Custom metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#adding-additional-metrics) can be configured with a promQL query.\n* [Alerts](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics) can be added on the UI directly for each metric.\n* Application deploys works by deploying to the monitored environment and can be [visualized on the metrics chart](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#getting-metrics-to-display-on-the-metrics-dashboard) itself to correlate performance spikes due to deploys.\n* [Custom dashboards](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#defining-custom-dashboards-per-project) can be configured as a YAML file and an existing GitLab default dashboard can be replicated as required.\n\n![Custom Dashboards](https://about.gitlab.com/images/blogimages/blog-metrics-key-services.png){: .shadow}\nUse a YAML file to configure a customized Metrics dashboard.\n{: .note.text-center}\n\nIf you already have an operational Prometheus instance that you would like to integrate with GitLab, you can simply point to the Prometheus server from within GitLab. In this case, performance metrics are retrieved from the external instance of Prometheus, and displayed within the GitLab interface.\n\n## How is GitLab dogfooding our metrics capability?\n\nAt GitLab, [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is one of the main tenets of our [results](https://handbook.gitlab.com/handbook/values/#results) value.\n\nThe [GitLab infrastructure team](/handbook/engineering/infrastructure/) is used as an internal customer, and they provide feedback which feeds directly into how we develop our metrics capabilities. Prometheus and Grafana are two tools the GitLab infrastructure team uses. One of the main reasons the infrastructure team was reluctant to implement GitLab metrics was our previously inadequate graphing capabilities. To encourage our infrastructure team to dogfood metrics, we are focused on filling critical and non-critical gaps in GitLab metrics charts, which initiates a feedback loop for the product. Our goal is to eventually phase out Grafana and work exclusively with Prometheus and GitLab charts to monitor GitLab.com, we will do it on our GitLab way, iteratively, first we'll replace all of our publicly facing [dashboard](https://dashboards.gitlab.com/).\n\n## What's next for GitLab Metrics\n\nGet started by visiting the GitLab Metrics [documentation page](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html) and [directions page](/direction/monitor/platform-insights/). We’d love your help with prioritizing work on the most valuable improvements to the GitLab Metrics solution.\n\nTo report a bug or request a feature or enhancement, follow these steps:\n* Open an issue in the [GitLab project](https://gitlab.com/gitlab-org/gitlab/issues).\n* Describe the feature enhancement and, if possible, include examples.\n* Add these labels to the issue: `devops::monitor`, `Category::Metrics`\n* Tag @dhershkovitch on the issue\n\nCover image by [chuttersnap](https://unsplash.com/photos/gts_Eh4g1lk) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[806,995],{"slug":2236,"featured":6,"template":681},"working-with-performance-metrics","content:en-us:blog:working-with-performance-metrics.yml","Working With Performance Metrics","en-us/blog/working-with-performance-metrics.yml","en-us/blog/working-with-performance-metrics",{"_path":2242,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2243,"content":2249,"config":2255,"_id":2257,"_type":17,"title":2258,"_source":18,"_file":2259,"_stem":2260,"_extension":21},"/en-us/blog/aws-gitlab-serverless-webcast",{"title":2244,"description":2245,"ogTitle":2244,"ogDescription":2245,"noIndex":6,"ogImage":2246,"ogUrl":2247,"ogSiteName":667,"ogType":668,"canonicalUrls":2247,"schema":2248},"How to deploy AWS Lambda applications with ease","Highlights from our serverless webcast with AWS exploring the Serverless Application Model.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/aws-gitlab-serverless-webcast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to deploy AWS Lambda applications with ease\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-04-29\",\n      }",{"title":2244,"description":2245,"authors":2250,"heroImage":2246,"date":2251,"body":2252,"category":14,"tags":2253},[1483],"2020-04-29","\n\nIn the [Cloud Native Computing Foundation (CNCF) 2019 survey](https://www.cncf.io/blog/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/), 41% of respondents use serverless technology. Among those using serverless, 80% use a hosted platform vs. 20% who use installable software. Of the 80% using a hosted platform, the top tool is AWS Lambda (53%).\n\nAs organizations continue to explore the power and scalability of serverless computing, AWS Lambda remains a large part of the conversation. On April 9, AWS and GitLab hosted a serverless webcast to demonstrate how teams can use [GitLab CI/CD](/topics/ci-cd/) and the AWS Serverless Application Model (SAM) to build, test, and deploy Lambda applications. For the serverless webcast, we showed attendees how to:\n\n*   Use and install the AWS SAM CLI\n*   Create a SAM application including a Lambda function and API\n*   Build, test, and deploy the application using GitLab CI/CD\n\nWhether you’re an AWS customer, a serverless newbie, or wanting to explore new ways to utilize GitLab CI/CD, this webcast had something for everyone. We’ve compiled some highlights from the discussion and a link to the on-demand webcast.\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>  \nWatch the webcast with AWS and GitLab to learn all about serverless - [Tune in here](/webcast/aws-gitlab-serverless/)!\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\n## What is the Serverless Application Model (SAM)?\n\nTooling and workflows are the biggest roadblocks to adopting serverless. Organizations love the scalability and automation of serverless but don’t believe that they have the tools to implement it effectively. In this webcast, we showed how teams can seamlessly use SAM with GitLab CI/CD for their serverless application development.\n\n[AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) is an open source framework for building serverless applications on AWS. It can be considered an extension to CloudFormation that makes it easier to define and deploy AWS resources – such as Lambda functions, API Gateway APIs and DynamoDB tables – commonly used in serverless applications.\n\nIn addition to its templating capabilities, SAM also includes a CLI for testing and deployment allows teams to define the resources they need as code. So that includes the serverless functions, but can also include any of the rest of the AWS suite of tools. SAM works by taking all of those things and creates a cloud formation stack from a SAM template. Next it automatically deploys those various functions and other AWS components and gets the IAM configured correctly between all of them so that an application can run not only Lambda functions, but also leverage the rest of the AWS stack to create an entire system and application.\n\n\n## Why is SAM a great tool for enterprise teams?\n\nSenior developer evangelist at GitLab, [Brendan O’Leary](/company/team/#brendan), is a Node.js developer at heart. \"For better or worse,\" he laughs. When putting together the presentation, he noted that SAM offered templates not only in Python but in Node.js as well. \"I think applies directly to the enterprise because those teams are going to be diverse. They're going to have different needs, they're going to choose the language that best fits those needs. It was great to have this starter template that I could start with Node.js 12X to really get started on coding in a comfortable environment for me.\"\n\nThe SAM templates can also be an asset for enterprise teams because they streamline a lot of the backend work. In the project presented during the webcast, we were able to start from a SAM template to orchestrate the IAM permissions we needed instead of coding all of the cloud formation ourselves. For a large or distributed team, this makes SAM a great out-of-the-box tool for serverless applications.\n\n\n## The benefits of going serverless\n\nRam Dileepan, solutions architect at AWS, highlighted this quote from AWS CTO Werner Vogels: No server is easier to manage than no server at all. \"The main goal of modern application development is to automate and abstract as much as possible from the customer. So what we do as an AWS cloud, we abstract a lot of the details from developers so they can actually focus on building applications instead of working with infrastructure.\"\n\nFor teams looking to incorporate serverless, it can provide a number of benefits:\n\n*   Scalable\n*   Pay for what you use\n*   Availability\n\n\n## Serverless and microservices best practices\n\nWhile serverless means that, from the developer perspective, servers are not actively managed, there is still work to do. When you design the application, you have to design how are you going to monitor it and what you are going to monitor. \"Even when you go to serverless, you can actually just follow the standard development best practices,\" says Ram. Here he presented his three serverless/microservices best practices:\n\n*   Treat your infrastructure the way you treat your code\n*   Set up an automated integration and deployment pipeline\n*   Build with monitoring and observability from day one\n\nIn addition to going over the SAM CLI and creating a GitLab CI/CD pipeline, Brendan O’Leary and Ram Dileepan also fielded a variety of questions in the live Q&A. To watch the full webcast and learn more about serverless with GitLab and AWS, click the link below or in the header.\n\n[Watch our serverless webcast Ram Dileepan of AWS and Brendan O'Leary of GitLab 🍿](/webcast/aws-gitlab-serverless/)\n{: .alert .alert-gitlab-purple}\n",[2254,723,110],"webcast",{"slug":2256,"featured":6,"template":681},"aws-gitlab-serverless-webcast","content:en-us:blog:aws-gitlab-serverless-webcast.yml","Aws Gitlab Serverless Webcast","en-us/blog/aws-gitlab-serverless-webcast.yml","en-us/blog/aws-gitlab-serverless-webcast",{"_path":2262,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2263,"content":2269,"config":2274,"_id":2276,"_type":17,"title":2277,"_source":18,"_file":2278,"_stem":2279,"_extension":21},"/en-us/blog/beginner-git-guide",{"title":2264,"description":2265,"ogTitle":2264,"ogDescription":2265,"noIndex":6,"ogImage":2266,"ogUrl":2267,"ogSiteName":667,"ogType":668,"canonicalUrls":2267,"schema":2268},"A guide to Git for beginners","Our senior developer evangelist answers newbie questions about Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681222/Blog/Hero%20Images/git-15th-anniversary-cover.png","https://about.gitlab.com/blog/beginner-git-guide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A guide to Git for beginners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n        \"datePublished\": \"2020-04-13\",\n      }",{"title":2264,"description":2265,"authors":2270,"heroImage":2266,"date":2271,"body":2272,"category":14,"tags":2273},[802],"2020-04-13","\n\n_If you're just learning about software development, or are brand new to open source, it won't be long before you encounter Git, a source code management tool and arguably one of the most successful open source projects ever. We asked senior developer evangelist [Brendan O'Leary](/company/team/#brendan) to fill in the background on Git's history and successes in honor of its 15th anniversary._\n\n## What is source code management?\n\nBefore you start in software engineering it's important to understand the concept of [source code management](/solutions/source-code-management/). In its simplest form software is a bunch of text files and if I'm using those by myself it's not a big deal. But when multiple people use multiple files it gets out of hand and you need some way to manage it all. Humans can't necessarily manage all of that easily: If you're working with files A and C and I'm working with C and D, you need a way to bring all the changes we've made together without overriding anything or causing any conflict. A computer can more easily figure that out, and in a nutshell, that's what source code management is.\n\n## Why the term Git?\n\nThere are several different urban legends about this. Linus Torvalds who wrote it is a pretty gruff person [with some acknowledged sharp edges](https://www.newyorker.com/science/elements/after-years-of-abusive-e-mails-the-creator-of-linux-steps-aside). And so the story suggests he actually named it after himself, as in the British slang word, [“git”](https://www.merriam-webster.com/dictionary/git). That may be apocryphal. Also, it's a three-letter combo, meaning it's short and didn't conflict with any existing Unix commands. Now people say it stands for “Global Information Tracker” or “GD Idiot Truckload of...” if you're mad at it.\n\n## But wait. Who is Linus Torvalds?\n\nLinus Torvalds is a Finnish-American software engineer who developed the [Linux kernel](https://www.howtogeek.com/howto/31632/what-is-the-linux-kernel-and-what-does-it-do/) and then invented Git 15 years ago. Torvalds has been quoted as saying he's more \"famous\" for Linux but that over time, Git will [end up being more important](https://www.techrepublic.com/article/linus-torvalds-git-proved-i-could-be-more-than-a-one-hit-wonder/). Torvalds is also widely seen as the godfather of the open source movement.\n\n## Can you explain the rationale behind the cult following of open source?\n\nTorvalds himself has a cult following and open source has been around for a very long time, long before Git was invented. But open source wasn't widely accepted and in some cases, companies were actively hostile to the concept. Torvalds wanted to create a project everyone could contribute to and Git was born (literally developed by Torvalds over a weekend 15 years ago). Git solved a problem that was common across all types of software development and it not only welcomed contributions from users, it _needed_ contributions to grow. The idea of a practical solution everyone could contribute to created a kind of zeitgeist, and today open source is widely embraced as a result.\n\n## How could I explain Git to my neighbor?\n\nWe tend to talk about Git as a tree but I really don't know if that is the best analogy for it. It's a tree in the sense that it makes branches, but then those branches come back together and that doesn't happen in a tree.\n\nInstead, I'd say Git is like a time machine. The whole history of everything that happened on any branch in alternate timelines is brought back together magically. Nothing is lost or changed and you can look backward and move forward. It's magic.\n\n## What's the most important thing I should know about Git?\n\nThat's easy: You can't break it!\n\nBecause it's a magical time machine you really can't do anything to it that can't be fixed. So I always tell beginners to relax and play around with your copy. No matter how many mistakes you make you can't break it in a way that's not fixable.\n\nHave no fear.\n",[973,852,831],{"slug":2275,"featured":6,"template":681},"beginner-git-guide","content:en-us:blog:beginner-git-guide.yml","Beginner Git Guide","en-us/blog/beginner-git-guide.yml","en-us/blog/beginner-git-guide",{"_path":2281,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2282,"content":2288,"config":2294,"_id":2296,"_type":17,"title":2297,"_source":18,"_file":2298,"_stem":2299,"_extension":21},"/en-us/blog/incident-management-with-gitlab",{"title":2283,"description":2284,"ogTitle":2283,"ogDescription":2284,"noIndex":6,"ogImage":2285,"ogUrl":2286,"ogSiteName":667,"ogType":668,"canonicalUrls":2286,"schema":2287},"Understand incident management with GitLab","GitLab Incident Management helps your response teams focus on the problem and shorten the mean time to repair rather than waste time on the process itself.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681208/Blog/Hero%20Images/incident-management-blog-cover.jpg","https://about.gitlab.com/blog/incident-management-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understand incident management with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Waldner\"}],\n        \"datePublished\": \"2020-04-03\",\n      }",{"title":2283,"description":2284,"authors":2289,"heroImage":2285,"date":2291,"body":2292,"category":14,"tags":2293},[2290],"Sarah Waldner","2020-04-03","\n\nManaging incidents can be stressful! While you’re busy trying to restore service for your customers, you are also likely juggling several competing priorities: digging through multiple tools to understand the problem, communicating with stakeholders, and updating tickets in different systems. Did you know that you can use GitLab to help manage the chaos?\n\nGitLab Incident Management, which recently became a [viable category](/direction/maturity/), aims to decrease the overhead of managing an incident so response teams can spend more time actually resolving problems. We do this by enabling teams to quickly gather the resources in one central, aggregated view. We facilitate communication and enable teams to have dialogs that can be captured all in the same tool they already use to collaborate on development. Ultimately, GitLab Incident Management can help response teams to shorten [MTTR](https://en.wikipedia.org/wiki/Mean_time_to_repair).\n\n## Why Incident Management within GitLab?\n\nGitLab is a complete [DevOps platform](/topics/devops/), delivered as a [single application](/handbook/product/single-application/). As such, we believe there are additional benefits for DevOps users to manage incidents within GitLab.\n\n1. Co-location of code, CI/CD, monitoring tools, and incidents reduces context switching and enables GitLab to correlate what would be disparate events or processes within one single control pane.\n1. The same interface for collaboration for development and incident response streamlines the process. The developers who are on call can use the same interface that they already use every day; this prevents the incident responders from having to use a tool that they are unfamiliar with and thus hampering their ability to respond to the incident.\n\n## GitLab Incident Management Capabilities\n\nAvailable today, GitLab Incident Management includes the following highlighted capabilities:\n* [Incident issues](https://docs.gitlab.com/ee/operations/incident_management/index.html#configuring-incidents) as the one place to capture all data and information related to the incident.\n* [Integration with Slack](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#gitlab-slack-application-free-only) to facilitate intuitive team communication\n* [Link Zoom calls to GitLab issues](https://docs.gitlab.com/ee/operations/incident_management/index.html#zoom-in-issues) to facilitate synchronous communication\n* [Embed GitLab-managed Kubernetes metrics](https://docs.gitlab.com/ee/operations/incident_management/index.html#gitlab-hosted-metrics) directly within the GitLab Incident Issue\n* [Embed generic Grafana metrics](https://docs.gitlab.com/ee/operations/incident_management/index.html#grafana-metrics) directly within the GitLab Incident Issue\n* [The GitLab alerts endpoint](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-endpoint) can accept alerts from any source via a generic webhook receiver\n* Prometheus Recovery alerts can [automatically close issues](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#taking-action-on-incidents) that were created when you receive notification that the alert is resolved.\n\n## How to use GitLab Incident Management\n\nThere are numerous entry points to a potential incident. As an incident responder, once you are aware of an ongoing incident, you can manually create an incident issue by simply tagging the issue with the `incident` label.\n\nAlternatively, you can also configure GitLab to automatically create incidents based on alerts from your monitoring tool. When an alert is posted to the GitLab [Alerts endpoint](https://docs.gitlab.com/ee/operations/incident_management/integrations.html), GitLab can create incidents using an [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html), populating important information useful to the incident response team.\n\nThe incident issue template can be customized using [quick actions](https://docs.gitlab.com/ee/user/project/description_templates.html) to label, mention team members, or assign to specific people automatically. Doing so will help create incidents that have a consistent baseline set of information to help jumpstart the incident response.\n\nAs more details for the ongoing incident emerge, you can directly embed GitLab-managed Kubernetes cluster metrics and application metrics in the incident. You can also embed other Grafana metrics in the incident if this is a critical tool for your team. Sharing up to date information in a central location will help facilitate understanding and enable the incident response team to move forward armed with the latest information. Having embedded charts can also enable more effective retrospectives by having relevant information within the same view.\n\nAs the firefight progresses, the incident response team is encouraged to add timeline events, updates, questions, and answers to the incident. These interactions help create an audit trail and enable shared understanding across the team.\n\nAt the end, an incident can be automatically closed once GitLab receives a recovery alert via the enabled Prometheus recovery alert integration. As the team reconvenes to determine actionable next steps, it  can leverage the completed incident ticket to find improvement areas instead of relying on a separate tool. Furthermore, a team can directly create and link action items to the incident issue in the form of related issues and merge requests to improve the resiliency of the system.\n\n## Next Steps\n\nGet started by visiting the [Incident Management documentation page](https://docs.gitlab.com/ee/operations/incident_management/index.html) and create an issue template. Adopt a new process or amend the existing process for incident management to take advantage of the capabilities within GitLab.\n\nIncident Management is a [focus area](/direction/maturity/#monitor) for GitLab in 2020. We plan to continue iterating and improving this category. We’d love your help in prioritizing work on the most valuable improvements to the incident management solution. Keep an eye on [Incident Management Issues](https://gitlab.com/groups/gitlab-org/-/epics/349) and upvote or share your experiences in relevant issues.\n\nTo report a bug or request a feature or enhancement, follow these steps:\n\n* Open an issue in the [GitLab project](https://gitlab.com/gitlab-org/gitlab/issues).\n* Describe the feature enhancement and, if possible, include examples.\n* Add these labels to the issue: Category:Incident Management, devops::monitor, group::health\n* Tag @abellucci on the issue.\n\nCover image by [Tine Ivanic](https://unsplash.com/photos/u2d0BPZFXOY) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[806,995],{"slug":2295,"featured":6,"template":681},"incident-management-with-gitlab","content:en-us:blog:incident-management-with-gitlab.yml","Incident Management With Gitlab","en-us/blog/incident-management-with-gitlab.yml","en-us/blog/incident-management-with-gitlab",{"_path":2301,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2302,"content":2308,"config":2313,"_id":2315,"_type":17,"title":2316,"_source":18,"_file":2317,"_stem":2318,"_extension":21},"/en-us/blog/low-code-no-code",{"title":2303,"description":2304,"ogTitle":2303,"ogDescription":2304,"noIndex":6,"ogImage":2305,"ogUrl":2306,"ogSiteName":667,"ogType":668,"canonicalUrls":2306,"schema":2307},"The role low code app development tools may play at GitLab","Citizen developers are creating code without being coders. CEO Sid Sijbrandij and senior PMM Parker Ennis explain the impact of low code app development tools on GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681170/Blog/Hero%20Images/lowcodenocode.jpg","https://about.gitlab.com/blog/low-code-no-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The role low code app development tools may play at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-03-26\",\n      }",{"title":2303,"description":2304,"authors":2309,"heroImage":2305,"date":2310,"body":2311,"category":14,"tags":2312},[890],"2020-03-26","\n\nIf software is eating the world and there is a [worldwide shortage of software developers](https://www.icims.com/hiring-insights/for-employers/how-to-win-tech-talent), how can companies stay in the game?\n\nOne answer: The [citizen developer](https://www.forbes.com/sites/johneverhard/2019/01/22/the-pros-and-cons-of-citizen-development/#2376328184fd). Empowered by technology, the so-called citizen developer is able to create code without a formal developer background. Two types of tools allow this: Low code app development tools let a citizen developer build apps using only the most rudimentary of coding skills, while no-code solutions are generally WYSIWYG choices that allow someone to create an app, or part of an app, using pre-assembled pieces of code.\n\nLow code and no code tools have been available for a long time – 4GL, computer-assisted software engineering (CASE) and rapid application development (RAD) tools were all precursors – and according to [IDC](http://www.idc.com), today their use is on the rise. In fact out of 23.4 million developers worldwide in 2019, IDC said 1.76 million of them are low coders, representing 7.5% of the total. There were also 810,000 no-code developers worldwide last year, according to IDC’s Market Perspective: Low-Code and No-Code Developer Census, 2019: Growth Begins in Earnest report.\n\nGiven the growing popularity, it’s not surprising the GitLab development team is taking a hard look at [how to leverage and/or integrate low code functionality](https://gitlab.com/groups/gitlab-org/-/epics/2353#note_263252013) into our tool. Recently CEO [Sid Sijbrandij](/company/team/#sytses) sat down with senior product marketing manager [Parker Ennis](/company/team/#parker_ennis) to talk about the role low code solutions can and should play at Gitlab.\n\n“So what I like about low code is the potential to have more people programming,” Sid tells Parker. And Parker is definitely enthusiastic as well. “What interests me in low code is providing the ease of getting into something like coding,” he explains. “There’s a high barrier of entry when it comes to programming. I found that first hand when I was an undergrad trying to learn Ruby on Rails. It was an intimidating, tough experience but for other people it’s something innate inside them. One of the really cool benefits of low code is you can have people starting to learn how to code without the intimidating factor.”\n\nAlso there’s no question there are simply not enough people with coding skills to fill the demand for software, Parker says, pointing to data from industry analyst and blogger [James Governor](https://redmonk.com/jgovernor/author/jgovernor) who says the world will need around 100 million developers in 10 years. Remember, we’re at just one quarter of that today.\n\nParker is particularly excited about the potential of low code tools to get kids interested in programming at an early age. “How can we educate the next generation in how to solve the problems we are creating today?” he asks. “Low code is a viable option.”\n\nMeanwhile today at GitLab we’re looking at ways we can make it easier to integrate low code tools into our workflow, Parker says. We might go further than that if a viable open source low-code tool arrives on the market.\n\n**Learn more about app develompent tools:**\n\n[Unify your logs and metrics](/blog/unifylogsmetrics/)\n\n[Get the most out of performance testing](/blog/how-were-building-up-performance-testing-of-gitlab/)\n\n[Up your merge train game](/blog/all-aboard-merge-trains/)\n\nCover image by [Anas Alshanti](https://unsplash.com/@otenteko) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[232,676,1255],{"slug":2314,"featured":6,"template":681},"low-code-no-code","content:en-us:blog:low-code-no-code.yml","Low Code No Code","en-us/blog/low-code-no-code.yml","en-us/blog/low-code-no-code",{"_path":2320,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2321,"content":2327,"config":2332,"_id":2334,"_type":17,"title":2335,"_source":18,"_file":2336,"_stem":2337,"_extension":21},"/en-us/blog/how-to-security-as-code",{"title":2322,"description":2323,"ogTitle":2322,"ogDescription":2323,"noIndex":6,"ogImage":2324,"ogUrl":2325,"ogSiteName":667,"ogType":668,"canonicalUrls":2325,"schema":2326},"Why implementing security as code is important for DevSecOps","We created a DevSecOps assessment to help your company level up its DevSecOps capabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663618/Blog/Hero%20Images/how-to-implement-security-as-code.jpg","https://about.gitlab.com/blog/how-to-security-as-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why implementing security as code is important for DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2020-03-12\",\n      }",{"title":2322,"description":2323,"authors":2328,"heroImage":2324,"date":2329,"body":2330,"category":14,"tags":2331},[1985],"2020-03-12","\n## What is security as code?\n\nSecurity as code is a driving force in the future of [application security](/topics/devsecops/).\nAccording to O’Reilly, [security as code is the practice of building security\ninto DevOps tools and workflows](https://www.oreilly.com/library/view/devopssec/9781491971413/ch04.html) by mapping out how changes to code and infrastructure\nare made and finding places to add security checks, tests, and gates without\nintroducing unnecessary costs or delays.\nDevelopers can define infrastructure using a\nprogramming language with infrastructure as code. The same needs to happen to bring security to the speed of DevOps.\n\nAt a basic level, security as code can be achieved by integrating security\npolicies, tests, and scans into the pipeline and code itself. Tests should be\nrun automatically on every code commit, with results made immediately available\nto developers for fixing. By bringing security scans to the code as it’s written,\nteams will save both time and money by streamlining the review process later in\nthe software development lifecycle (SDLC).\n\n## Why is it important?\n\nSecurity as code is key to shifting left and achieving [DevSecOps](/solutions/security-compliance/): It requires\nthat security be defined at the beginning of a project and codified for\nrepeated and consistent use. In this way, it gives developers a self-service\noption for ensuring their code is secure.\n\nPredefined security policies boost efficiency, and also allow for checks on\nautomated processes to prevent any mishaps in the deployment process (like\naccidentally taking down the whole infrastructure because a problem wasn’t\nidentified in a staging environment).\n\n## Six security as code capabilities to prioritize\n\nFrancois Raynaud, founder and managing director of [DevSecCon](https://www.devseccon.com/),\nsaid that [security as code is about making security more transparent and\ngetting security practitioners and developers to speak the same language](https://techbeacon.com/devops/devseccon-security-code-secure-devops-techniques-track).\nIn other words – security teams need to understand how developers work, and use that\ninsight to help developers build the necessary security controls into the SDLC.\nDevelopers can reciprocate by staying open-minded as they adopt new tools and\npractices to boost security during the development process. Here are six best\npractices and capabilities to build into your pipeline:\n\n1. Automate security scans and tests (such as [static analysis](https://docs.gitlab.com/ee/user/application_security/sast/),\n[dynamic analysis](https://docs.gitlab.com/ee/user/application_security/dast/),\nand penetration testing) within your pipeline so that they can be reused across\nall projects and environments.\n1. Build a continuous feedback loop by presenting results to developers, allowing\nthem to remediate issues while coding and learn best practices during the coding\nprocess.\n1. Evaluate and monitor automated security policies by building checks into the\nprocess. Verify that sensitive data and secrets are not inadvertently shared or published.\n1. Automate complex or time-consuming manual tests via custom scripts, with\nhuman sign-off on results if necessary. Validate the accuracy and efficiency of\ntest scripts so that they can be replicated across different projects.\n1. Test new code within a staging environment to allow for thorough security and\nlow-impact failure, and test on every code commit.\n1. Scheduled or continuous monitoring should automatically create logs (or red\nflags) within a review dashboard (such as GitLab’s [Security Dashboard feature](https://docs.gitlab.com/ee/user/application_security/security_dashboard/index.html)).\n\n## Security as code is a best practice for a bigger goal\n\nSecurity as code gives pragmatic meaning to the concept of DevSecOps, but it\nshould not be your end goal. Ultimately, security as code is a means to get more people on board with integrating security throughout your\nSDLC. The idea will feel familiar to developers who\nhave practiced infrastructure as code, and it provides an opportunity for\nsecurity to step into the fray both to better understand software development\nand to help design the policies that will be codified in the process.\n\nAs your team works its way toward becoming a well-oiled DevSecOps machine,\nsecurity as code will inevitably present itself as a smart solution within a complex endeavor.\n\n## GitLab’s DevSecOps methodology assessment\n\nThere’s a lot to cover when standing up a DevSecOps process – so to help you\nmaster the key elements, we created a DevSecOps methodology assessment. Score\nyourself on 20 capabilities, and then use those scores to understand your DevSecOps\nmaturity level, and determine what actions your team can take to bring your DevSecOps to\nthe next level. [Download the assessment here.](https://about.gitlab.com/resources/devsecops-methodology-assessment/)\n\nCover image by [Tim Evans](https://unsplash.com/@tjevans) on [Unsplash](https://unsplash.com/photos/Uf-c4u1usFQ)\n{: .note}\n",[806,894,110,1255],{"slug":2333,"featured":6,"template":681},"how-to-security-as-code","content:en-us:blog:how-to-security-as-code.yml","How To Security As Code","en-us/blog/how-to-security-as-code.yml","en-us/blog/how-to-security-as-code",{"_path":2339,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2340,"content":2346,"config":2351,"_id":2353,"_type":17,"title":2354,"_source":18,"_file":2355,"_stem":2356,"_extension":21},"/en-us/blog/kubernetes-and-multicloud",{"title":2341,"description":2342,"ogTitle":2341,"ogDescription":2342,"noIndex":6,"ogImage":2343,"ogUrl":2344,"ogSiteName":667,"ogType":668,"canonicalUrls":2344,"schema":2345},"How Kubernetes merges with multicloud & how to manage it","Google Cloud's Ian Chakeres and Tim Hockin discuss how Kubernetes reduces cloud noise and makes multicloud possible.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681075/Blog/Hero%20Images/kubernetes-multicloud-blog.jpg","https://about.gitlab.com/blog/kubernetes-and-multicloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Kubernetes merges with multicloud & how to manage it\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-02-05\",\n      }",{"title":2341,"description":2342,"authors":2347,"heroImage":2343,"date":2348,"body":2349,"category":14,"tags":2350},[1483],"2020-02-05","\n\nIn November 2019, we had the opportunity to co-host [MulticloudCon](https://multicloudcon.io/), a zero-day event with our partners at [Upbound](https://upbound.io/). The event featured experts in cloud, Kubernetes, database resources, CI/CD, security, and more to learn how multicloud is evolving and empowering developers and operations experts across the industry.\n\nIn this presentation from MulticloudCon, Google Cloud's [Ian Chakeres](http://www.ianchak.com/) and [Tim Hockin](https://twitter.com/thockin) cover the challenges of using multiple clouds, and how Kubernetes cuts through the cloud noise to provide consistency in workflows. Gartner predicts that by 2021, [over 75% of midsize and large organizations will have adopted a multicloud or hybrid IT strategy.](https://www.gartner.com/en/documents/3895580/predicts-2019-increasing-reliance-on-cloud-computing-tra)\n\nAs organizations continue to amp up their [multicloud](/topics/multicloud/) initiatives, they’ll need ways to manage the complexities and differences between multiple cloud environments. Kubernetes is perfectly built for this task because it creates the right abstractions so teams can utilize multiple clouds on a consistent platform.\n\n\n## Discussion highlights\n\n### The challenges of multiple clouds:\n\n> \"The hard thing about multiple clouds is the noise. There's so much that is different across clouds. To learn them to the _depth_ that you need to be able to develop and debug real applications on these clouds is really, really difficult. Networking capabilities across clouds, across environments, are incredibly different and varied. Storage, auto-scaling, life cycle management, all of these things that have a real, material impact on the way you develop your applications. It can be total chaos for your staff.\" – Tim Hockin, Software Engineer, Kubernetes, Anthos, and GKE\n\n\n### Why Kubernetes is built for multicloud:\n\n> \"Kubernetes is this platform that is [at a] high enough level that it hides most of those variances that we see across all the different clouds. But it's also [at a] low enough level that you can do anything that you need to, for your business and your developers. Kubernetes provides these abstractions that insulate your teams from some of the mess below, hiding that infrastructure complexity that's associated with multiple clouds.\" – Ian Chakeres, Engineering Manager, Anthos and GKE\n\n### How open source continues to improve Kubernetes and multicloud:\n\n> \"Not only can you build the platform for your teams, but there is this entire ecosystem of people who are out there, in Kubernetes, building things that can help you run your business. I went to look at the [CNCF](https://www.cncf.io/) page recently, just to look at all the different projects, and even just the graduated project list now fills your entire screen. There's this entire ecosystem that builds the infrastructure and the applications... they can fill in the gaps if there are any things that your business is running into. So Kubernetes is giving you this leverage as being a platform that actually spans all of those other clouds.\" – Ian Chakeres\n\n## Kubernetes and multicloud\n\nNetworking across environments, clouds, and clusters remains challenging. Organizations don’t want to train DevOps teams on multiple clouds, and even if they did, training teams on the intricacies and fine details for _every single cloud provider_ would be an exercise in futility. Tailoring deployments for each cloud is inefficient and time-consuming. Kubernetes provides the consistency teams need to work with multiple clouds by creating abstractions that bring all deployments into one environment. Even though there are many exciting things happening in open source around Kubernetes and multicloud, not every abstraction is leak-proof.\n\nIn a perfect multicloud, multi-cluster hybrid world, teams are working with multiple providers in a seamless environment that hides the underlying infrastructure. It’s still a little too early for multicloud and hybrid Kubernetes to make that \"perfect\" world a reality, but as multicloud technology continues to evolve, Kubernetes will continue to be at its core.\n\nTo learn more about how the team at Google is investing in Kubernetes and multicloud, watch the full presentation below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/ArQL05VZ18U\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by Francisco Delgado on [Unsplash](https://unsplash.com/s/photos/multi-cloud?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[723,1076],{"slug":2352,"featured":6,"template":681},"kubernetes-and-multicloud","content:en-us:blog:kubernetes-and-multicloud.yml","Kubernetes And Multicloud","en-us/blog/kubernetes-and-multicloud.yml","en-us/blog/kubernetes-and-multicloud",{"_path":2358,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2359,"content":2365,"config":2370,"_id":2372,"_type":17,"title":2373,"_source":18,"_file":2374,"_stem":2375,"_extension":21},"/en-us/blog/ciso-secure-next-gen-software",{"title":2360,"description":2361,"ogTitle":2360,"ogDescription":2361,"noIndex":6,"ogImage":2362,"ogUrl":2363,"ogSiteName":667,"ogType":668,"canonicalUrls":2363,"schema":2364},"Securing next generation software","Scale your security efforts by understanding and integrating with the DevOps workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673038/Blog/Hero%20Images/ciso-secure-next-gen-software.jpg","https://about.gitlab.com/blog/ciso-secure-next-gen-software","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Securing next generation software\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2020-01-27\",\n      }",{"title":2360,"description":2361,"authors":2366,"heroImage":2362,"date":2367,"body":2368,"category":14,"tags":2369},[1463],"2020-01-27","\nNext generation software has changed the way developers work, allowing them to \nproduce code quickly and at scale. This poses new security challenges \nhowever and all too often security is treated as a bolt-on task at the end of the \nprocess. Approaching security in this manner won’t scale to the size and \nvelocity of software development. It’s therefore critical that security \ninnovation finds its way into your development lifecycle. You can be sure \nthat your cyber-adversaries aren’t using hacking methods from 10 years ago – \nso why should you be using security technologies and methods from 10 years ago?\n\nTo tackle these changes, CISOs will need to understand three critical shifts in \nnext-generation software: \n\n1. How software is composed and executed\n1. How software is delivered and managed\n1. How software complies with regulatory requirements\n\nIt’s time to think of security as an outcome from an integrated DevSecOps effort.\n\nIn my recent book ([free to download here](/resources/ebook-ciso-secure-software/)) \nI explain these three shifts in depth to help security professionals understand \nnew application-related attack surfaces and areas of risk, how DevOps processes \nand tools affect their security efforts, and how security teams can adapt and \nscale to unite the iterative development and security workflows. \n\n## Secure software in the age of DevOps\n\nSecuring the software development lifecycle has never been easy, \nand efficiency-boosting development changes have created more challenges for \nsecurity teams to face. To be successful, CISOs and their teams need to be \nable to focus on:\n\n* Basic security hygiene\n* Monitoring, detection, and automated response\n* Building on standardization, policy automation, validation, common controls, \nand continuous improvement\n\n## Think it through\n\nAt the end of my book, you’ll find 10 steps to take as you work toward your \nnext generation security program. Here is a quick preview of a few of the steps:\n\n1. Start by assessing where you are, and decide on a path to move forward. \n1. Align metrics to manage risks, not silos. \n1. Go broad, not deep, when testing software. \n1. Apply continuous security scanning to iterative development.\n1. Apply Zero Trust principles to your applications and their infrastructure.\n\nCover image by [theverticalstory](https://unsplash.com/@theverticalstory) on [Unsplash](https://unsplash.com/photos/LjkEdYv55bA)\n{: .note}\n",[894,806,1255],{"slug":2371,"featured":6,"template":681},"ciso-secure-next-gen-software","content:en-us:blog:ciso-secure-next-gen-software.yml","Ciso Secure Next Gen Software","en-us/blog/ciso-secure-next-gen-software.yml","en-us/blog/ciso-secure-next-gen-software",{"_path":2377,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2378,"content":2384,"config":2390,"_id":2392,"_type":17,"title":2393,"_source":18,"_file":2394,"_stem":2395,"_extension":21},"/en-us/blog/goldman-sachs-partners-with-gitlab-for-next-gen-platform-strategies",{"title":2379,"description":2380,"ogTitle":2379,"ogDescription":2380,"noIndex":6,"ogImage":2381,"ogUrl":2382,"ogSiteName":667,"ogType":668,"canonicalUrls":2382,"schema":2383},"Goldman Sachs partners with GitLab for next-gen platform strategies","Goldman Sachs’ George Grant shares how partnering with GitLab has modernized the development ecosystem.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671845/Blog/Hero%20Images/serverless-ops-blog.jpg","https://about.gitlab.com/blog/goldman-sachs-partners-with-gitlab-for-next-gen-platform-strategies","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Goldman Sachs partners with GitLab for next-gen platform strategies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2020-01-24\",\n      }",{"title":2379,"description":2380,"authors":2385,"heroImage":2381,"date":2387,"body":2388,"category":14,"tags":2389},[2386],"Brein Matturro","2020-01-24","\n\nMost people know Goldman Sachs as the global investment banking giant, but over the past few years the company has branched out to some pretty modern applications that go beyond the standard financial firm. At GitLab Commit Brooklyn 2019, [George Grant](https://www.linkedin.com/in/george-grant-21a9624), who runs the US SDLC engineering team at Goldman Sachs, explained how they’ve partnered with GitLab to help transform not only their development but the company as a whole.\n\n“It means we have to be a lot more nimble than we were in the past,” Grant says. “Now that we’re developing things that run on people’s iPhones, you need to have a different sort of infrastructure to do that.” The SDLC engineering team drives strategies for the development team, including legacy products, but also newer platforms like budgeting applications and the latest Apple credit card. The team is at the center of every business move within the organization. \n\n## Getting past the “dark times”\nGolman Sachs has about 10 [SDLCs running](/solutions/faster-software-delivery/), having grown organically into its own ecosystem over the years for various purposes. “Many of the things that we have at GS were designed in house – its our own workflow, our own tools doing code reviews, surrounding a minimum amount of external tools. Everthing thats involved in it is very tightly coupled with everything else,” Grant says. \n\nThe deployments, the issue tracker, the builds, and the testing are all linked together in order for everything to be controlled in one environment, including regulatory and compliance. This workflow is comfortable and controlled for users, but not ideal. “The problem is, it is sort of simultaneously its greatest strength and greatest weakness because the tightness of the coupling of the components makes it very difficult to replace any of the ones,” Grant says. If any part of the environment needs to be updated or switched out, it impacts all the others.\n\n\n\nThe engineering team started researching a new strategic direction, primarily looking for a modern Git-based solution. The goal was to find a tool that could alleviate developers’ SDLC workload and provide critical strategies for [cloud and Kubernetes](/2017/11/30/containers-kubernetes-basics/), allowing people to move away from the legacy stack. “You actually want to have something that gives you the freedom to innovate, but still have that control level around it.”\n\n## Creating a roadmap with GitLab\nGoldman Sachs chose GitLab as a way to move to the cloud, as an automation tool and to ultimately become the center of the ecosystem. “We didn’t want GitLab to be an island,” Grant says. Within the first two weeks of introducing GitLab, there were over 1600 users, underscoring the push for a new strategic platform.  \n\nGitLab users can be innovative without restrictions. Each user group continues to work in their own world of tooling, but in a highly regulated environment. Reduced cycle times are another benefit, according to Grant. “We have one team that used to only be able to do a release every two weeks. Now they can do one and do another one five minutes later if they want to,” he says. \n\nFor an experienced company, the ability to integrate with legacy tools is important. On top of that, GS is embracing DevOps and QA metrics now that they have end-to-end visibility within the ecosystem. The transparency of GitLab allows Goldman Sachs to have input. “We have new ideas and new ways that we want to use the product to drive it strategically within GS,” Grant says. \n\n## Goldman Sachs and GitLab: Better together\nGoldman Sachs and GitLab have established a partnership. “The proof is in the pudding, as they say, and Goldman Sachs was very, very happy to become an investor in GitLab,” Grant says. As users of the tool, Goldman Sachs found it to be a natural investment opportunity. Bottom line, he says, people are demanding to use it more often. “We believe it is the strategic platform to take us into the future.”\n\nTo learn more about Goldman Sach’s implementation strategies, watch George Grant’s presentation from GitLab Commit Brooklyn 2019.\n \n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Bu3nrxPy1-E\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPhoto by [Tomasz Frankowski](https://unsplash.com/@sunlifter?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1791,110,806,973,268],{"slug":2391,"featured":6,"template":681},"goldman-sachs-partners-with-gitlab-for-next-gen-platform-strategies","content:en-us:blog:goldman-sachs-partners-with-gitlab-for-next-gen-platform-strategies.yml","Goldman Sachs Partners With Gitlab For Next Gen Platform Strategies","en-us/blog/goldman-sachs-partners-with-gitlab-for-next-gen-platform-strategies.yml","en-us/blog/goldman-sachs-partners-with-gitlab-for-next-gen-platform-strategies",{"_path":2397,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2398,"content":2404,"config":2409,"_id":2411,"_type":17,"title":2412,"_source":18,"_file":2413,"_stem":2414,"_extension":21},"/en-us/blog/introducing-resource-groups",{"title":2399,"description":2400,"ogTitle":2399,"ogDescription":2400,"noIndex":6,"ogImage":2401,"ogUrl":2402,"ogSiteName":667,"ogType":668,"canonicalUrls":2402,"schema":2403},"Introducing: Resource groups","How we’re improving deployments by limiting pipeline concurrency.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679102/Blog/Hero%20Images/resource-groups.jpg","https://about.gitlab.com/blog/introducing-resource-groups","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing: Resource groups\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-01-21\",\n      }",{"title":2399,"description":2400,"authors":2405,"heroImage":2401,"date":2406,"body":2407,"category":14,"tags":2408},[1483],"2020-01-21","\nGitLab CI/CD pipelines build, test, deploy your code as part of a single workflow integrated across all [stages of the DevOps lifecycle](/topics/devops/). Ultimately, we want to enable teams to deploy better software faster to their customers, and we do that by continually [iterating](https://handbook.gitlab.com/handbook/values/#iteration) on new and existing features to improve the GitLab experience. \n\nContinuous delivery is all about making sure that [CI-validated code](/features/continuous-integration/) goes through a structured deployment pipeline. While GitLab CI continues to be [a top-rated solution in continuous integration](/analysts/forrester-cloudci19/), we want our continuous delivery capabilities to be just as loved and feedback from the GitLab community plays a big role in how we improve the user experience.\n\nAt GitLab, everything we do is [public by default](https://handbook.gitlab.com/handbook/values/#public-by-default). This allows us to collaborate and share ideas, documentation, examples, and processes with the whole community. The original idea of limiting pipeline concurrency using resource groups was introduced by [@inem](https://gitlab.com/inem) in [a public issue](https://gitlab.com/gitlab-org/gitlab/issues/15536) and the response was certainly enthusiastic.\n\n![Resource groups response](https://about.gitlab.com/images/blogimages/resource-groups-1.png){: .shadow.small.center}\n\nFor some users, they found that running multiple pipelines and/or jobs at the same time in an environment would lead to errors. Some pipelines and/or jobs use unique resources, and concurrent deployments meant that multiple users were affecting the environment with some unintended consequences. \n\n### Example:\n\nLet's say your team is developing a mobile app and you deploy it for testing purposes to a physical smartphone on a Friday afternoon. Maybe you're a startup and only have one or two phones for this purpose. You may need to clear the cache and delete the app before downloading it again so you can start the test clean. But what if in the middle of your test, someone else decides to clear the data on that device? Situations like this would inevitably cause errors, leaving teams with little choice but to coordinate these deployments amongst themselves.\n\nWe’re always working hard to enable [speedy, reliable pipelines](/direction/ops/#speedy-reliable-pipelines). Coming to GitLab 12.7, available tomorrow, we’re introducing the `resource_group` attribute to projects so that only one job can deploy to a specific resource group at any given time. This will improve deployment flows, especially when deploying to physical environments.\n\nIf we go back to the mobile phone example, the phone would be it’s own `resource_group` and will only have one deployment at a time. If another deployment were to try and run on this device, the job will be queued until the first job is finished with the message “waiting for resource.”\n\n![waiting on resource](https://about.gitlab.com/images/blogimages/resource-groups-2.png){: .shadow.medium.center}\n\nTeams can define multiple `resource_group`(s) for their environment in `.gitlab-ci.yml`. Even if running separate pipelines, as long as a `resource_group` is assigned then the jobs will not run concurrently. Tools like [Terraform](https://www.terraform.io/docs/internals/graph.html) similarly help users manage concurrencies by limiting resources.\n\nAs we continue to improve and iterate on our [product vision for continuous delivery](/direction/ops/), we’ll be looking to make future improvements to resource groups and deployment environments. Some of our plans include implicit environment locking, [only allowing forward incremental deployments](https://gitlab.com/gitlab-org/gitlab/issues/25276), and the flexibility to define concurrency values (the default of 1 can’t be configured in this release).\n\nPlease join us in our [public epic](https://gitlab.com/groups/gitlab-org/-/epics/1294) where we discuss continuous delivery and feel free to give feedback or suggestions on ways we can improve deployments. Everyone can contribute.\n\nCover image by [mostafa meraji](https://unsplash.com/@mostafa_meraji?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/turnstile?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[110,1255],{"slug":2410,"featured":6,"template":681},"introducing-resource-groups","content:en-us:blog:introducing-resource-groups.yml","Introducing Resource Groups","en-us/blog/introducing-resource-groups.yml","en-us/blog/introducing-resource-groups",{"_path":2416,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2417,"content":2423,"config":2428,"_id":2430,"_type":17,"title":2431,"_source":18,"_file":2432,"_stem":2433,"_extension":21},"/en-us/blog/ci-cd-the-ticket-to-multicloud",{"title":2418,"description":2419,"ogTitle":2418,"ogDescription":2419,"noIndex":6,"ogImage":2420,"ogUrl":2421,"ogSiteName":667,"ogType":668,"canonicalUrls":2421,"schema":2422},"CI/CD: The ticket to multicloud","Read our expert panel from MulticloudCon on how CI/CD and cloud-agnostic DevOps help organizations go multicloud and increase productivity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679235/Blog/Hero%20Images/cloud-native-predictions-2019.jpg","https://about.gitlab.com/blog/ci-cd-the-ticket-to-multicloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CD: The ticket to multicloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-01-17\",\n      }",{"title":2418,"description":2419,"authors":2424,"heroImage":2420,"date":2425,"body":2426,"category":14,"tags":2427},[1483],"2020-01-17","\n\nIn November 2019, we had the opportunity to co-host [MulticloudCon](https://multicloudcon.io/), a zero-day event with our partners at [Upbound](https://upbound.io/). The event featured experts in cloud, Kubernetes, database resources, CI/CD, security, and more, to learn how [multicloud is evolving](/topics/multicloud/) and empowering developers and operations experts across the industry.\n\nDevOps can play a major role in cloud usage. In this discussion from MulticloudCon, we assembled a panel of experts across the industry to talk about [CI/CD](/features/continuous-integration/) and DevOps in multiple clouds. As [multicloud](/topics/multicloud/) technology continues to evolve, tools can give organizations more control and flexibility on where their workloads live and where they deploy.\n\n![CI/CD MulticloudCon panelists](https://about.gitlab.com/images/blogimages/multicloudcon-panel.png){: .shadow.medium.center}\n\n## Panel highlights\n\n### Why multicloud is important:\n\n> “If we have a single point of failure on a cloud, it is really easy to have some downtime [or] an outage and be like, \"Well, it was my cloud provider's fault.\" But, to our customers, that doesn't matter. You as a company, we're down and that affects them.”\n– Ana Medina, Chaos Engineer at [Gremlin](https://www.gremlin.com/)\n\n> “There are a lot more applications now that are becoming event-driven and are relying on integrations with cloud providers. And if it's more than one, you can't just test on one provider and go well it works across the board. You need to be expanding your test coverage to cover multiple cloud providers.”\n– Denver Williams, DevOps/SRE Consultant at [Vulk Coop](http://vulk.coop/)\n\n\n### The challenges of multicloud:\n\n> “When you're running in multiple clouds, that also introduces problems… I'm talking more specifically about high availability and also fault tolerance and then disaster recovery. These are things people just think about, ‘Oh we need to connect, integrate.’ But at the end of the day, if you're serious about running these applications, you need to also think about those things. And introducing those complexities from the different cloud providers will definitely impact your operations.”\n– Angel Rivera, Developer Advocate at [CircleCI](https://circleci.com/)\n\n\n### How tools impact a multicloud strategy:\n\n> “One thing that helps a lot when you're working on deploys for multicloud is to choose tooling that is going to support multiple clouds off the bat… One thing you really want to avoid, if possible, is ending up with different workflows for different cloud providers. Because then you're testing with different CI/CD pipelines. It's different code and it's inevitably going to behave differently. And then you're going to run into weird bugs.” – Denver Williams\n\n> “When I'm talking to users and GitLab customers that are doing multicloud, they're doing a lot of orchestration and abstraction, and they're having to write an abstraction layer in order to homogenize a logic. A lot of folks have talked about Crossplane today. When I see these types of capabilities and Crossplane in that community emerging, that's pretty exciting because that's what I see a lot of folks writing all the time. That can just be pulled out into a tool and offloaded so that you can focus on the business logic.” – [William Chia](/company/team/#williamchia), Sr. Product Marketing Manager at GitLab\n\nLearn more about GitLab’s Crossplane integration in our [12.5 release](/releases/2019/11/22/gitlab-12-5-released/#crossplane-support-in-gitlab-managed-apps).\n\n\n### CI/CD and multicloud best practices:\n\n> “There's always going to be platform-specific code. Just keep that separate and then your actual YAML logic, keep it agnostic.” – Uma Mukkara, Co-founder and COO at [MayaData](https://mayadata.io/)\n\n> “At Gremlin we help companies avoid downtime. So, we're starting to work with integrations with CI/CD platforms so folks actually start having a stage that they run chaos engineering experiments... You can actually build a lot more testing around past outages that your company has had or maybe some of the large outages that we've seen around in the industry. Building testing around those scenarios, [we’re] making sure the caching layers are able to handle when one of your services goes down... If you're caching layer limits out, the other services that are dependent on it are able to still continue providing a good user experience.” – Ana Medina\n\n> “I always encourage people who are writing pipelines in our platform to do some checks against APIs that they use so that they can just fail their builds right away, instead of wasting money and effort and going to build that. It's going to eventually fail.” – Angel Rivera\n\nMulticloud is made possible through cloud native applications built from containers using services from different cloud providers, and allows for multiple services to be managed in one architecture. CI/CD plays a big role in workflow portability, ensuring workflows stay consistent (no matter where projects are deployed).\n\nWatch the full panel discussion below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/Sx02_fyaGgc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPhoto by [Marc Wieland](https://unsplash.com/photos/zrj-TPjcRLA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/clouds?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n",[110,723,1076],{"slug":2429,"featured":6,"template":681},"ci-cd-the-ticket-to-multicloud","content:en-us:blog:ci-cd-the-ticket-to-multicloud.yml","Ci Cd The Ticket To Multicloud","en-us/blog/ci-cd-the-ticket-to-multicloud.yml","en-us/blog/ci-cd-the-ticket-to-multicloud",{"_path":2435,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2436,"content":2442,"config":2447,"_id":2449,"_type":17,"title":2450,"_source":18,"_file":2451,"_stem":2452,"_extension":21},"/en-us/blog/shifting-from-on-prem-to-cloud",{"title":2437,"description":2438,"ogTitle":2437,"ogDescription":2438,"noIndex":6,"ogImage":2439,"ogUrl":2440,"ogSiteName":667,"ogType":668,"canonicalUrls":2440,"schema":2441},"Shifting from on-prem to cloud","The challenges of being on-prem and what to consider when shifting to public cloud.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679664/Blog/Hero%20Images/on-prem-to-cloud.jpg","https://about.gitlab.com/blog/shifting-from-on-prem-to-cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Shifting from on-prem to cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-01-09\",\n      }",{"title":2437,"description":2438,"authors":2443,"heroImage":2439,"date":2444,"body":2445,"category":14,"tags":2446},[1483],"2020-01-09","\n\nCloud computing and cloud adoption are perennial topics when talking about scalability and growth, but many enterprises still operate a significant portion of their workloads in legacy environments. With so much information on the reduced infrastructure costs and the elasticity of public cloud, why do organizations still do all the work themselves?\n\nIn this discussion with Sr. Product Marketing Manager [William Chia](/company/team/#williamchia), we talk about the challenges traditional IT teams face, the barriers to cloud adoption, and strategies to consider for making the leap.\n\n\n## Why organizations use traditional IT\n\nThe reasons that an organization may want to manage their own infrastructure are myriad and geared toward unique needs and/or limitations within their organization.\n\n\n### Regulatory/Compliance\n\nIn highly-regulated industries such as banking and healthcare, or even government entities, there may be compliance concerns or risks that prevent them from utilizing public cloud. More control means more oversight and more accountability. \"If I need to keep patient data private to comply with HIPAA, for example, if I keep 100% control of my systems and infrastructure I can ensure I comply. If I outsource to cloud services then I have to take different steps to ensure I'm not leaking PII,\" says William. Even though the big cloud providers – namely GCP, AWS, and Azure – have compliance built-in, some organizations may still be hesitant to have them assume those risks.\n\n\n### Protecting sensitive data\n\nIT leaders surveyed in a [Cloud Security Alliance report](https://www.skyhighnetworks.com/cloud-security-blog/5-surprising-truths-from-the-cloud-security-alliances-latest-survey/) expressed that, while they are confident in cloud security capabilities, there are things that can go wrong beyond their control: Inside threats, compromised accounts, and misconfigured security settings up the stack that can all lead to security breaches. According to nearly 68% of the IT leaders surveyed, the ability to enforce corporate security policies is the [number one barrier to moving applications to the cloud](https://www.skyhighnetworks.com/cloud-security-blog/5-surprising-truths-from-the-cloud-security-alliances-latest-survey/). \"The top-level concern basically comes down to control and data privacy,\" says William.\n\n\n### Better costs\n\nFor companies operating at a small scale, cloud computing’s pay-per-use model will almost always be cheaper than managing your own data centers, but for larger-scale organizations that isn’t always the case. \"There's a breaking point… If you run on-prem, it actually could be cheaper than your cloud bill at huge scale, but you’re running so much software you’re basically running your own private cloud at that point,\" says William. For a long-term strategy, organizations have to weigh their CapEx vs OpEx costs, and while [CapEx involves a large upfront expense in whole systems and servers](https://www.10thmagnitude.com/opex-vs-capex-the-real-cloud-computing-cost-advantage/), and the continued cost of maintenance, the computing volume could make this a worthwhile investment.\n\nAnother reason that companies may run their own infrastructure is because that’s how they’ve always done it. While not a very scientific answer, it’s the reality for many companies, especially those that grew before the age of cloud.\n\n\"Once upon a time, if you were a large enterprise and you had to run a lot of software, you had no choice but to manage it all yourself. And so now you have all these servers, you have all of these staff, and you have all of these business processes. You have a great deal of both physical and logical infrastructure and if you want to move to the cloud you have to change all of it. That comes at a very high cost,\" says William.\n\nIn the past, moving small amounts of data was relatively easy. When we start talking about exabytes of data, rather than terabytes of data, the process of migration becomes herculean. According to Jean-Luc Valente, the VP for product management in the cloud platforms and solutions group at Cisco, egressing that kind of data to a public cloud could [cost as much as $30 million dollars](https://www.zdnet.com/article/multicloud-is-here-but-challenges-remain/).\n\n\n\n\n\n## The challenges of on-prem infrastructure\n\nWhile organizations may have specific reasons for running on-premises infrastructure, that decision comes with distinct challenges.\n\n\n### Range of expertise\n\n\"Above a certain level, you are managing all of your infrastructure and you're managing all of your uptime. That's a lot of expertise. You need to become as good at operating a cloud infrastructure as Amazon or Google is, which is why those public clouds are so radically popular. In order to get there requires a lot of resources,\" says William.\n\n\n### Managing software and hardware\n\nIn order to manage uptime and security, operations teams need to perform software maintenance like upgrades and patches in addition to managing physical assets like servers, racks, power supplies, and network switches. At a certain point, an organization is devoting a lot of resources to just keeping things running rather than innovating, so all of these resources are being invested in undifferentiated engineering.\n\n\n### Undifferentiated engineering\n\nIf it is not a core competency for your organization, then it’s undifferentiated engineering. \"If you don't need to manage that on-premises data center or servers for a specific reason, then the cloud is more attractive because that's a high cost,\" says William. \"You're spending a lot of engineering dollars on things that are not differentiating you in the marketplace.\"\n\n\n## Strategies for shifting to cloud\n\n\n### The benefits of \"lift-and-shift\"\n\nIn previous posts, we’ve talked about [legacy and monolithic applications acting as a barrier](/blog/cloud-adoption-roadmap/) for cloud adoption, but there can be some benefit to lifting and shifting those applications to the cloud. While you may not be able to take full advantage of microservices and cloud native application development, shifting those applications to the cloud does provide the benefit of reducing your operational overhead. This can provide an opportunity to learn new competencies.\n\n\"There's a separate set of competencies that you need to acquire to start running in the cloud. You don’t need to learn everything all at once. If you take a monolithic, on-premises app, simply lift-and-shift it into a VM in the cloud, that allows you to start to understand things like cloud billing, and gain some of the competencies of a cloud deployment pattern,\" says William.\n\n\n### Hybrid cloud\n\nMany organizations have opted to use both private and public cloud for a hybrid cloud infrastructure. These hybrid clouds blend the control and security of a private cloud, but also the flexibility and agility of public cloud. During periods of high usage, organizations can leverage public cloud’s pay-per-use model and save themselves from needing additional infrastructure. Organizations can use their private cloud for sensitive data and public cloud for developing and testing new applications. Having a hybrid cloud environment allows teams to manage their on-premises infrastructure and take advantage of public cloud scale.\n\n\nWhile cloud adoption is widespread, many organizations have unique reasons to stay or migrate to an on-premises infrastructure. Cost, control, and risk mitigation continue to be the main drivers of on-prem vs. cloud decisions. Public cloud’s pay-per-use model may not be more cost effective for organizations that operate at higher scale, but a hybrid cloud model can offer organizations the flexibility to use public cloud during periods of high usage without having to invest in additional infrastructure. Both on-prem and cloud require unique and extensive operational competencies, so teams will need leaders that are skilled in these areas when making the switch.\n\n\nCover image by [Matt Howard](https://unsplash.com/@thematthoward?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/journey?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,723],{"slug":2448,"featured":6,"template":681},"shifting-from-on-prem-to-cloud","content:en-us:blog:shifting-from-on-prem-to-cloud.yml","Shifting From On Prem To Cloud","en-us/blog/shifting-from-on-prem-to-cloud.yml","en-us/blog/shifting-from-on-prem-to-cloud",{"_path":2454,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2455,"content":2461,"config":2466,"_id":2468,"_type":17,"title":2469,"_source":18,"_file":2470,"_stem":2471,"_extension":21},"/en-us/blog/cloud-adoption-roadmap",{"title":2456,"description":2457,"ogTitle":2456,"ogDescription":2457,"noIndex":6,"ogImage":2458,"ogUrl":2459,"ogSiteName":667,"ogType":668,"canonicalUrls":2459,"schema":2460},"Cloud strategy and adoption roadmap for businesses","Everything you need to know for transforming your business to the cloud and how to plan out the perfect strategy for it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680891/Blog/Hero%20Images/cloud-adoption-roadmap.jpg","https://about.gitlab.com/blog/cloud-adoption-roadmap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Cloud strategy and adoption roadmap for businesses\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-12-05\",\n      }",{"title":2456,"description":2457,"authors":2462,"heroImage":2458,"date":2463,"body":2464,"category":14,"tags":2465},[1483],"2019-12-05","\n\nOrganizations continue to focus on scalability and growth, and cloud can be a valuable asset in those strategies. When it comes to cloud adoption, not every organization takes the same path – some already work in multiple clouds, some work in industries with strict compliance standards, and some may only be starting their cloud journey.\n\nIt’s estimated that investments in infrastructure to support cloud computing account for [more than a third of all IT spending](https://www.zdnet.com/article/top-cloud-providers-2019-aws-microsoft-azure-google-cloud-ibm-makes-hybrid-move-salesforce-dominates-saas/), and teams want to make sure they’re investing in the right things that benefit them for the long-term. In order to implement the best cloud strategies to meet your needs, a cloud adoption roadmap should have four key steps:\n\n*   Assessment\n*   Planning\n*   Implementation\n*   Optimization\n\n## What is cloud adoption?\n\nCloud adoption aims to mitigate risk, reduce costs, and gain organizational scalability of database capabilities. “The cloud” refers to software and services that live and operate online rather than in an on-premise network of servers or local computers, and it creates incomparable flexibility in daily operations. The cloud provides the necessary speed for an organization to launch new releases quickly, securely, and efficiently.\n\n## Assessing cloud-readiness\n\nCloud adoption does not guarantee scalability and growth on its own. In order for cloud implementation to be successful, organizations have to identify challenges and expertise gaps that affect their cloud-readiness. For example, a lift-and-shift to the cloud isn’t going to produce great results if existing business applications are monolithic and/or outdated. In this scenario, companies will need to commit to an [application modernization](/blog/application-modernization-best-practices/) strategy that makes a cloud investment worthwhile.\n\nFor large enterprises currently working in a traditional IT environment, there may be internal barriers such as lack of organizational buy-in, reluctance to invest the required resources in a multiyear effort, or even regulatory and compliance restraints. On average, [enterprise adoption remains low at around 20%](https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/cloud-adoption-to-accelerate-it-modernization), so it may be beneficial for these organizations to adopt cloud’s [agile](/solutions/agile-delivery/) and automated operating model within their traditional IT, at least in the short-term.\n\nAs part of the assessment stage of your cloud adoption roadmap, ask yourself the following questions:\n\n1. Do we have the internal expertise necessary for a cloud migration or will we need to implement an education or hiring plan?\n2. Do we have industry requirements or compliance regulations to consider?\n3. Will we need to tackle legacy application modernization as well?\n4. What strategies have worked for similar companies in similar industries?\n\n## Creating a plan\n\nAfter identifying challenges and opportunities to cloud adoption, the work on an implementation plan begins. Whether it’s a cloud transformation or just migrating from one cloud to another, it’s important to create actionable steps and have the right leadership in place to guide the process.\n\nKeeping your assessment in mind, your organization will need to decide which clouds and cloud models work best for your needs and business goals. You’ll need to evaluate public, private, or hybrid clouds, in addition to SaaS, IaaS and PaaS cloud models, to determine which combination fits within your limitations. Having leaders with expertise in these areas of cloud computing, rather than relying on information from the cloud service providers themselves, will ensure that decisions are unbiased with your unique needs in mind.\n\n![cloud models](https://about.gitlab.com/images/blogimages/cloud_models.png){: .shadow.medium.center}\n\nBut what if you want to use multiple cloud providers? This is where a [multicloud](/topics/multicloud/) approach can be beneficial.\n\n### What is multicloud?\n\nMulticloud describes [how enterprises use multiple cloud providers to meet different technical or business requirements](https://www.zdnet.com/article/multicloud-everything-you-need-to-know-about-the-biggest-trend-in-cloud-computing/). At its core, multicloud is made possible through cloud-native applications built from containers using services and allows for multiple services to be managed in one architecture. Research indicates [85% of enterprises currently operate in multiple clouds](https://www.ibm.com/blogs/cloud-computing/2018/10/19/survey-multicloud-management-tools/).\n\n\n\nDuring the planning phase of your cloud roadmap, consider the following:\n\n1. Do we have internal expertise to make sure we’re making the right decisions?\n2. Have we evaluated the different cloud models?\n3. Would a multicloud approach be a good fit?\n\n## Putting plans into action\n\nThe implementation phase usually requires multiple steps and thrives when teams are able to communicate and collaborate with each other. As plans change (and they inevitably will), high visibility ensures teams can adapt.\n\nIn our recent migration from Azure to GCP, we documented our progress publicly and leaned on three of our [core values](https://handbook.gitlab.com/handbook/values/): efficiency, iteration, and transparency. We believe in taking small steps and looking for the most [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions) because that allows us to get feedback quickly and reduce cycle times. Whether migrating to the cloud for the first time, or just moving from one cloud to another, things rarely ever go smoothly. By practicing iteration, we were able to course correct and come up with the right solutions quickly. Learn how we put our values into action and watch our presentation at Google Cloud Next ‘19.\n\n[GitLab’s journey from Azure to GCP](/blog/gitlab-journey-from-azure-to-gcp/)\n{: .alert .alert-gitlab-purple .text-center}\n\nWhen implementing cloud strategies, expect your approach to DevOps to change as well.\n\n[DevOps](/topics/devops/) is all about developers and operations working together and using the cloud as a common language, and [cloud native app development](/topics/cloud-native/) will require a shift to a DevOps operating structure. Once you’ve decided on the cloud service and deployment models in your adoption roadmap, you’ll also need to evaluate which DevOps tools support your cloud initiatives. [Developer tools have a high capacity for driving cloud usage](/blog/gitlab-ci-cd-is-for-multi-cloud/) because once you have your application code hosted, the natural next step is finding a place to deploy it. For example, if you decided during the planning phase to adopt multicloud, having cloud-agnostic tools will play a big role in the success of that strategy.\n\nDuring the implementation phase of your cloud roadmap, consider the following:\n\n1. Take small steps and practice iteration so you can course correct effectively.\n2. Make sure teams have visibility into the cloud process and can collaborate as things progress.\n3. Ensure your DevOps structure will be able to support your cloud and cloud native application development initiatives.\n4. Evaluate developer tools and consider if cloud-agnostic tools would allow more flexibility with multiple clouds.\n\n## Cloud optimization and beyond\n\nWhile there will inevitably be a point when cloud models and DevOps tools have been implemented, a cloud adoption roadmap is really a never-ending journey for continuous improvement. By the time a cloud adoption timeline has been completed, there will be new technologies and new paths for cloud optimization already on the horizon. A solution you implemented may need to be deprecated in favor of something that works a little better. A valuable part of iteration is making decisions and acting quickly, and that is a process that never ends.\n\nIn [Cloud Powers the New Platform Economy](https://www.forrester.com/report/Cloud+Powers+The+New+Platform+Economy/-/E-RES120506), Forrester explains that you must automate, integrate, and orchestrate all the moving parts of your cloud to keep up with the pace of innovation the cloud economy demands. As you continue to improve your cloud ecosystems, consider the following:\n\n1. Are we keeping up with the pace of innovation and how can we improve?\n2. Are we investing in next-generation skills and providing continuing education opportunities?\n3. Are we evaluating new technologies?\n4. Are we managing our cloud effectively?\n\n\nCover image by [Matt Howard](https://unsplash.com/@thematthoward?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/journey?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[806,723],{"slug":2467,"featured":6,"template":681},"cloud-adoption-roadmap","content:en-us:blog:cloud-adoption-roadmap.yml","Cloud Adoption Roadmap","en-us/blog/cloud-adoption-roadmap.yml","en-us/blog/cloud-adoption-roadmap",{"_path":2473,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2474,"content":2480,"config":2485,"_id":2487,"_type":17,"title":2488,"_source":18,"_file":2489,"_stem":2490,"_extension":21},"/en-us/blog/migrating-from-jenkins",{"title":2475,"description":2476,"ogTitle":2475,"ogDescription":2476,"noIndex":6,"ogImage":2477,"ogUrl":2478,"ogSiteName":667,"ogType":668,"canonicalUrls":2478,"schema":2479},"Migrating from Jenkins","Best practices for making the switch to GitLab CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679081/Blog/Hero%20Images/jenkins-migration.jpg","https://about.gitlab.com/blog/migrating-from-jenkins","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrating from Jenkins\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-11-26\",\n      }",{"title":2475,"description":2476,"authors":2481,"heroImage":2477,"date":2482,"body":2483,"category":14,"tags":2484},[1483],"2019-11-26","\nMigrations feel daunting, which is one of the reasons teams put them off as long as possible. Even when tools are brittle or not working as they should, it’s the fear of the unknown that keeps us from making the plunge. Teams might have found workarounds to solve common problems but those only work... until they don’t work. If you know that you need to make a tool change or migration, it’s much better to do it early rather than during a crisis.\n\nMigrations don’t have to be scary. If you’re tired of brittle builds and endless plugin maintenance, migrating your CI/CD doesn’t have to be a headache. Several teams have [made the switch from Jenkins CI to GitLab CI/CD](/blog/5-teams-that-made-the-switch-to-gitlab-ci-cd/), and there are resources available to ease the transition.\n\n## From Jenkins to GitLab using Docker\n\nThe team at [Linagora](/blog/docker-my-precious/) loved that GitLab includes Git repository management, issue tracking, [code review](/stages-devops-lifecycle/code-review-workflow/), an IDE, activity streams, wikis, and built-in CI/CD to test, build, and deploy code. In order to take advantage of these all-in-one features, they needed to find a way to switch over from Jenkins CI. Luckily, GitLab’s Docker support and [documentation](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html) allowed them to utilize custom Docker images, spin up services as part of testing, build new Docker images, and run on Kubernetes.\n\n### Running Jenkinsfiles in GitLab CI/CD\n\nOne short-term solution teams can use when migrating from Jenkins to GitLab CI/CD is [using Docker to run a Jenkinsfile in GitLab CI/CD](https://lackastack.gitlab.io/website/posts/gitlabci-jenkinsfile/) while the syntax is being updated. While this doesn’t address the endless [plugin dependencies](/blog/plugin-instability/), it’s a stop-gap measure that can get your team working in GitLab until the migration is complete.\n\n## Using Auto DevOps\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/index.html) can potentially be used to build, test, and deploy your applications with little to no configuration needed at all. One of the more time-consuming tasks during a Jenkins migration can be converting the pipelines from Groovy to YAML, but Auto DevOps provides predefined CI/CD configurations – just push your code and Auto DevOps can build a default pipeline. Auto DevOps offers more features including security testing, performance testing, and code quality testing. If you need [advanced customizations](https://docs.gitlab.com/ee/topics/autodevops/index.html#customizing), you can modify the templates without having to start over on a completely different platform.\n\nGitLab senior solutions manager [Brendan O’Leary](/company/team/#brendan) provided a brief overview of how to convert a Jenkins pipeline built with Maven into a GitLab CI/CD pipeline using Auto DevOps.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/RlEVGOpYF5Y\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Advice from teams that made the switch\n\nAt our [GitLab Commit](/events/commit/) event in London, the team at adSoul, a Germany-based marketing automation company, discussed [their own transition from Jenkins to GitLab](/blog/adsoul-devops-transition-to-gitlab-ci/). They offered insight into their migration process, but for others considering GitLab CI/CD, here are some best practices:\n\n### Start small\n\nIn the spirit of iteration, it’s better to make incremental changes than try to tackle everything all at once. Even if it’s just small projects, or just running a Jenkinsfile in the meantime, be patient and aim for steady progress\n\n### Utilize tools effectively\n\nWith Docker and Auto DevOps, you have the tools available to ease the transition so you’re not reinventing the wheel.\n\n### Communicate clearly\n\nKeep teams informed of the process and communicate any changes. This can also apply to the naming of your new pipelines. Aim for clear job names, style your config for a better overview, and write comments for variables and hard-to-understand code.\n\nFor more information, check out our [migrating from Jenkins documentation](https://docs.gitlab.com/ee/ci/migration/jenkins.html).\n\nCover image by [Aryan Singh](https://unsplash.com/@wuzclicks?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@wuzclicks?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[110,806],{"slug":2486,"featured":6,"template":681},"migrating-from-jenkins","content:en-us:blog:migrating-from-jenkins.yml","Migrating From Jenkins","en-us/blog/migrating-from-jenkins.yml","en-us/blog/migrating-from-jenkins",{"_path":2492,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2493,"content":2499,"config":2504,"_id":2506,"_type":17,"title":2507,"_source":18,"_file":2508,"_stem":2509,"_extension":21},"/en-us/blog/multi-cloud-security",{"title":2494,"description":2495,"ogTitle":2494,"ogDescription":2495,"noIndex":6,"ogImage":2496,"ogUrl":2497,"ogSiteName":667,"ogType":668,"canonicalUrls":2497,"schema":2498},"A brief guide to multicloud security","Five challenges and seven best practices to consider for your multicloud strategy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679136/Blog/Hero%20Images/multi-cloud-security.jpg","https://about.gitlab.com/blog/multi-cloud-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A brief guide to multicloud security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-11-21\",\n      }",{"title":2494,"description":2495,"authors":2500,"heroImage":2496,"date":2501,"body":2502,"category":14,"tags":2503},[1985],"2019-11-21","\nMany agree that multicloud is worth the risk.\n\nThe multicloud trend has taken hold in recent years, with [RightScale finding\nthat 84% of enterprises run a multicloud strategy](https://www.flexera.com/blog/cloud/2019/02/cloud-computing-trends-2019-state-of-the-cloud-survey/). With multicloud,\norganizations deploy applications across two or more cloud platforms, like\nAWS, Azure, or Google Cloud.\n\nIncreased flexibility is one of the biggest appeals of a [multicloud strategy](/topics/multicloud/).\nCompanies avoid vendor lock-in by deploying workloads to different cloud platforms\nbased on cost and application needs. Hyperscale cloud vendors have data centers\nacross the globe, so organizations are able to control their cloud expenditures\nby scheduling workloads based on location and local time. Multicloud also\nprotects business operations by reducing down time, and improving resilience in\nthe event of an outage or workload-disruptive breach (like a DDoS attack).\n\nHowever, multicloud still has drawbacks that require careful consideration.\nThe increased complexity of a multicloud environment exponentially increases\nan organization’s attack surface and level of risk. Most of these risks can be\nmitigated with a thorough assessment and strategy addressing security needs –\nand as [a study from IDG and IBM has found](https://www.ciosummits.com/Online_Assets_IBM_Whitepaper_-_Multi-cloud_Organizations_Confront_IT_Security_Challenges.pdf),\n70% of survey respondents agreed that the benefits of multicloud outweigh the risks.\n\nThat being said, there’s a lot to consider. In this blog, we’ll run through\nsome of the top security challenges of multicloud, and dig into the strategies\nto conquer them. If you're short on time, feel free to skip down to the best\npractices section.\n\n### Key security challenges and how to manage them\n\n#### Access and permissioning\n\nMulticloud adds complexity to your identity and access management efforts.\nEmployees need access to multiple cloud services as part of their daily work,\nand will access your data from a multitude of locations and devices. We\nrecommend you take a Zero Trust approach here: Allow access on an as-needed\nbasis, and no more. Data classification levels can help you streamline access\ndeterminations across different clouds, but the key idea is that limited access\nwill both protect your most mission critical and sensitive information, and\nallow you a clear view of when (and by whom) that information is accessed.\n\n#### Staying up to date\n\nWhile this is a security concern for any cloud use, upgrades and patching in\nmulticloud are more challenging because the vulnerabilities and mitigations\nfrom each cloud service provider are different. Multicloud complexity also\nmakes it difficult to keep track of vulnerabilities as applications communicate\nacross multiple clouds. [Mike Bursell from RedHat\ncalls this need “workload freshness”](https://enterprisersproject.com/article/2019/10/multi-cloud-security-issues-watch) – and suggests that this might require you\nto upgrade or patch in place, restart the workload with the latest image, or\ncheck and reload recent dependencies, in order to maintain the most recent\nversions of any dependent libraries, middleware, or executables.\n\n#### A disjointed view of security\n\nMost cloud vendors offer native tools to help you manage security within their\ncloud platform, and most of those tools can’t be applied to other vendors. This\ndisjointed approach to monitoring makes it difficult to gain a thorough\nunderstanding of all the vulnerabilities present in your infrastructure.\n\nInstead of making piecemeal security sense, adopt a multicloud management tool\nthat serves as a single pane of glass into all the happenings across all of your\ncloud platforms. Bursell notes that any monitoring tool needs to be fully aware\nof the scope of your deployment. It’s also important to have regular, if not\nreal-time, updates to your data view so that you’re aware of unusual changes or\nactivities and can address attacks as they come in. A centralized tool is also\nvaluable for conducting forensic analysis of your systems in the event of a\nlate-discovered breach.\n\n#### Control plane complexity\n\nRedHat’s Bursell defines the control plane as any communication which controls\nyour applications or how they are run. In addition to securing communications\nbetween and within applications, all scheduling, monitoring, and routing\ncommunications should also be encrypted. It’s critical to secure the\nadministration, logging, and audit functionality of your applications\n(lest you want to give hackers the opportunity to take down your entire\ninfrastructure). [David Locke of World Wide Technology writes\nthat security functionality and enforcement needs to be uniform within all of\nyour cloud environments](https://www.datacenterdynamics.com/opinions/security-challenges-multicloud-evolution/), allowing those functions to communicate and coordinate\nbetween themselves and support security automation.\n\n#### Application hardening\n\nWhen hardening your infrastructure, Bursell recommends knowing what APIs are\nexposed, understanding what controls you have on them, and planning what\nmitigations you can apply if they come under attack. [Tripwire notes that\nany software that your organization develops or acquires](https://www.tripwire.com/state-of-security/security-data-protection/cloud/multi-cloud-security-best-practices-guide/) from a third party must\nbe patched and security hardened by your organization.\n\n### Best practices\n\nNeed a TL;DR? We’ve got you covered:\n\n**Key security capabilities and strategies:** Multi-factor authentication,\ncloud workload security, security analytics, encryption, identity and access\nmanagement, cloud security gateways, microsegmentation, threat modeling,\nthreat intelligence, and endpoint detection and response.\n\n**Keep things consistent:** Develop a set of security policies and procedures\nto enforce on all of your clouds (and any on-prem software too, for that matter).\nWhile there will almost always be some kind of incompatibility, a benchmark or\nstandardized security policy will reduce the risk of oversights.\n\n**Cloud agnostic software:** Use security tools that can easily integrate with\nany cloud service, and that can scale with increased apps and workloads.\n\n**Go beyond your CSP’s tools:** Your cloud providers have tools to keep their\nofferings safe, but protection of the data itself falls to you. Some vendors\nmay be able to advise which capabilities you need within their infrastructure\nto keep your data safe.\n\n**Confidential computing:** Data protection usually focuses on data at rest and\nin transit, but what about data in use? Protect data as it is being processed,\nand always know _where_ the data is being used. Confidential computing will\nallow encrypted data to be processed in memory without exposing it to the rest\nof the system. This is a relatively new area, so consider keeping tabs on\nthe [Confidential Computing Consortium](https://confidentialcomputing.io/) to\nstay in the loop.\n\n**Anticipate unforeseen changes:** Planning for the unknown seems like an\noxymoron – but in tech, it’s not. Things change constantly, and often in ways\nwe don’t predict. Make sure your systems and environments can adapt to whatever\nthe market throws at you.\n\n**Stay informed of new computing trends:** For instance, [Nick Ismail from\nInformation Age highlights that serverless computing adoption is growing](https://www.information-age.com/business-multicloud-strategy-123471227/) as it allows cloud\ninstances to be scaled and patched instantly, and machine learning will be able\nto help servers identify patterns of malicious behavior and respond faster than\nhuman administrators can respond.\n\n## Looking ahead\n\nJust like every market, cloud will continue to change as vendors make new\nalliances and focus on new capabilities. In 2020, [Forrester predicts](https://go.forrester.com/blogs/predictions-2020-cloud/)\nthat hyperscale global public cloud leaders will form more alliances, while\ncloud management vendors will shift their focus to security – after a\nhigh-visibility data breach. Take steps to ensure that that breach isn’t yours\nby assessing the current and future state of your cloud strategy, and infusing\nsecurity into everything you do.\n\nCover image by [Michael Weidner](https://unsplash.com/@michaelbweidner) on [Unsplash](https://unsplash.com/photos/h-rP5KSC2W0).\n{: .note}\n",[894,1989,723],{"slug":2505,"featured":6,"template":681},"multi-cloud-security","content:en-us:blog:multi-cloud-security.yml","Multi Cloud Security","en-us/blog/multi-cloud-security.yml","en-us/blog/multi-cloud-security",{"_path":2511,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2512,"content":2518,"config":2523,"_id":2525,"_type":17,"title":2526,"_source":18,"_file":2527,"_stem":2528,"_extension":21},"/en-us/blog/defend-cicd-security",{"title":2513,"description":2514,"ogTitle":2513,"ogDescription":2514,"noIndex":6,"ogImage":2515,"ogUrl":2516,"ogSiteName":667,"ogType":668,"canonicalUrls":2516,"schema":2517},"Defending the CI/CD pipeline","Speed to launch often comes at the cost of security – but it doesn’t have to. Here are four ways to achieve both by using a CI/CD pipeline","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678499/Blog/Hero%20Images/defend-cicd-security.jpg","https://about.gitlab.com/blog/defend-cicd-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Defending the CI/CD pipeline\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-11-19\",\n      }",{"title":2513,"description":2514,"authors":2519,"heroImage":2515,"date":2520,"body":2521,"category":14,"tags":2522},[1985],"2019-11-19","\n[CI/CD](/topics/ci-cd/) is a way to release software as quickly as possible, which, unfortunately, often comes at the expense of security. [Synopsys and \n451 Research found](https://www.synopsys.com/blogs/software-security/security-challenges-cicd-workflows/) \nthe most significant [application security](/topics/devsecops/) challenges in CI/CD workflows \ninclude a lack of automated, integrated security testing tools, inconsistent \nmethods, slowed workflows, and too many false positives.\n\nThere’s also the challenge of securing the pipeline itself. Traditional and \nmanual security practices can’t scale to the level of CI/CD – the resulting delivery pipelines expand a company’s attack surface by a significant measure. The pipeline represents an end-to-end lifecycle for your software which makes it a \nprime target for hackers. It's clear [CI/CD security](/solutions/security-compliance/) can’t be an afterthought. DevOps teams \nmust bring security issues to the forefront of their considerations throughout the SDLC. \n\n## Security risks in enterprise CI/CD\n\nCI/CD significantly broadens your attack surface with a lengthy list of \ncomponents – repositories, servers, containers, and for those who don’t use \nGitLab, a wide array of tools. A large number of moving pieces presents a \ntempting ROI for hackers – one compromised segment of the ecosystem could open \nup the entire infrastructure for exploitation. [As tech journalist Twain Taylor \nexplains](https://thenewstack.io/the-biggest-security-risks-lurking-in-your-ci-cd-pipeline/), \nsecuring the CI/CD pipeline is not a straightforward process. Teams need to study the \npipeline, understand what information the pipeline ingests, uncover any major \nvulnerabilities and find ways to eliminate those risks.\n\nAlso, tools that lack transparency, require frequent switching \nbetween platforms, and inhibit the overall workflow are less likely to be \nadopted – and more likely to be worked around. Workarounds can create friction in the pipeline which can mean inconsistent \ntesting and remediation, all of which can allow more vulnerabilities to make their way \nthrough to production and launch.\n\n## Defending against CI/CD pipeline risks\n\nSecure CI/CD can be achieved through [DevSecOps](/topics/devsecops/) but you’ll need a mature CI/CD solution to get you there. In addition to the \nstability of the solution, your lifecycle ecosystem must be well-maintained and \neasily monitored for suspicious activity. Four of the most important aspects of \na secure CI/CD pipeline are automation, access management, positive user \nexperience, and transparency.\n\n### Automation\n\nAutomation, at the very least, should allow you to bring your security \npractices (especially [testing](/stages-devops-lifecycle/application-security-testing/)) \nup to the speed and scale of CI/CD. The value of automation magnifies when \nprocesses are standardized across teams and organizations. By introducing \nrepeatability to your projects, you’re also creating expected functionality and operations within your pipeline. When there are behaviors \nor activities that don’t align to the expected, a red flag will be triggered alerting developers to potential threats.\n\n### Access management\n\nAccess rights should be considered for both human-to-tool and tool-to-tool \ninteractions. [Tripwire recommends](https://www.tripwire.com/state-of-security/devops/security-ci-cd-pipeline-flowing/) \nrequiring authentication for anyone to push changes to the pipeline, \nimplementing login tracking, and confirming that builds reside on secure \nservers. \n\nCommunication between tools and components should be carefully managed \nto ensure that access is only granted on an as-needed basis. The New Stack's Twain also notes it’s important to consider what secrets are contained in pipeline scripts. He recommends removing any keys, credentials, and secrets from scripts and \nprotecting them with trusted secrets managers. He also suggests implementing \naccess control across your entire toolchain to revoke anything anonymous or shared, and to regularly audit the controls across the \necosystem. \n\n### User experience\n\nSeamless integration between tools will make a night-and-day difference in \nsecuring your CI/CD pipeline (alternatively, you could also use [a single tool \nfor the entire lifecycle]/handbook/product/single-application/)). \nEven though security is gaining traction in the minds of non-security \nprofessionals, it still remains a challenge for many development teams. Provide \ndevelopers with tools and practices that are standard across the organization, \nand reduce friction between tools as much as possible. \n\nWith lower barriers to \nadoption, your team will be less likely to create workarounds that could \njeopardize your business or customers. Providing users with immediate \nfeedback on the security of their code will enable them to remediate on the \nspot and serve an educational purpose, showing developers what to watch out \nfor when writing code. \n\n### Transparency\n\nIt's vital to have a view into what happens throughout the CI/CD pipeline. Maintain a single source of truth that logs every change – \nas well as its origin – and include functionality that allows sign-off for any \nhigh-stakes updates. Transparency also builds accountability among team members, \nreenforcing the idea that everyone is responsible for security. Lastly, \ntransparency is crucial to your team communication strategy. Methodologies and \nknowledge should be communicated openly and thoroughly, so that everyone on the \nteam understands how to apply best practices and what the intended outcomes are.\n\n## Speed and security: No longer a paradox\n\nEach of the above steps will help your security efforts shift left in the \nSDLC. Moving it all earlier in the process will enable you to release secure, quality software at the \nspeed of the business. This can only happen if there is true collaboration between development, operations, \nand security. Set policies and standard practices, understand respective \ngoals, and foster a culture of responsibility for the software as a \nwhole – and not just one facet of its creation or performance.\n\n## The security benefits of a single CI/CD tool for the entire lifecycle\n\nIt’s extremely important to use established tools that have been thoroughly \nvetted by both your internal teams and the market at large. That being said, \nfinding the best-in-class tools for every phase of the lifecycle and then \nsuccessfully (and securely) stringing them together can be a nightmare and result in untold technical debt. A single CI/CD tool relieves much of \nthat burden, by eliminating unnecessary platform switching and enabling high \ntransparency throughout the pipeline. With GitLab in particular, security \nchecks are embedded within the development workflow, which both reduces \nfriction for developers and provides a single source of truth for the entire \npipeline.\n\nRegardless of your tool (or tools) of choice, it’s critical that you and your \nteam prioritize security in all aspects of work.\n\nCover image by [Boban Simonovski](https://unsplash.com/@3031n) on [Unsplash](https://unsplash.com/photos/akQ06aB6MfM)\n{: .note}\n",[110,806,894],{"slug":2524,"featured":6,"template":681},"defend-cicd-security","content:en-us:blog:defend-cicd-security.yml","Defend Cicd Security","en-us/blog/defend-cicd-security.yml","en-us/blog/defend-cicd-security",{"_path":2530,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2531,"content":2537,"config":2542,"_id":2544,"_type":17,"title":2545,"_source":18,"_file":2546,"_stem":2547,"_extension":21},"/en-us/blog/gitlab-ci-cd-is-for-multi-cloud",{"title":2532,"description":2533,"ogTitle":2532,"ogDescription":2533,"noIndex":6,"ogImage":2534,"ogUrl":2535,"ogSiteName":667,"ogType":668,"canonicalUrls":2535,"schema":2536},"GitLab CI/CD is for multi-cloud","Can cloud providers (and their tools) ever be cloud agnostic? We discuss GitHub Actions and GitLab CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678401/Blog/Hero%20Images/gitlab-for-multicloud.jpg","https://about.gitlab.com/blog/gitlab-ci-cd-is-for-multi-cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab CI/CD is for multi-cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-11-06\",\n      }",{"title":2532,"description":2533,"authors":2538,"heroImage":2534,"date":2539,"body":2540,"category":14,"tags":2541},[1483],"2019-11-06","\nAs organizations continue to go all-in on cloud-first strategies, optimizing their cloud architectures is becoming a top priority. It’s estimated that investments in infrastructure to support cloud computing account for [more than a third of all IT spending](https://www.zdnet.com/article/top-cloud-providers-2019-aws-microsoft-azure-google-cloud-ibm-makes-hybrid-move-salesforce-dominates-saas/). Using multiple cloud providers with multiple cloud services requires an architecture that enables workflow portability, and organizations will need an unbiased, multi-cloud strategy to make that a reality.\n\n## What is multi-cloud?\n\nMulti-cloud describes [how enterprises use multiple cloud providers to meet different technical or business requirements](https://www.zdnet.com/article/multicloud-everything-you-need-to-know-about-the-biggest-trend-in-cloud-computing/). At its core, multi-cloud is made possible through cloud-native applications built from containers using services from different cloud providers. It allows for multiple services to be managed in one architecture. [85% of enterprises currently operate in multiple clouds](https://www.ibm.com/blogs/cloud-computing/2018/10/19/survey-multicloud-management-tools/), but just because an organization uses multiple cloud providers doesn’t necessarily mean they are multi-cloud.\n\nBeing dependent on one cloud provider can limit the flexibility of an organization and leave it susceptible to vendor lock-in. Workflow portability is one of the benefits of multi-cloud and it enables a seamless workflow, regardless of _where_ you deploy.\n\nIn addition to workflow portability, there are several reasons why most businesses have adopted multi-cloud, and why more will continue to use this approach:\n\n*   **Greater flexibility**: Each cloud vendor shines in some areas and is weak in others. Using multiple vendors lets you use the right tool for the job.\n*   **Better acquisitions**: Whether an organization wants to grow through acquisitions (or be acquired itself), existing systems can work within another company’s infrastructure, even if both are using separate cloud providers.\n*   **Increased resilience**: Architecting failover between multiple cloud providers lets you stay up even if one of your vendors is down.\n*   **Improved cloud negotiations**: If another cloud vendor offers better terms or significant credits, businesses can have better leverage because their [DevOps processes](/topics/devops/) are not tied to vendor-specific services.\n*   **Fewer conflicts of interest**: With cloud service providers offering so many different services, you’re less likely to find yourself [in conflict with customers competing in those same spaces](https://www.cnbc.com/2017/06/21/wal-mart-is-reportedly-telling-its-tech-vendors-to-leave-amazons-cloud.html).\n\nA multi-cloud strategy allows organizations to use the tools and services that work best for the job, not just tools that work within their cloud environment.\n\n## Can cloud providers really support multi-cloud?\n\nCloud service providers continually compete with each other to provide more services to keep customers in their cloud. The more services you have with one CSP, the less likely you are to migrate those workloads. AWS offers 90 different services, as does GCP. In comparison, [Microsoft lists over 160 services on its Azure product page](https://www.parkmycloud.com/cloud-services-comparison/) and many of them are integrations with other Microsoft products. Cloud service providers want to have more of your business by making you more dependent on their specific services.\n\nEven though most cloud providers claim to support multi-cloud, migrating workloads out of their cloud isn’t in their best interest. As cloud computing is a pay-per-use model, it seems unlikely that multi-cloud would be a goal for the large cloud providers.\n\n## Implementing CI/CD in the cloud\n\nIn the [RightScale 2019 State of the Cloud Report](https://info.flexera.com/CM-REPORT-State-of-the-Cloud), 33% of respondents mentioned [implementing CI/CD](/topics/ci-cd/) in the cloud as a top cloud initiative. DevOps processes play a big role in multi-cloud deployments, so if organizations are wanting to build faster and deploy anywhere, CI/CD will be a key factor in that success. Multi-cloud is all about being cloud-agnostic, and your tools should also support that goal.\n\nBut what if your CI/CD comes from a cloud provider?\n\n### GitHub Actions and GitLab CI/CD\n\nIn 2018, [GitHub announced Actions](/blog/github-launch-continuous-integration/) with CI-like functionality built into a single application offering. The industry has shown us in the past year that single application functionality [is becoming a trend](/blog/built-in-ci-cd-version-control-secret/), and GitLab has been a part of that single application message since the beginning. Now that continuous integration has caught up with the importance of single application, we have to examine how both GitHub and GitLab fit into multi-cloud deployments.\n\nIn June 2018 [Microsoft acquired GitHub](/blog/microsoft-acquires-github/), which really affirmed the importance of software developers and modern DevOps. Developer tools have a high capacity for driving cloud usage because once you have your application code hosted, the natural next step is finding a place to deploy it. From a strategic standpoint, this acquisition made a lot of sense for Microsoft because they could use [GitHub’s popularity as a source code management tool as a springboard for greater Azure adoption](https://www.techrepublic.com/article/with-github-acquisition-microsoft-wants-to-make-azure-the-default-cloud-for-developers/).\n\nWhen we talk about multi-cloud in the CI/CD conversation, cloud-agnosticism kind of goes out the window when it comes to GitHub Actions. GitHub’s ubiquity in the SCM market means that millions of developers are using that platform, and it’s those users that [made GitHub such an appealing asset for Microsoft](/blog/microsoft-acquires-github/).\n\nGitLab, in comparison, is cloud-independent. When organizations use GitLab CI/CD, there is no conflict of interest in using one cloud provider over another. Being truly cloud-agnostic means that GitLab provides a complete [DevOps platform](/solutions/devops-platform/) that allows teams to have the same productivity metrics, the same governance, regardless of what cloud you use.\n\n“Choosing a cloud provider should depend on the company’s business objectives, it should not be constrained by technology, and GitLab wants to enable every one of our customers to have this freedom,” says [Sid Silbrandij](/company/team/#sytses), co-founder and CEO at GitLab.\n\n## Multi-cloud should mean any cloud\n\nBusinesses want to choose cloud providers for their inherent value and use the services that best meet their needs. In turn, we should expect our DevOps processes to support multi-cloud objectives. Partnering with cloud-agnostic vendors provides a consistent workflow across all clouds, and CI/CD will play a big role in the multi-cloud future.\n\nWe’d love for you to watch our webcast _Mastering your CI/CD_ so you can see for yourself how GitLab’s industry-leading CI/CD helps teams build, test, deploy, and monitor code on any cloud.\n\n[Watch the webcast](/competition/github/)\n{: .alert .alert-gitlab-purple .text-center}\n\nCover image by [Alexandre Chambon](https://unsplash.com/@goodspleen?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[110,1255,806],{"slug":2543,"featured":6,"template":681},"gitlab-ci-cd-is-for-multi-cloud","content:en-us:blog:gitlab-ci-cd-is-for-multi-cloud.yml","Gitlab Ci Cd Is For Multi Cloud","en-us/blog/gitlab-ci-cd-is-for-multi-cloud.yml","en-us/blog/gitlab-ci-cd-is-for-multi-cloud",{"_path":2549,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2550,"content":2556,"config":2562,"_id":2564,"_type":17,"title":2565,"_source":18,"_file":2566,"_stem":2567,"_extension":21},"/en-us/blog/devops-tool-landscape",{"title":2551,"description":2552,"ogTitle":2551,"ogDescription":2552,"noIndex":6,"ogImage":2553,"ogUrl":2554,"ogSiteName":667,"ogType":668,"canonicalUrls":2554,"schema":2555},"The DevOps tool landscape","Competitive intelligence manager Mahesh Kumar describes the criteria we use when comparing GitLab to other DevOps tools.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670008/Blog/Hero%20Images/devops-tool-landscape.jpg","https://about.gitlab.com/blog/devops-tool-landscape","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The DevOps tool landscape\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mahesh Kumar\"},{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-11-01\",\n      }",{"title":2551,"description":2552,"authors":2557,"heroImage":2553,"date":2559,"body":2560,"category":14,"tags":2561},[2558,1483],"Mahesh Kumar","2019-11-01","\nOne of the [core values](https://handbook.gitlab.com/handbook/values/) at GitLab is transparency, and it is in this spirit that we evaluate and articulate how GitLab fits into the competitive landscape. One of the ways we’ve demonstrated this transparency is by [listing other DevOps tools](/competition/) on our website and how they compare to functionality in GitLab. This approach is a little unorthodox but we believe this transparency not only helps teams make the right decisions, it also helps us identify where we can improve our product.\n\nFor any competitive comparison to be effective, it has to be fair, accurate, and easy to understand. Whether we’re comparing [three versions of Jenkins](/blog/jenkins-one-year-later/) to GitLab CI/CD, or comparing other [DevOps tools](/topics/devops/devops-tools-explained/) in the SDLC, we try to ensure these three key objectives of competitive comparisons are achieved.\n\n## Staying fair\n\nOne of the biggest challenges in competitive comparisons is staying fair and credible. The selection of competitive comparison criteria plays a significant role because it has to be comprehensive and not self-serving. Far too often vendors restrict competitive comparison criteria to what their product does well and avoid the gaps that might be in their products. At GitLab, we make a concerted effort to avoid this pitfall, and our culture of transparency keeps us honest in our assessment of where we excel and where we can do better.\n\nThe [GitLab Maturity Framework](/direction/maturity/) articulates the stages, categories, and features that constitute the end-to-end DevOps lifecycle. The maturity framework shows where GitLab provides an elevated user experience and also outlines our planned roadmap for the future. Since this framework takes a long-term view of criteria/features that constitute various DevOps stages and categories, we use this framework as a guide for our competitive comparisons.\n\nIn our GitLab Maturity Framework, we have a few categories where we rank as one of the best-in-class, both with industry analysts and GitLab users: Source code management, code review, and continuous integration (CI). To see one of these comparisons, check out our Jenkins CI page where we outline features, pricing, and a comprehensive overview.\n\n[Jenkins vs. GitLab](/devops-tools/jenkins-vs-gitlab/)\n{: .alert .alert-gitlab-purple .text-center}\n\n## Keeping it accurate\n\nHaving settled on criteria for evaluation, getting the data accurate is a major challenge. We have a structured information gathering process as laid out below:\n\n    1. Website\n    2. Documentation\n    3. Demos\n    4. Product install and usage\n    5. Customer feedback\n\nSometimes we are unable to complete this process for all vendor products for several reasons. First is the lack of available information either on a vendor's website or documentation. Second, we may be unable to access their product to validate certain capabilities. Some vendors do not provide a free or easily accessible version of the product, while others may explicitly prohibit the use of their product for comparison purposes. In either case, we restrict our comparison to publicly available details.\n\nThe second challenge in ensuring accuracy is that vendors don't always put out new releases and capabilities on a constant basis and our analysis may be slightly outdated. One of the best examples of this is, “when does one stop [painting the Golden Gate Bridge](http://goldengatebridge.org/research/facts.php#PaintHowOften)?” The answer is never! It’s an ongoing process that requires continuous paint touch-ups from one end to the other.\n\n## Everyone can contribute\n\nOur open source DNA extends to how we manage the tools landscape pages. We freely solicit input internally from multiple teams within GitLab and more importantly from other vendors’ teams. Anyone, including other vendors, can use GitLab to create an issue stating the change they wish to see or information they would like to correct. This issue is then assigned to the appropriate GitLab team to address. In fact, one Product Manager from a vendor recently contacted us about a change to their comparison page, and we gladly made that change.\n\nBy providing an opportunity to comment and give feedback, we hope to foster a dialog with those better informed about different products, thereby improving the tools landscape pages with rich and accurate information.\n\n## Easy to understand\n\nThe final challenge in comparison pages is to make them easy to interpret. We do this in two different ways: First, all the feature-level comparison is listed in the comparison page. For those interested in a particular feature or capability, they can easily scan the page to find the feature they’re looking for.\n\nSometimes the feature details need explanation, or perhaps there’s a feature that doesn’t quite fit into the “yes or no” mold. For that reason, we also provide a top-down analysis at the start of most comparison pages that provides a summary of features and provides additional context. This sometimes means a critical feature can get lost in the text, but we are doing our best to keep consistency across vendors and identify discrepancies quickly.\n\nThere are a lot of DevOps tools out there. As a complete [DevOps platform](/solutions/devops-platform/) delivered as a single application, GitLab can remove the pain of having to choose, integrate, learn, and maintain the multitude of tools necessary for a successful DevOps toolchain. If a DevOps tool is missing, feel free to [email us](mailto:incoming+gitlab-com-marketing-product-marketing-7424125-issue-@incoming.gitlab.com?subject=DevOps%20tool%20request&bcc=devopstools%40gitlab.com&body=-%20Tool%20name%3A%0D%0A-%20Stages%3A%0D%0A-%20Change%3A%0D%0A%0D%0A%0D%0APlease%20leave%20these%20label%20flags.%20%20%20%20%0D%0A%2Flabel%20~comparison%20~Servicedesk) or [create an issue](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#create-a-new-issue) and we’ll be happy to add a feature comparison for that product.\n\nCover image by [Troy Nikolic](https://unsplash.com/@troynikolic?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[110,806,676],{"slug":2563,"featured":6,"template":681},"devops-tool-landscape","content:en-us:blog:devops-tool-landscape.yml","Devops Tool Landscape","en-us/blog/devops-tool-landscape.yml","en-us/blog/devops-tool-landscape",{"_path":2569,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2570,"content":2576,"config":2581,"_id":2583,"_type":17,"title":2584,"_source":18,"_file":2585,"_stem":2586,"_extension":21},"/en-us/blog/speed-security-devops",{"title":2571,"description":2572,"ogTitle":2571,"ogDescription":2572,"noIndex":6,"ogImage":2573,"ogUrl":2574,"ogSiteName":667,"ogType":668,"canonicalUrls":2574,"schema":2575},"How to ensure security at the speed of DevOps","Read here on how to speed up your secure DevOps for faster delivery on your safe and secure applications.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678356/Blog/Hero%20Images/balance-speed-security-devops.jpg","https://about.gitlab.com/blog/speed-security-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to ensure security at the speed of DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-10-31\",\n      }",{"title":2571,"description":2572,"authors":2577,"heroImage":2573,"date":2578,"body":2579,"category":14,"tags":2580},[1985],"2019-10-31","\nChoosing between speed and security leaves some development teams walking a fine\nline between order and chaos. Even in [DevOps](/topics/devops/), if your security practices are\nstill largely manual, teams often choose to release apps before they’re fully\nsecured, rather than waiting for the security team to address critical\nvulnerabilities.\n\nBut what if I told you that you don’t need to choose? Pull your security team,\ntests and practices to the beginning of the SDLC, and embed them throughout to\nreduce time to launch – and launch a secure product.\n\n## Six ways to bring security up to speed\n\n### 1. Make small, frequent changes\nProduce code in small chunks or units, and then run automated tests on those\nunits as they’re committed, so the developers can remediate any\nvulnerabilities on the spot – rather than waiting for feedback days, weeks, or\neven months later. Running regular tests saves time down the road, when the completed\napp is tested before launch.\n\n### 2. Educate developers _and_ security teams\nAdopt or create an educational program that teaches developers to recognize\ncommon vulnerabilities and remediate on their own. Security professionals should\nalso be educated on application development and emerging technology,\nso they can understand developers’ work and ensure their organization isn’t\noverlooking any major vulnerabilities.\n\n### 3. Fail fast, fix fast\nFailing fast is a critical component of the DevOps mindset – and should be\napplied to developers’ security practices as well. If the automated scans\nreveal vulnerabilities, developers should be encouraged to take\nremediation into their own hands, both as a form of self-education, and to keep\nthe SDLC moving quickly.\n\n### 4. Prioritize risks\nRisks will take different levels of priority within a single app, or across all\nof an organization’s apps. DevOps and security teams should work together to\nestablish security guidelines that allow teams to prioritize which risks to\naddress immediately, and which may not need remediation in the short term.\n[Joe Coletta of IBM brings up an important distinction](https://securityintelligence.com/how-to-balance-speed-and-security-in-your-application-security-program/):\nFlaws should be assessed not only by level of severity, but also by likelihood\nof exploitation by an attacker.\n\n### 5. Automate as much as possible\nManual security processes cannot keep up – point blank. There are too many new\ntechnologies, deployments, and access requests for security teams to manually\nhandle everything. Tests should be pre-written and policies pre-defined so\nthat they’re addressed automatically within the development pipeline. Automation\nalso allows developers to focus on business demands – getting the app out\nquickly – while reducing the chance for human error.\n\n### 6. More is better\nTesting more frequently is always better, if it can be done efficiently. In rapid\ndevelopment, teams push small changes continuously, which also means they’re\nable to find vulnerabilities more easily, and push small fixes continuously.\n[As Forrester Research Director Amy DeMartine has stated](https://techbeacon.com/app-dev-testing/has-continuous-security-arrived-rise-rapid-development),\nany changes that developers make [using these methods] will only affect their\nsmall piece of code, without any ramifications on the rest. Ultimately, this\nincreases quality.\n\n## Like always, communication is key\n\nAbove all, your security and DevOps teams **must** be on the same page: A cross-team\nsecurity mindset requires a strong commitment to communication and transparency. Leaders should encourage\nmembers of both teams take initiative to understand the other team’s goals and\nintent, and why these goals are important to both the business and customer. Teams at\nevery business should focus on building a security-first mindset, as today’s\nexpanding attack surfaces provide opportunity for exploitation at every level.\nLastly, make it easy (or as easy as it can be). Integrated tools, or a single\ntool for the entire lifecycle (such as GitLab) will bring transparency to all\nsides of the operation and allow for seamless interactions, change logging,\nand efficiency.\n\nCover image by [Christian Englmeier](https://unsplash.com/@christianem) on [Unsplash](https://unsplash.com/photos/J7EUjSlNQtg)\n{: .note}\n",[894,806,724],{"slug":2582,"featured":6,"template":681},"speed-security-devops","content:en-us:blog:speed-security-devops.yml","Speed Security Devops","en-us/blog/speed-security-devops.yml","en-us/blog/speed-security-devops",{"_path":2588,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2589,"content":2595,"config":2600,"_id":2602,"_type":17,"title":2603,"_source":18,"_file":2604,"_stem":2605,"_extension":21},"/en-us/blog/secure-journey-continuous-delivery",{"title":2590,"description":2591,"ogTitle":2590,"ogDescription":2591,"noIndex":6,"ogImage":2592,"ogUrl":2593,"ogSiteName":667,"ogType":668,"canonicalUrls":2593,"schema":2594},"Securing the journey to continuous delivery","The UK Dept for Work and Pensions bring security best practices to the forefront of a massive transition to continuous delivery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678442/Blog/Hero%20Images/londoncommit.png","https://about.gitlab.com/blog/secure-journey-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Securing the journey to continuous delivery\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-10-30\",\n      }",{"title":2590,"description":2591,"authors":2596,"heroImage":2592,"date":2597,"body":2598,"category":14,"tags":2599},[1985],"2019-10-30","\n[Adam Moss](https://www.linkedin.com/in/adam-moss/?originalSubdomain=uk) is the\nHead of Engineering Strategy, Technical Leadership, DevOps, and SRE at the\nDepartment for Work and Pensions. At this year’s GitLab Commit in London, Adam\nspoke about how his organization transitioned from waterfall to Agile, and how\nthey built security into both their organization's infrastructure and culture.\n\nThe Department for Work and Pensions (DWP) is the United Kingdom’s largest\ngovernment department. It comprises 84,000 employees and serves 22 million\ncitizens, with systems containing approximately 55 million lines of code and\nseeing about 10,000 changes per year.\n\nIn other words, it’s a big deal.\n\nBut their infrastructure and operations were less than stellar. Adam and his\nteam wanted to offer 24/7 service availability, improve their user experience,\nand reduce operational costs. So, they went Agile.\n\n## Big change for big gains\n\nBefore the transformation, the DWP had outsourced services for 30 years. To get\nto [continuous delivery](/topics/continuous-delivery/), they brought everything in-house. In addition to massive\noperational change, this also required an enormous cultural shift within the\norganization. Insourcing meant taking responsibility for everything – they couldn't blame a third party should anything go wrong. Teams also had to take on an iterative mindset: Changing their standard maximum viable product into a minimum one.\n\nThen there was the question of tools, which also brought the question of\nsecurity: What tools would best enable developers, without leaving gaping holes\nin their systems?\n\n## Owning the risk\n\nAs a government organization, the DWP was used to managing risk – but they\nsuddenly found themselves without an outsourced partner to blame. Now that Adam’s\nteam was fully responsible for security efforts, they needed to become much\nmore risk averse. Taking ownership of security is also a big change for\ndevelopers, even for organizations not undergoing massive transformation.\n\n### The journey to DevOps security\n\n#### Considerations\n\nTo keep both processes and systems secure, the DWP took a multi-layered\napproach with people, devices, and code among the top aspects considered.\n\nDevelopers are often highly privileged users, which poses certain risks to your\nenvironment. While it’s necessary to protect both systems and people,\norganizations need to be clear about their security policies and intent in\norder to build and maintain employee trust. Adam puts it this way: Think about\ndisciplinary policies – if a piece of vulnerable code is released and causes a\nproblem, is it the individual’s fault? Or is it a fault of the processes you’ve\nput in place?\n\nAdam also emphasized that restrictions might not be the best answer: Developers\nwill find a way around, so it’s better to implement something that allows\nthem to achieve their objectives without creating any backdoor processes.\n\nThere was also the consideration of open source – while it provides great\nbenefits, there are challenges that must also be managed appropriately. Adam’s\nteam chose to implement continuous vulnerability monitoring (with [GitLab](/solutions/security-compliance/))\nto keep track of any risky dependencies that might spring a data leak. They\nalso chose to use GitLab as a central point of control and single source of\ntruth, increasing transparency for the organization.\n\n#### Lessons learned\n\nIn his presentation, Adam shared some valuable tips for a successful\ntransition to continuous delivery. Here are a few favorites:\n\n##### Automate, automate!\nAutomation will make things immensely easier – not just because of the time\nsaved, but also because of its repeatability and reduced risk for human error.\nFocus on the low-hanging fruit early on in the process. There will always be things you can’t\nautomate, so pick the easy battles first.\n\n##### Identify your pain point\nTake a look across your operations and organization. What is the biggest\nchallenge you can solve? Or, what change will bring a lot of value in the move\nto continuous delivery? Try to achieve ROI as soon as possible.\n\n##### Anticipate risks from an external POV\nAdam recommends threat modeling, and looking at security from the outside in.\nWhat might an adversary be thinking? Why and how might they attack? Some tools\nwill even generate possible situations that you’ve never considered.\n\n##### Continuous doesn’t always mean automatic\nWhile you may want to automate functions as much as possible, the catalyst can\nstill be human. Separation of duties can serve as a useful defense mechanism to\nensure that big changes won’t cause undue risk.\n\n## The journey doesn’t end with DevOps\n\nAdam concludes with some wisdom for the future: Always be thinking about how\nyou’re going to evolve your organization, and make sure your roadmap continues to change as well.\nHe suggests looking externally for options you might not have yet considered,\nlike the capabilities planned for [your favorite DevOps tools](/direction/#devops-stages).\n\nTo build some new ideas into your own roadmap, watch Adam’s talk from GitLab\nCommit London.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/c8zFXUkPb2c\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[894,806,1447,1194,268],{"slug":2601,"featured":6,"template":681},"secure-journey-continuous-delivery","content:en-us:blog:secure-journey-continuous-delivery.yml","Secure Journey Continuous Delivery","en-us/blog/secure-journey-continuous-delivery.yml","en-us/blog/secure-journey-continuous-delivery",{"_path":2607,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2608,"content":2613,"config":2618,"_id":2620,"_type":17,"title":2621,"_source":18,"_file":2622,"_stem":2623,"_extension":21},"/en-us/blog/advanced-devsecops-practices",{"title":2609,"description":2610,"ogTitle":2609,"ogDescription":2610,"noIndex":6,"ogImage":1478,"ogUrl":2611,"ogSiteName":667,"ogType":668,"canonicalUrls":2611,"schema":2612},"How advanced are your DevSecOps practices?","Read here what the three levels of DevSecOps practices are and what they include and how to improve your own","https://about.gitlab.com/blog/advanced-devsecops-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How advanced are your DevSecOps practices?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-10-21\",\n      }",{"title":2609,"description":2610,"authors":2614,"heroImage":1478,"date":2615,"body":2616,"category":14,"tags":2617},[1985],"2019-10-21","\n[DevSecOps](/solutions/security-compliance/) doesn’t happen overnight – between team alignment, new\nresponsibilities, new processes, and automation, there is a lot that needs to\nhappen to reach an advanced state of DevSecOps. Then there's the question of\nwhat it means to be advanced. How do you know when you've reached a comfortably\nmature state? What defines a beginner or intermediate level of DevSecOps maturity?\n\n## Analysing your DevOps practicies?\n\nI set out to find answers to these questions and\ndiscovered a mountain of different measures. So instead of asking you to take your\nown journey through DevSecOps self-discovery, I compiled some points of maturity\nand segmented them into three classes: Beginner, intermediate, and advanced. The folks at the [2018 Open Security Summit](https://2018.open-security-summit.org/outcomes/tracks/owasp-samm/working-sessions/devsecops-maturity-model/) agree that\nDevSecOps maturity is generally evaluated across six dimensions: Technology, processes, culture, tools, automation, and information flow.\n\n## DevOps Maturity: Beginner\n\nTeams in the early phases of DevSecOps adoption show clear attempts to change\nthe inertia of their organizations, but don't yet have all people and processes\non board. A security mindset and culture is beginning to take hold in these early-stage teams. Testing may be interspersed throughout the development lifecycle, but\nsome of those tests may run manually. The processes and\noperations used by early-stage teams often lack transparency and standardization. This lack of clarity makes it difficult for teams to\nreproduce certain activities and requires developers figure out solutions\nfrom scratch when taking on a new project.\n\n## DevOps Maturity: Intermediate\n\nMany teams at an intermediate level of DevSecOps maturity have accepted\nthat security is everyone's responsibility – and dev, sec, and ops teams are\nlearning how to collaborate efficiently on software development. The pipeline\nintegrates automated security checks at a few points throughout the development lifecycle and provides visibility\ninto the actions taking place. Incident response may still lag behind these\nnewer developments, with teams reacting to incidents rather than proactively\ndefending against them.\n\n## DevOps Maturity: Advanced\n\nA mature DevSecOps practice is highly efficient and collaborative.\nDevelopers accept ownership of their security responsibilities and run tests\nagainst their code at every commit to ensure security and compliance. Each\nteam has visibility into an integrated toolchain (or better yet, [a single tool](/stages-devops-lifecycle/)),\nand developers work quickly within a self-service, easy to use, and\ncentralized platform at every phase. Automation helps teams test and remediate,\nminimizes back and forth between teams, and brings security to the speed of\nthe business.\n\nAs a whole, advanced DevSecOps practices take a proactive approach to security.\nCompliance and expectations are defined and standardized across teams. Testing\nshould evolve to anticipate the most likely targets for attack. Automated\nmonitoring will continue security efforts after launch, and response plans (for\nthe sec, dev, and ops teams) should be established in case of a breach.\n\n## DevSecOps is for everyone\n\nEach step toward DevSecOps is a step in the right direction – and it is increasingly\nrisky to leave security as a bolt-on operation. Regardless of size\nor history, every company can and should adopt DevSecOps for\nsoftware development. Strategies may vary: Nimble startups can adjust and\nadapt quickly, while larger incumbent businesses might begin with a pilot project,\nor choose to retrofit new security practices to established products.\n\nPhoto by Stanislav Kondratiev on [Unsplash](https://unsplash.com/s/photos/growth?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[806,894],{"slug":2619,"featured":6,"template":681},"advanced-devsecops-practices","content:en-us:blog:advanced-devsecops-practices.yml","Advanced Devsecops Practices","en-us/blog/advanced-devsecops-practices.yml","en-us/blog/advanced-devsecops-practices",{"_path":2625,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2626,"content":2632,"config":2637,"_id":2639,"_type":17,"title":2640,"_source":18,"_file":2641,"_stem":2642,"_extension":21},"/en-us/blog/better-devops-with-gitlab-ci-cd",{"title":2627,"description":2628,"ogTitle":2627,"ogDescription":2628,"noIndex":6,"ogImage":2629,"ogUrl":2630,"ogSiteName":667,"ogType":668,"canonicalUrls":2630,"schema":2631},"Unlock better DevOps with GitLab CI/CD","Why a single application helps to eliminate silos and knowledge gaps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670652/Blog/Hero%20Images/dev-to-devops-cover.png","https://about.gitlab.com/blog/better-devops-with-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unlock better DevOps with GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-10-18\",\n      }",{"title":2627,"description":2628,"authors":2633,"heroImage":2629,"date":2634,"body":2635,"category":14,"tags":2636},[1483],"2019-10-18","\nWe’ve talked about how the [seamless collaboration between Development and IT operations is a beautiful thing](/topics/devops/build-a-devops-team/). When an organization has a healthy DevOps culture, they’re able to meet business objectives and increase delivery speed. DevOps is meant to eliminate silos so everyone can get on the same page, and the tools you use can play a big role in just how successful, or unsuccessful, your DevOps strategy is.\n\n## Complicated tools create silos\n\nOne of the ways that operations can be at a disadvantage is by having to maintain a [complicated plug-in environment](/blog/plugin-instability/). This scenario becomes especially problematic when things go wrong and developers are relying on a specific group to fix the problem. While specialization isn’t necessarily a bad thing (devs shouldn’t have to do ops, and vice versa), usually the expertise needed to manage a plugin environment is a specialization within an already specialized group.\n\nJenkins is the most popular example of this kind of complexity, for a few reasons:\n\n*   **Jenkins architecture requires maintaining a large set of build environment systems**: At scale, this requires many dedicated people to manage machines, install and manage build tools (NodeJS, Python, Java, et al.), monitor machines, etc.\n\n*   **Upgrading is a risk (Jenkins or plug-ins)**: There is a good chance that upgrades can cause processes to fail, leading to broken builds or downtime.\n\n*   **Groovy is hard to maintain**: This isn't a widely popular script language, so it is harder to find experts to manage it and it's hard to debug due to a lack of debuggers.\n\n*   **Jenkins does not support any kind of clustering or failover**: The web UI is run on a web container known as Jenkins master, and you can only have one. For a large team of developers needing to use Jenkins all at once, that one instance needs to be very closely monitored with limited permissions.\n\nA large Jenkins plug-in environment creates silos within silos and knowledge gaps that are hard to overcome. What this leads to is a “throw it over the wall” team dynamic: Because the system depends on the expertise of a very limited number of people, developers have to submit code and hope their experts have the skills to manage it.\n\n## Lack of visibility keeps teams in the dark\n\nIn order for [DevOps](/topics/devops/) to thrive there needs to be an understanding of what every team is doing and clarity around processes. Unfortunately, a tool like Jenkins doesn’t necessarily facilitate this. Because users can’t see other users’ commits, they can’t visualize the SDLC as a whole. This only isolates teams even further.\n\nTeams that work within this plug-in environment often download the plug-ins they need, which makes it hard for Jenkins admins to standardize across teams. That, in turn, makes it harder for admins to manage the dependencies and maintain plug-ins properly, which can lead to more broken builds.\n\nWhile plug-ins are a common way to add functionality into a toolchain, it doesn’t address the problems of a toolchain that hinder teams trying to implement DevOps:\n\n*   Lack of visibility\n*   Knowledge gaps\n*   Work silos\n\n## Why single application CI/CD makes better DevOps\n\nAs a complete [DevOps platform](/solutions/devops-platform/) delivered as a single application, we provide a tool that covers all parts of the SDLC from one interface. CI and CD are just one part of the lifecycle, and by having functionality like [SCM, Issue tracking, Security testing, and Monitoring](/devops-tools/jenkins-vs-gitlab/) built right in, we’re making it easier for teams to work with DevOps best practices.\n\nIf you would like to see a demo of GitLab CI/CD and how we compare to Jenkins, and access other curated content around CI/CD, you can watch our most recent webcast.\n\n[Watch the demo.](/blog/migrating-from-jenkins/)\n{: .alert .alert-gitlab-purple .text-center}\n",[110,1255,806],{"slug":2638,"featured":6,"template":681},"better-devops-with-gitlab-ci-cd","content:en-us:blog:better-devops-with-gitlab-ci-cd.yml","Better Devops With Gitlab Ci Cd","en-us/blog/better-devops-with-gitlab-ci-cd.yml","en-us/blog/better-devops-with-gitlab-ci-cd",{"_path":2644,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2645,"content":2651,"config":2657,"_id":2659,"_type":17,"title":2660,"_source":18,"_file":2661,"_stem":2662,"_extension":21},"/en-us/blog/auto-devops-explained",{"title":2646,"description":2647,"ogTitle":2646,"ogDescription":2647,"noIndex":6,"ogImage":2648,"ogUrl":2649,"ogSiteName":667,"ogType":668,"canonicalUrls":2649,"schema":2650},"Auto DevOps 101: How we’re making CI/CD easier","VP of product strategy Mark Pundsack shares everything you need to know about Auto DevOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666915/Blog/Hero%20Images/autodevops.jpg","https://about.gitlab.com/blog/auto-devops-explained","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Auto DevOps 101: How we’re making CI/CD easier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-10-07\",\n      }",{"title":2646,"description":2647,"authors":2652,"heroImage":2648,"date":2653,"body":2654,"category":14,"tags":2655},[890],"2019-10-07","\nContinuous integration and continuous delivery (CI/CD) are the gold standards of software development but they can be challenging to achieve. GitLab’s [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) feature is designed to make the CI/CD process much easier with baked-in best practices and automation that will move code seamlessly through the entire development lifecycle. [Mark Pundsack](/company/team/#markpundsack), VP of product strategy, demonstrated how straightforward – and customizable – Auto DevOps is during our company-wide meeting, [Contribute 2019](/blog/how-we-scaled-our-summits/). Here’s what you need to know to get started with [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/).\n\n## It’s a shift... left\n\n“Auto DevOps is a [CI/CD pipeline](/topics/ci-cd/) that we have defined for you,” Mark says. “It’s basically all these best practices that we want to encourage everybody to have, and we believe are a good baseline for software development.” The goal is to have everyone set up to do CI/CD, but not just the bare minimum CI/CD, he says. “Like most people when they create a project, they start with running tests. That's the natural thing for CI. And then maybe they'll even get into CD, but they're not going to do things like [code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) analysis and security analysis. And we really believe in the [shift left movement](/blog/secure-containers-devops/). If you look at everything as a pipeline, we want to take security and things like that which are stuck at the end and we want to move them as far left as possible. We believe you should be checking for security even on your first deploy. So we said, okay, let's put all that in there and make a script that says this is everything that you should be doing, so let's just do it for you.”\n\nThe roots of Auto DevOps can be found in previous versions of GitLab which offered Auto Deploy. “We evolved [Auto DevOps] as the company evolved to have more and more capabilities around the DevOps lifecycle,” Mark explains. Today, Auto DevOps tackles 12 software development steps automatically. Customers wanting more flexibility can choose the [Composable Auto DevOps](/releases/2019/04/22/gitlab-11-10-released/#composable-auto-devops) option, where the template can easily be modified to suit the requirements.\n\n## The Auto DevOps process\n\nAuto DevOps begins with language detection using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks). While not all languages are supported, a build is created and tested automatically for the supported languages, Mark explains. Auto DevOps uses the open source version of [Code Climate](https://codeclimate.com/oss) to do code quality analysis and the results are displayed in the merge request when a change is made. After that, it’s time for security testing; including dependency scanning, license management, and container scanning. “All those things kick off again right from your first deploy,” Mark says. “We’re really taking shifting left seriously there.”\n\nAt this point developers are able to auto review applications. And once that review app is available Auto DevOps will kick off [dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/). “It tries to detect security vulnerabilities in your running application,” Mark says. Finally Auto DevOps will auto deploy to either staging or production depending on how its configured. “From the first push it just automatically does all this stuff all the way – from deployment to production – which is pretty great.”\n\nAn app in production will get automatic browser performance testing which both challenges the application and records the results. [Auto monitoring](https://docs.gitlab.com/ee/topics/autodevops/#auto-monitoring) is also running so users can easily track response times, error rates, and even things like CPU and memory utilization. “All of this happens without any configuration whatsoever and that's really, that's why we put ‘auto’ in front of all of these,” Mark says. “It's really almost all the capabilities of our [DevOps lifecycle](/stages-devops-lifecycle/) thrown in by default.”\n\nWatch Mark demonstrate exactly how Auto DevOps works in the video below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pPRF1HEtQ3s\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Joshua Sortino](https://unsplash.com/@sortino) on [Unsplash](https://unsplash.com)\n{: .note}\n",[110,806,935,2656],"production",{"slug":2658,"featured":6,"template":681},"auto-devops-explained","content:en-us:blog:auto-devops-explained.yml","Auto Devops Explained","en-us/blog/auto-devops-explained.yml","en-us/blog/auto-devops-explained",{"_path":2664,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2665,"content":2671,"config":2676,"_id":2678,"_type":17,"title":2679,"_source":18,"_file":2680,"_stem":2681,"_extension":21},"/en-us/blog/plugin-instability",{"title":2666,"description":2667,"ogTitle":2666,"ogDescription":2667,"noIndex":6,"ogImage":2668,"ogUrl":2669,"ogSiteName":667,"ogType":668,"canonicalUrls":2669,"schema":2670},"The problem with plugins","For all of the customization, plugins sometimes come at a high price.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673012/Blog/Hero%20Images/plugin-instability.jpg","https://about.gitlab.com/blog/plugin-instability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The problem with plugins\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-09-27\",\n      }",{"title":2666,"description":2667,"authors":2672,"heroImage":2668,"date":2673,"body":2674,"category":14,"tags":2675},[1483],"2019-09-27","\nWe’ve talked a lot over the past year about how [all-in-one is taking over the marketplace model](/blog/github-launch-continuous-integration/), and we highlighted [CloudBees adding SDM](/blog/jenkins-one-year-later/) in our most recent example. Even with all of the consolidation we’ve seen lately, plugins are still a popular [DevOps solution](/topics/devops/). On the surface, there’s a lot to appreciate: Literally thousands of plugins offer seemingly limitless customization without you having to make large investments in other tools. Need something? Chances are there’s a plugin for that.\n\nJenkins plugins have served as both a selling point **_and_** a downside – but how can a strength also be a weakness? All that customization comes with a few caveats.\n\n## Plugins and security vulnerabilities\n\nJenkins offers more than 1,600 community-contributed plugins. David Fiser over at the TrendLabs Security Intelligence Blog highlighted some [Jenkins security advisories associated with plain-text-stored credentials](https://blog.trendmicro.com/trendlabs-security-intelligence/hiding-in-plain-text-jenkins-plugin-vulnerabilities/) from July and August 2019. There were six plugins affected, one of which has been deprecated. At the time of article publication (August 30), three of the plugins had not been fixed.\n\nTo properly store credentials, a third-party credential provider, such as the `Credentials` plugin, is recommended. Organizations can also use a [`Secret`](https://javadoc.jenkins.io/index.html?hudson/util/Secret.html) to store credentials. Jenkins was proactive in identifying these potential problems but, in the case of plugins, Jenkins can only recommend best practices and notify users once they’re aware of a potential issue. Because the plugins are operated by third parties, there’s also no guarantee any problems will be fixed.\n\nInstalling Jenkins plugins is limited to either a dedicated Jenkins admin or someone with exclusive access to the Jenkins filesystem, but uploading a potentially malicious plugin to the Jenkins plugin site doesn’t require as much authentication.\n\nThe team at CyberArk wanted to see just how easy it would be for an attacker to infiltrate a plugin. Dubbed [Aladdin’s Lamp](https://www.cyberark.com/threat-research-blog/jenkins-plugins-aladdins-lamp-and-the-sultan-of-threats/), the CyberArk team modified the existing Green Balls plugin that changed the plugin image to an image of Aladdin’s lamp. What they inserted discreetly into the code was a capability that gave any unauthenticated remote attacker SYSTEM access to a Jenkins master that installed their plugin with a specially crafted request:\n\n[`http://jenkinsURL:8080/OpenSesame`](http://jenkinsURL:8080/OpenSesame)\n\nTheir experiment was not malicious, of course, but it highlighted just how easy it could be to exploit the plugin ecosystem.\n\n## Plugins and brittle pipelines\n\nIt’s a tall order for users to weigh the pros and cons of more than 1,600 plugins, and many people rely on a plugin’s popularity in order to gauge whether it’s a suitable option. A simple search for a Docker plugin could show almost 26 results, and upon further review, one of the top results has eight plugin dependencies. If a team is using plugins for Docker, Kubernetes, GitLab, Go – those dependencies can really add up, and that’s where teams start seeing brittle pipelines.\n\nTechnology is constantly evolving, and keeping up with all of these dependencies can spell trouble for pipelines. The last thing you want is a broken deployment pipeline because [the pipeline itself is broken vs. the actual software artifact or build that’s being tested](https://harness.io/2018/09/4-reasons-your-jenkins-pipelines-are-brittle/).\n\nA vast majority of Jenkins plugins were created by third-party developers, meaning they can vary in quality and [some plugins lose support without notice](https://thenewstack.io/many-problems-jenkins-continuous-delivery/). Abandoned plugins are out there because their creators have opted to work on something else. Teams have to be diligent with maintaining these plugins with every new Jenkins version, but as any Jenkins admin can tell you, [this process has not always gone over well](https://jenkins.io/blog/shifting-gears/).\n\n## Plugins and maintenance\n\nWe touched on this briefly but admins are mostly in agreement that Jenkins maintenance is, to put it simply, not a great time. There’s a reason why developers often talk about their love/hate relationship with Jenkins – **_yay!_**, there’s a plugin for everything I need, **_oh no!_** I’m a Jenkins plugin maintainer now.\n\nUpgrading one plugin means you’ll likely have to update many others, and many Jenkins admins do this directly on their production Jenkins master. In one example, [Blue Ocean requires dozens of dependencies, many of which you may have no use for](https://cb-technologists.github.io/posts/jenkins-plugins-good-bad-ugly/), such as the Bitbucket Pipeline for Blue Ocean and the GitHub Pipeline for Blue Ocean plugins, even if you don’t use either Bitbucket or GitHub for source control.\n\n## Plugins: Pros and cons\n\nThere are pros and cons to anything and plugins are no exception. There is a lot to love about plugins:\n\n*   Flexibility\n*   Customization\n*   Convenience\n\nAnd there are things to be wary of:\n\n*   Maintenance\n*   Dependencies\n*   Lack of support\n*   Security vulnerabilities\n\nWith Jenkins’s modular architecture there’s a building block for everything you need. However, an ecosystem built entirely on plugins is going to require some discipline, and that means dedicating resources into maintaining that plugin environment.\n\nPlugins can be a great asset for a DevOps team. As CloudBees pointed out, [even GitLab uses plugins](https://docs.gitlab.com/ee/administration/file_hooks.html). We just don’t think you should have to use plugins for really basic tasks. In the end, it’s important for organizations to weigh the pros and cons of different platforms for themselves. You can check out our ebook, “The benefits of single application CI/CD,” and see how we stack up against other CI tools.\n\nCover image by [Fernando Lavin](https://unsplash.com/@filmlav?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@filmlav?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[110,806],{"slug":2677,"featured":6,"template":681},"plugin-instability","content:en-us:blog:plugin-instability.yml","Plugin Instability","en-us/blog/plugin-instability.yml","en-us/blog/plugin-instability",{"_path":2683,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2684,"content":2689,"config":2694,"_id":2696,"_type":17,"title":2697,"_source":18,"_file":2698,"_stem":2699,"_extension":21},"/en-us/blog/jenkins-one-year-later",{"title":2685,"description":2686,"ogTitle":2685,"ogDescription":2686,"noIndex":6,"ogImage":2246,"ogUrl":2687,"ogSiteName":667,"ogType":668,"canonicalUrls":2687,"schema":2688},"Jenkins: One year later","With new acquisitions and the launch of CloudBees SDM, is Jenkins trying to become another all-in-one?","https://about.gitlab.com/blog/jenkins-one-year-later","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jenkins: One year later\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-09-20\",\n      }",{"title":2685,"description":2686,"authors":2690,"heroImage":2246,"date":2691,"body":2692,"category":14,"tags":2693},[1483],"2019-09-20","\n\nIt’s been a little over a year since we wrote about [how GitLab CI compares with the three variants of Jenkins](/blog/how-gitlab-ci-compares-with-the-three-variants-of-jenkins/). How have things changed – and how much has stayed the same?\n\n## Acquisitions\n\nIn April 2019, [CloudBees acquired Electric Cloud](https://www.businesswire.com/news/home/20190418005393/en/CloudBees-Acquires-Market-Leader-Electric-Cloud-Creating), a market leader in continuous delivery. This acquisition brought application release automation, continuous delivery, and continuous deployment under the Cloudbees umbrella through two of Electric Cloud’s premier products: ElectricFlow and ElectricAccelarator.\n\nThis acquisition came a little more than a year after [CloudBees acquired Codeship](https://techcrunch.com/2018/02/06/cloudbees-acquires-codeship-as-devops-consolidates/), another startup focused on continuous integration and delivery. These investments in continuous delivery tools are all about creating value. Because Jenkins doesn’t have continuous delivery built-in, it has to offer integrations with other tools (or acquire them) in order to offer that functionality. Acquisitions go a little deeper than just setting up an API, and are a lot more expensive. Could the acquisition of these two CD platforms give Jenkins the ability to offer CI/CD in their core product in the future?\n\n## Jenkins X\n\nThere has been a strong push by certain vendors to create a solution for combined CI/CD to match the capabilities of GitLab. GitHub developed GitHub Actions while CloudBees supported the development of Jenkins X, for example. Jenkins X was developed to automate continuous delivery pipelines to Kubernetes and cloud-native environments. [According to the Jenkins X website](https://jenkins-x.io/), “Rather than having to have deep knowledge of the internals of Jenkins X Pipeline, Jenkins X will default awesome pipelines for your projects that implement fully CI and CD.”\n\n## JenkinsWorld\n\nIn his [opening Keynote at JenkinsWorld 2018](https://www.youtube.com/watch?v=qE3tfS7k1VI&t=2s), CloudBees CTO Kohsuke Kawaguchi discussed some of the known unreliability of Jenkins and discussed how Cloud Native Jenkins could address some of these problems by removing the single point of failure and creating a more distributed system.\n\nAt JenkinsWorld 2019, [CloudBees offered an early preview of its CloudBees SDM Platform](https://www.businesswire.com/news/home/20190814005028/en/CloudBees-Presents-Software-Delivery-Management-SDM--).\n\nSource code management brings visibility and cross-functional collaboration into the SDLC, something that (until now) CloudBees could only offer through a plug-in. This new platform is a part of the CloudBees objective to be an end-to-end platform.\n\nWhat was most interesting was this quote from Sacha Labourey, CEO and co-founder of CloudBees:\n\n>“Organizations need a way to eliminate silos – to truly realize their vision of becoming software-first companies. This vision is Software Delivery Management and we are building the cohesive system our customers want. It will connect product stakeholders and development teams with the rest of the business, provide the intelligence and insights they all need to build software faster and provide increased value to their customers.”\n\nWe couldn’t agree more. ;)\n\n## A push for consolidation\n\nWith the acquisitions of Codeship and Electric Cloud, as well as the announcement of CloudBees SDM, it’s clear that CloudBees/Jenkins is pushing to be an end-to-end SDLC solution for its users. We’re seeing this throughout the industry: Idera purchasing Travis CI, Oracle acquiring Werker, JFrog’s acquisition of Shippable, and the launch of GitHub Actions just last month. Either through acquisitions or adding new features, [the app development industry is in a push for consolidation](/blog/built-in-ci-cd-version-control-secret/).\n\nToolchains get in the way of organizations enabling faster software delivery and realizing their maximum business impact. Where CloudBees/Jenkins has faltered is in its instability, mainly due to the thousands of third-party plugins it supports and the maintenance headaches they cause. At GitLab, we enable SDM, packaging, delivery, monitoring, and security in the product itself without the plugins.\n\nBecause [transparency is one of our values](https://handbook.gitlab.com/handbook/values/), we proudly display other DevOps tools directly on our website with [head-to-head comparisons](/devops-tools/jenkins-vs-gitlab/) so that organizations can know which platform works best for their needs.\n\nCompetition makes everyone else better, and with CloudBees/Jenkins amping up their consolidation efforts, how does that compare to us as an already all-in-one platform? We invite you to join us for a demo so you see how GitLab CI/CD compares to Jenkins firsthand.\n\n[See demo of GitLab CI/CD vs. Jenkins](/blog/migrating-from-jenkins/)\n{: .alert .alert-gitlab-purple .text-center}\n",[110,806],{"slug":2695,"featured":6,"template":681},"jenkins-one-year-later","content:en-us:blog:jenkins-one-year-later.yml","Jenkins One Year Later","en-us/blog/jenkins-one-year-later.yml","en-us/blog/jenkins-one-year-later",{"_path":2701,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2702,"content":2708,"config":2715,"_id":2717,"_type":17,"title":2718,"_source":18,"_file":2719,"_stem":2720,"_extension":21},"/en-us/blog/gitlab-hashicorp-terraform-vault-pt-1",{"title":2703,"description":2704,"ogTitle":2703,"ogDescription":2704,"noIndex":6,"ogImage":2705,"ogUrl":2706,"ogSiteName":667,"ogType":668,"canonicalUrls":2706,"schema":2707},"GitLab and HashiCorp: Providing application and infrastructure delivery workflows","Discover how to leverage CI/CD for your infrastructure scripts with Terraform and GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670238/Blog/Hero%20Images/gitlab-terraform-pipelines.jpg","https://about.gitlab.com/blog/gitlab-hashicorp-terraform-vault-pt-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab and HashiCorp: Providing application and infrastructure delivery workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kelly Hair\"},{\"@type\":\"Person\",\"name\":\"Anthony Davanzo\"}],\n        \"datePublished\": \"2019-09-17\",\n      }",{"title":2703,"description":2704,"authors":2709,"heroImage":2705,"date":2712,"body":2713,"category":14,"tags":2714},[2710,2711],"Kelly Hair","Anthony Davanzo","2019-09-17","\nA growing number of teams are becoming more and more invested in continually improving the business through iterative development. Adopting the culture of DevOps isn’t necessarily confined to software development itself, but is equally applicable to ITOps, System Admins, and other infrastructure teams as well. Just as a proper CI/CD workflow is the foundation of today’s application delivery, a similar automated workflow is essential for managing the delivery of infrastructure as well.\n\nAs developers try to become more agile in building, packing, and testing their applications, having the right CI/CD tool that is flexible to other automation use cases is critical. GitLab has gone into great detail about their [flexible CI/CD capabilities here](https://docs.gitlab.com/ee/ci/introduction/index.html#how-gitlab-cicd-works). What’s sometimes overlooked is implementing the proper CI/CD process for the underlying infrastructure that these applications rely on. In addition to application delivery, organizations need to consider what their infrastructure delivery process looks like. GitLab and HashiCorp have partnered to create a multi-blog series on how to combine the application delivery workflow with the infrastructure delivery workflow. In this part we will discuss a high-level overview of the solutions that we will dive deeper into in Part 2.\n\n## Leveraging HashiCorp Terraform for CI/CD Pipelines\n\n[HashiCorp Terraform](https://www.terraform.io/) is an open source tool for provisioning infrastructure as code. Users define infrastructure in HashiCorp Configuration Language (HCL) configuration files, Terraform reads those configurations, offers a speculative plan of what it will create, and then users confirm and apply those changes. Terraform keeps track of what infrastructure is provisioned in a state file.\n\nThe recently announced Terraform Cloud application provides users with additional automation and collaboration capabilities on top of Terraform, such as remotely managing and version that state file, executing Terraform runs (plan/apply) remotely, and allowing teams to comment and collaborate on Terraform. By remotely managing state files, Terraform Cloud empowers teams to work more quickly and safely in parallel without concerns of losing the file or overwriting each other's changes. These features are especially helpful for users implementing CI/CD pipelines because they allow users to interact with Terraform via webhooks/API instead of having Terraform run on a local machine.\n\nMost users will store their configuration files in a VCS (Version Control System) like GitLab and connect that VCS to Terraform Cloud. That connection allows users to borrow best practices from software engineering to version and iterate on infrastructure as code, using VCS and Terraform Cloud as a provisioning pipeline for infrastructure. Terraform will automatically run a plan upon changes to configuration files in a VCS. This plan can be reviewed by the team for safety and accuracy in the Terraform UI, then it can be applied to provision the specified infrastructure. Terraform Cloud can also be configured to automatically apply those changes.\n\nTerraform Cloud also includes a Governance upgrade, which provides access to the [Sentinel](https://www.hashicorp.com/sentinel) policy as code framework.  This framework allows users to define fine-grain rules and policies for their infrastructure that are automatically enforced before that infrastructure is provisioned. This allows users to work with the speed and efficiency they want in their continuous integration/delivery pipelines, while still ensuring that best practices are being implemented.\n\n### Future iterations\n\nIt is also worth discussing current work in progress with GitLab and Vault. Vault from Hashicorp secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets that services depend on. In efforts to improve [Variables and secrets management in GitLab CI/CD](https://gitlab.com/groups/gitlab-org/-/epics/816) we’re working with HashiCorp to provide a [first-class integration with Vault](https://gitlab.com/gitlab-org/gitlab-ce/issues/61053) sometime in the future.\n\n## Next steps\n\nAs a follow up, we will soon be posting a blog on the technical details of _how_ to build a Terraform pipeline in GitLab CI/CD.\n\nIn meantime, check out how [WagLabs reduced their release process from 40 minutes to just six](/blog/wag-labs-blog-post/), using Terraform and GitLab CI/CD!\n\n### About the authors\n\n_[Anthony Davanzo](https://www.linkedin.com/in/anthonydavanzo/) is the product marketing manager for Terraform Cloud at HashiCorp. In this role he focuses on bringing Terraform Cloud to market, hoping to drive adoption and spread awareness of the tool. His prior role as the technical product marketing manager for Terraform helps with deep domain knowledge and before HashiCorp, he was a product marketing manager at Cloudflare._\n\n_[Kelly Hair](/company/team/#khair1) is a solutions architect at GitLab._\n\nPhoto by [Saad Salim](https://unsplash.com/@saadx?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[110,723,806,232,1851],{"slug":2716,"featured":6,"template":681},"gitlab-hashicorp-terraform-vault-pt-1","content:en-us:blog:gitlab-hashicorp-terraform-vault-pt-1.yml","Gitlab Hashicorp Terraform Vault Pt 1","en-us/blog/gitlab-hashicorp-terraform-vault-pt-1.yml","en-us/blog/gitlab-hashicorp-terraform-vault-pt-1",{"_path":2722,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2723,"content":2728,"config":2734,"_id":2736,"_type":17,"title":2737,"_source":18,"_file":2738,"_stem":2739,"_extension":21},"/en-us/blog/security-testing-principles-developer",{"title":2724,"description":2725,"ogTitle":2724,"ogDescription":2725,"noIndex":6,"ogImage":1286,"ogUrl":2726,"ogSiteName":667,"ogType":668,"canonicalUrls":2726,"schema":2727},"5 Security testing principles every developer should know","Developers are looking for guidance and standard practices as they take on more security testing responsibilities.","https://about.gitlab.com/blog/security-testing-principles-developer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Security testing principles every developer should know\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"},{\"@type\":\"Person\",\"name\":\"Seth Berger\"}],\n        \"datePublished\": \"2019-09-16\",\n      }",{"title":2724,"description":2725,"authors":2729,"heroImage":1286,"date":2731,"body":2732,"category":14,"tags":2733},[1985,2730],"Seth Berger","2019-09-16","\n## Principles of secure testing and how to do it\n\nSecurity testing is no longer under sole ownership of the security team. New\ntools have made it easy to bring testing into the DevOps model, where developers\ncan review and test code as they build out the app or software. However,\ndevelopers aren’t always on board with conducting security tests themselves:\nNearly half of security professionals surveyed in [GitLab’s 2019 Global\nDeveloper Report](/developer-survey/) (49%) said they\nstruggle to get developers to make remediation of vulnerabilities a priority.\nLike the developers and operations professionals, 50% of security teams\nsurveyed also believe testing is what most slows down development. AppDev leaders can improve their teams' security practices by building team buy-in and adopting tools that make it easy for developers to follow the five principles outlined below.\n\n## Security should be with you every step of the way\n\nWe’ve reached a day and age where security can’t be an afterthought or bolt-on\nactivity: Everyone is responsible for ensuring their work does not put the\ncustomer or business at risk. Security isn't just a box to check either, it’s a\nway of operating that should stay with you through development, deployment, and\nupdates. Developers can adopt security as their own by following these five\nprinciples:\n\n### 1. Evangelize your security efforts\n\nWhile developers are taking more responsibility for security, an overall\nquestion of ownership still remains. Everyone should be responsible for\nsecurity, but all too often that “everyone” comes to mean “no one”. Dev team\nleaders should advocate for security and the proper time to address it. Without\nthe proper advocacy, resources won't be allocated and security can become high-\nrisk technical debt. By shifting security left in the software development\nprocess, developers can allocate resources early on while they are still\nplentiful. Make it easy for your developers to adopt strong security practices\nby creating team-wide guidelines, educating developers on best practices and\ncommon challenges, and standardizing your expectations through both team and\nindividual security metrics.\n\n### 2. Test early, test often\n\nDevSecOps is an important next step in your DevOps initiatives. [Security teams\nare three times as likely to discover bugs before code is merged](/developer-survey/), so test as you\ncode and begin fixing vulnerabilities as early as possible. By incorporating tools\nthat help with dependency scanning, dynamic application security testing (DAST),\nand static application security testing (SAST), developers can get feedback as code is written and committed. These tools can give\ndevelopers information about the security of their code early in the development\nprocess, making it faster and cheaper to remediate compared to making fixes later on.\n[In a mature DevOps model, teams are 90% more likely to test between\n91% and 100% of all code than organizations with early-stage DevOps](/developer-survey/).\nTesting should continue throughout the DevOps lifecycle, so that developers are\nable to change code before it’s integrated into the broader codebase. Frequent testing will\nultimately take less time and fewer resources, speed time to deployment, and\nreduce friction between IT and security.\n\n### 3. Always verify your changes with a second set of eyes\n\nWriting and updating code should always be a joint effort. A second set of eyes\nwill spot potential issues that the author wasn’t able to see, and will reduce\nthe risk of deploying code that still has vulnerabilities. A [randomized buddy\nsystem](/blog/play-reviewer-roulette/) comes in handy here, to ensure that code reviews aren’t being handed to\nthe same person time after time, and allows different team members to\nlook at work that may be different from their own activities. Don't be afraid to\nuse tooling to help implement code reveiws and approvals. Configure your tooling\nto [require approvers within your merge request process](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/).\nCulture is an important element when it comes to code review: Your team of\ndevelopers must care about the integrity of the product or project as a whole,\nand not just the speed or quality of their own code development.\n\n### 4. Keep a master log of every code deployment, dependency, and update\n\nTransparency is key to ensuring quality code. Creating a complete history of your code\nwill be helpful in reviews and incident response, and allows the security team or\ndevelopers to identify exactly when and where a vulnerability occurred. Teams should\nalso minimize any manual build or deployment processes to ensure that their\napplications have full traceability and logging.\nWith a majority of application code being open source, dependencies have become a\nmajor attack surface. What’s more, bugs in open source code generally fly under\nthe radar (no pun intended), undetected by developers until it’s too late.\nUnderstanding, patching, and updating dependencies is critical, as catastrophic\nbreaches ([such as WannaCry](https://en.wikipedia.org/wiki/WannaCry_ransomware_attack))\ncan and have occurred due to a missed update or patch. Security scans using updated vulnerability databases should be run on a regular\nbasis to maintain app security – even on code that has previously been scanned.\n\n### 5. Diversify your security portfolio\n\nEmploy many different types of testing to cover your bases. A single type of\ntesting, like SAST, DAST, pre-release scanning, pen testing, or dependency\nscanning is helpful, but won’t provide a complete view of your application\nenvironment. [Forrester's annual application security report](https://www.forrester.com/report/The+State+Of+Application+Security+2019/-/E-RES145135)\nnotes that security teams are adjusting their practices to help developers respond to\nvulnerabilities at the speed of development. Some teams now conduct software\ncomposition analysis ahead of production, and have moved static application\nsecurity testing (SAST) to early development ([something your team can achieve\nwith GitLab](https://docs.gitlab.com/ee/user/application_security/sast/)).\nOthers are using bug bounty programs to crowdsource vulnerability discovery,\nwhich is particularly helpful for uncovering problems that don’t fall into known\nsecurity flaw patterns.\n\n## Work to achieve a DevSecOps model\n\nNearly 70% of developers are expected to write secure code, but only 25% of\ndevelopers believe they have “good” security practices. DevOps is a great place\nto start: It’s [clear from our data](/developer-survey/)\nthat a more mature DevOps model encourages innovation and collaboration, and\nenables teams to test more code faster. As more teams continue to shift their\nsecurity practices left, DevSecOps will become an advantageous reality for\ndevelopers and security professionals alike.\n\nCover photo by [Patrick Tomasso](https://unsplash.com/@impatrickt?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\non [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,894],{"slug":2735,"featured":6,"template":681},"security-testing-principles-developer","content:en-us:blog:security-testing-principles-developer.yml","Security Testing Principles Developer","en-us/blog/security-testing-principles-developer.yml","en-us/blog/security-testing-principles-developer",{"_path":2741,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2742,"content":2747,"config":2753,"_id":2755,"_type":17,"title":2756,"_source":18,"_file":2757,"_stem":2758,"_extension":21},"/en-us/blog/is-serverless-the-end-of-ops",{"title":2743,"description":2744,"ogTitle":2743,"ogDescription":2744,"noIndex":6,"ogImage":2381,"ogUrl":2745,"ogSiteName":667,"ogType":668,"canonicalUrls":2745,"schema":2746},"Is serverless the end of ops?","What is Serverless architecture, what are the pros and cons of using it and where will it go in the future?","https://about.gitlab.com/blog/is-serverless-the-end-of-ops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Is serverless the end of ops?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-09-12\",\n      }",{"title":2743,"description":2744,"authors":2748,"heroImage":2381,"date":2749,"body":2750,"category":14,"tags":2751},[1483],"2019-09-12","\nWe’re not playing tricks when we say [serverless](/topics/serverless/) isn’t actually serverless. It’s not that servers aren’t doing work, it’s just that _your_ servers aren’t necessarily having to do the work. In these exciting times of automation, not having to worry about servers seems pretty appealing.\n\n[Serverless architecture has an annual growth rate of over 700%](https://hackernoon.com/severe-truth-about-serverless-security-and-ways-to-mitigate-major-risks-cd3i3x6f) and shows no signs of slowing down. Its popularity is all due to the operational efficiency it promises. Instead of worrying about infrastructure, you can essentially outsource those responsibilities to your cloud provider. Once you specify the resources your code requires, the cloud provider provisions the servers and deploys. Even better, you only pay for what is used.\n\nThe dream of serverless computing is pretty simple: Developers deploy into infrastructures they don’t have to manage, set up, or maintain. Once they upload a simple cloud function it _just works_. Since organizations are only paying for what they use, this system is infinitely scalable, and because this is all managed by a cloud provider, they take over security as well.\n\nWith a serverless architecture carrying all of the ops load, what does that mean for sysadmins?\n\n## Serverless: The end of ops?\n\nServerless hype hasn’t been without skepticism. On the ops side of things, there has been some concern that serverless is trying to force ops out of the picture. A successful [DevOps team structure](/topics/devops/build-a-devops-team/) is all about dev and ops working together but, as we well know, there are some challenges to overcome. For one: dev and ops teams are incentivized by vastly different things. Development wants faster feature delivery, whereas operations wants stability and availability. These two goals contradict each other. With serverless bypassing ops altogether, it unintentionally reinforces the “ops as a barrier” trope.\n\nGetting to the point: No, serverless is not the end of ops as we know it. Ops looks after monitoring, security, networking, support, and the overall stability of a system. Serverless is just one way of managing systems, but it isn’t the only way. [The sysadmin is still happening – you’re just outsourcing it with serverless](https://martinfowler.com/articles/serverless.html), and that’s not necessarily a bad (or good) thing.\n\nEven with so many new technologies and methodologies out there – Kubernetes, serverless, containerization – the basics of computing remain the same. It’s only when we understand the fundamentals and commit to building reliable code that we can make the most of these new platforms.\n\n[In a recent interview with Google Staff Developer Advocate Kelsey Hightower](/blog/kubernetes-chat-with-kelsey-hightower/), one of the biggest challenges he mentions is the “all-or-nothing” approach. “Either I’m all serverless, or I’m all Kubernetes, or I’m all traditional infrastructure. That has never made sense in the history of computing.” Ultimately, you don’t have to choose: Pick the platforms that work best for the job. Monoliths are easy to build and run, and microservices and Kubernetes can help organizations scale faster. Serverless is just another tool that teams can use to keep innovating.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/9OHNejqXOoo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n\n## Serverless pros and cons\n\nAs with any architecture, there are going to be some benefits and some disadvantages. It’s important to weigh the pros and cons carefully against your organization’s needs.\n\n### Less operational overhead\n\nThis is frequently listed as one of the biggest advantages of serverless. Security patches, server upgrades, and other maintenance are already taken care of, which can free up resources for more important things.\n\n### Scalability\n\nYou just upload a code/function and your cloud provider handles the rest. [Serverless allows as many functions to be run (in parallel, if necessary) as needed to continually service all incoming requests](https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9). Or you can have serverless run an entire application (with frontend, backend, etc.) and still reap the benefits. Because you’re not boxed into a certain pricing structure or number of minutes, serverless can be infinitely scalable (in theory).\n\n### Less operating costs\n\nYou’re only using what you need and all costs are purely based on usage. Finances are dynamic, which is more representative of how companies actually operate.\n\nOne example of this concept is comparing a rideshare service to the costs of owning a vehicle. With a car, there are costs you pay regardless of usage (insurance, registration, car payment), there are costs you pay depending on the usage (gas, maintenance), and then there are additional costs tied to unforeseen circumstances (accidents, that pothole again). With a rideshare, you’re just paying to go from point A to point B – all car costs we listed previously are being taken care of by someone else.\n\n### Less control\n\nOften cited as the biggest con, what you gain in reduced operational costs, complexity, and engineering lead time comes with [increased vendor dependencies](https://martinfowler.com/articles/serverless.html) and less oversight. There has to be a lot of trust in the cloud vendor since you’ll be unable to manage the server yourself. Not having control of your system means that if errors happen, you’re reliant on someone else to fix them. In business, no one cares more about your problems than you do.\n\n### Potential security risks\n\nWhile cloud vendors will manage security for you, and are generally well equipped for that task, it’s the architecture of serverless itself that could introduce vulnerabilities into the system. The problem is especially true for serverless applications built on top of microservices, with independent pieces of software interacting through numerous APIs. Gartner warns that [APIs will become the major source of data breaches by 2022](https://www.gartner.com/doc/3834704/build-effective-api-security-strategy).\n\n### Unpredictable costs\n\nHow can we list costs as both a pro and a con? That’s mainly due to the elasticity serverless offers. Since everything is event-triggered, rather than paid up front, elasticity becomes a double-edged sword: You’re not paying for cloud usage you don’t need, but it being so easy to use means you may end up using more.\n\nFor another real-world example of this concept in action, let’s examine ketchup, mainly the introduction of the plastic squeeze bottle.\n\nHeinz ketchup had been served in the iconic glass bottles we all know and love since 1890, but in 1983 the Heinz corporation unveiled the squeezable plastic bottle to consumers. This was heralded as a huge innovation – consumers could squeeze more precisely, the bottles were unbreakable which reduced losses in shipment, and the ergonomic design made it perfect for hands of all sizes. After the introduction of the new squeezable bottle, [ketchup sales went up by 3.7% from the prior year](https://www.npr.org/sections/thesalt/2014/04/29/306911004/whats-the-secret-to-pouring-ketchup-know-your-physics). Why? Now that ketchup could be dispensed more easily, people used a lot more of it. Instead of tapping on a glass bottle hoping for a drop, the ketchup cup runneth over.\n\nWith serverless being so easy to use, it’s best to assume that developers will use it more than you expect.\n\n## Where are we on our serverless journey?\n\nSo much of the literature about serverless comes from the cloud providers themselves, so of course it focuses on the most idealized vision of what serverless can be. As a result, those in the ops community felt like they were being forced out, and organizations were too busy paying attention to the benefits to see the potential downsides.\n\nServerless opens up a lot of opportunities in DevOps, and offers a unique solution for many use cases. Does this mean that sysadmins everywhere will soon be out of a job? Probably not. Serverless is just another tool in the toolbox, and at GitLab we’re exploring how to help users leverage Knative and Kubernetes to define and manage serverless functions in GitLab. We’re also looking into how we can be even more multi-faceted. Some users want to work with a Kubernetes cluster, some want to push a serverless function into AWS Lambda. We can already help with monoliths and microservices, and we’re actively working on supporting serverless as well.\n\nInterested in joining the conversation for this category? Please join us in our [public epic](https://gitlab.com/groups/gitlab-org/-/epics/155) where we discuss this topic and we can answer any questions you might have. Everyone can contribute.\n\nPhoto by [Tomasz Frankowski](https://unsplash.com/@sunlifter?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1076,995,2752],"demo",{"slug":2754,"featured":6,"template":681},"is-serverless-the-end-of-ops","content:en-us:blog:is-serverless-the-end-of-ops.yml","Is Serverless The End Of Ops","en-us/blog/is-serverless-the-end-of-ops.yml","en-us/blog/is-serverless-the-end-of-ops",{"_path":2760,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2761,"content":2767,"config":2772,"_id":2774,"_type":17,"title":2775,"_source":18,"_file":2776,"_stem":2777,"_extension":21},"/en-us/blog/software-dependencies-tech-debt",{"title":2762,"description":2763,"ogTitle":2762,"ogDescription":2763,"noIndex":6,"ogImage":2764,"ogUrl":2765,"ogSiteName":667,"ogType":668,"canonicalUrls":2765,"schema":2766},"Don’t let your dependency-laden software become the next monolith","Keep your software development fast and efficient with dependency scanning and auto-remediation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678488/Blog/Hero%20Images/software-dependencies-monolith.jpg","https://about.gitlab.com/blog/software-dependencies-tech-debt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Don’t let your dependency-laden software become the next monolith\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-09-09\",\n      }",{"title":2762,"description":2763,"authors":2768,"heroImage":2764,"date":2769,"body":2770,"category":14,"tags":2771},[1985],"2019-09-09","\nDependencies are a great tool for developers: They save time, which saves money\nand helps meet the need for speed when developing. But with great dependencies\ncomes great responsibility because it’s easy to accumulate tech debt in the form\nof dependencies. What happens when you need to alter a line of code? Does it\nbreak your software? What is the cost of fixing a bug, updating dependencies,\nor adding a new module? Suddenly your software management starts to resemble the\nstruggles of a monolithic architecture, where changing one small piece can break\neverything.\n\n## Software dependencies are like bricks, but flammable\n\nEach module added to your software can be thought of like a brick: Small parts\nof a greater whole. But now imagine that those bricks are highly flammable. You\nhave a significant chance of catastrophe with the tiniest of sparks.\n\nThat spark could be a single code change, [deleted code like the LeftPad\nincident](https://www.businessinsider.com/npm-left-pad-controversy-explained-2016-3),\na corrupted library, a missed patch, or patch that forces updates to all your\nother dependencies. There’s also the issue of security flaws – when a bug is\nfound, the whole open source community is in the know, and that applies to\nhackers as well. Popular dependencies [can quickly become targets](https://www.aptible.com/blog/vulnerability-scanning-for-your-dependencies-why-and-how)\nas soon as the news of a patch is released. Another common risk of all third-party software and code are [zero-day attacks](https://www.csoonline.com/article/3284084/what-is-a-zero-day-a-powerful-but-fragile-weapon.html),\nwhen a previously unknown vulnerability is exploited by hackers before a patch\nor update is applied.\n\n## Software dependency scanning: Your firetruck dispatch\n\nDependency scanners have risen in popularity and breadth in recent years,\nproving themselves useful tools for incident prevention. Scanners generally\nprovide a list of all the dependencies within your code or app, along with a\nlist of all the known vulnerabilities within each dependency. Scans can be done\nmanually or automatically. Users can [set up scans that run automatically within GitLab](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), which is helpful for code that\nisn’t updated often.\n\nDependency scanners can also be used to look for redundancies within projects\nthat have been worked on or updated without a detailed changelog, or over a\nlong period of time. Simplifying your dependencies will reduce the risk of a\ncode change chain reaction, and will also reduce your attack surface.\n\n## Auto-remediation: The all-in-one fire prevention and firehose tool\n\n[Auto-remediation tools](/direction/secure/#auto-remediation)\ncan find vulnerabilities within your code, evaluate the scope of any problems,\nand propose a solution. Developers can even set up auto-remediation tools to\napply solutions under defined circumstances, shortening the time the vulnerability window\nis open to cyber assailants. Once that fix is automatically created, next it is\ntested. If it passes all the tests defined for your application, the fix is then\ndeployed to production.\n\nAuto-remediation tools can also help verify that changes made in dependency\nupdates didn’t break any parts of your application – kind of like making sure\nyou’ve turned off the stove before leaving the house.\n\n## Build your house by laying each brick with intention\n\nDependencies help simplify coding, but they add complexity when it comes to\nmanaging the bigger picture. So it is crucial to understand what\ndependencies you have, where you can simplify, and how your current and new\ndependencies will affect your software in the future. Take command of your\ndependencies with tools like dependency scanners and auto-remediation, and use\nthat information and experience to build future software with efficiency and\nintention.\n\nCover photo by [Grace Kadiman](https://unsplash.com/@gracekadiman?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\non [Unsplash](https://unsplash.com/search/photos/brick-laying?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[852,894],{"slug":2773,"featured":6,"template":681},"software-dependencies-tech-debt","content:en-us:blog:software-dependencies-tech-debt.yml","Software Dependencies Tech Debt","en-us/blog/software-dependencies-tech-debt.yml","en-us/blog/software-dependencies-tech-debt",{"_path":2779,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2780,"content":2786,"config":2791,"_id":2793,"_type":17,"title":2794,"_source":18,"_file":2795,"_stem":2796,"_extension":21},"/en-us/blog/developers-write-secure-code-gitlab",{"title":2781,"description":2782,"ogTitle":2781,"ogDescription":2782,"noIndex":6,"ogImage":2783,"ogUrl":2784,"ogSiteName":667,"ogType":668,"canonicalUrls":2784,"schema":2785},"4 Ways developers can write secure code with GitLab","GitLab Secure is not just for your security team – it’s for developers too. Learn four ways to write secure code with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666895/Blog/Hero%20Images/developers-write-secure.jpg","https://about.gitlab.com/blog/developers-write-secure-code-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 Ways developers can write secure code with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-09-03\",\n      }",{"title":2781,"description":2782,"authors":2787,"heroImage":2783,"date":2788,"body":2789,"category":14,"tags":2790},[1985],"2019-09-03","\nWriting secure code is a standard part of day-to-day development work, but\nsecurity often appears to be a roadblock instead of a critical piece of the\npuzzle. To make security efforts easier, [GitLab Secure](/stages-devops-lifecycle/secure/)\noffers a number of different tools that help developers identify and remediate vulnerabilities\nwithin their code, _as they’re writing it_. Our goal is to seamlessly integrate\nsecurity into your code writing practices so you’re better able to protect\nyour business from growing cybersecurity threats.\n\n## Testing\n\nThere are a variety of testing tools available to developers within GitLab.\nGenerally, they alert developers to vulnerabilities within their code and report\nthem within the merge request so developers can adjust their code as they\ngo. In addition to the testing methods outlined below, developers can also [use\nother tools outside of GitLab](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#plays-well-with-others) by integrating\nthe results of your scanners with our merge request security reports.\n\n### Static application security testing\n\nOur [static application security testing](https://docs.gitlab.com/ee/user/application_security/sast/index.html)\n(SAST) tool scans the application source code\nand binaries to spot potential vulnerabilities before deployment. It uses open\nsource tools that are installed as part of GitLab. Vulnerabilities are shown\nin-line with every merge request and results are collected and presented as a\nsingle report.\n\n### Secret detection\n\n[Secret detection](https://docs.gitlab.com/ee/user/application_security/sast/#secret-detection)\nwithin GitLab is able to detect secrets and credentials that\nhave been unintentionally pushed to the repository. This check is performed by\na specific analyzer during the SAST job, runs regardless of the programming\nlanguage of your app, and displays results within the SAST report.\n\n### Dynamic application security testing\n\nOur [DAST tool](https://docs.gitlab.com/ee/user/application_security/dast/index.html)\nanalyzes your web application for known runtime\nvulnerabilities. It conducts live attacks against a review app and can be created for every\nmerge request as part of GitLab’s [CI/CD capabilities](/topics/ci-cd/). Users can provide HTTP\ncredentials to test private areas. Vulnerabilities are shown in-line with every\nmerge request.\n\n### Dependency scanning\n\n[Dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html)\nanalyzes external dependencies (e.g. libraries like Ruby gems) for known\nvulnerabilities on each code commit with GitLab CI/CD. This scan relies on open\nsource tools and on the integration with [Gemnasium](https://docs.gitlab.com/ee/user/project/import/index.html)\ntechnology (now part of\nGitLab) to show, in-line with every merge request, vulnerable dependencies\nin need of updating. Results are collected and available as a single report.\nDependency scanning also provides a list of your project’s dependencies with\ndifferent versions for languages and package managers supported by Gemnasium.\n\n### Container scanning\n\nIf you’re using GitLab CI/CD, [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html)\nwill let you check Docker images (and containers) for\nknown vulnerabilities in the application environment. Analyze image contents\nagainst public vulnerability databases using the open source tool, [Clair](https://coreos.com/clair/docs/latest/),\nthat\nis able to scan any kind of Docker (or app) image. Vulnerabilities are shown\nin-line with every merge request.\n\n### License management\n\nUpon code commit, project dependencies are reviewed for [approved and blacklisted\nlicenses](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html)\ndefined by custom policies per project. Software licenses are\nidentified if they are not within policy, and new licenses are also listed if\nthey require a status designation. This scan relies on an open source tool,\nLicenseFinder, and license analysis results are shown in-line for every merge\nrequest for immediate resolution.\n\n### Code quality analysis\n\nWith the help of GitLab CI/CD, you can analyze your source code quality using\nGitLab [Code Quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html).\nCode Quality uses [Code Climate Engines](https://codeclimate.com/)\nand runs in pipelines using a Docker image built into the Code Quality\nproject. Once the\nCode Quality job has completed, GitLab checks the generated report, compares the\nmetrics between the source and target branches, and shows the information\nwithin the merge request. With pipelines that enable concurrent testing and\nparallel execution, teams quickly receive insight about every commit, allowing\nthem to deliver higher quality code faster.\n\n### The Security Dashboard\n\nSecurity dashboards in GitLab exist at both the project and group level. The\ngroup dashboard provides an overview of all the security vulnerabilities in your\ngroups and projects. In the dashboard, developers are able to drill down into a\nvulnerability for further details, see which project it comes from and the file\nit’s in, and view various metadata to help analyze the risk.\n\nThe dashboard also allows viewers to\n[interact with vulnerabilities](https://docs.gitlab.com/ee/user/application_security/index.html#interacting-with-the-vulnerabilities)\nby creating an issue for them or dismissing them. For ease of use, vulnerabilities\nwithin the group Security Dashboard can be filtered by severity, confidence, report type, and project.\n\nIn addition to the vulnerability overview, the group Security Dashboard also\nprovides a timeline that displays how many open vulnerabilities your projects\nhad at various points in time. While security scans are automatically run for\neach code update, you’ll have some default branches that are infrequently\nupdated. To keep your Security Dashboard up to date on those branches, you can\nuse GitLab to [configure a scheduled pipeline](https://docs.gitlab.com/ee/ci/pipelines/schedules.html)\nto run a daily security scan.\n\n## What’s next for GitLab Secure?\n\nWhile we already have a number of ways to help you write secure code and build\nsecure products and services, we’re always looking for ways to give you more.\nHere are a few of the things we’re working on:\n\n### Interactive application security testing\n\nInteractive application security testing (IAST) checks the runtime behavior of applications by\ninstrumenting the code and\nchecking for error conditions. It is composed by an agent that lives inside the\napplication environment, and an external component, like DAST, that can interact\nand trigger unintended results.\n\n### Fuzzing\n\n[Fuzzing](/direction/secure/dynamic-analysis/fuzz-testing/)\nis a testing technique focused on finding flaws and vulnerabilities in\napplications by sending arbitrary payloads instead of valid input. The idea is to\ntrigger exceptions and unintended code paths that may lead to crashes and\nunauthorized operations. Once a possible problem – like a crash – is found,\nattackers can attempt to find the exact conditions needed to trigger the bug\nand see if they can be fine-tuned to obtain a useful result. (It is worth noting\nthat fuzzing is primarily intended for security teams because it requires more\ntime to execute. While fuzzing is a useful testing method, it should not be a\ndevelopment blocker).\n\n### Vulnerability database\n\nGitLab integrates access to proprietary and open source application security\nscanning tools. In order to maintain the efficacy of those scans, we strive to\nkeep their underlying vulnerability databases up to date.\n\n### Auto remediation\n\nVulnerabilities that require manual intervention to create a fix and push it to\nproduction have a time window where attackers have the ability to leverage the\nvulnerability. Auto remediation aims to automate the vulnerability solution flow and\nautomatically create a fix. The fix is then tested, and if it passes all the\ntests already defined for the application, it is deployed to production.\n\nPhoto by [Daniel McCullough](https://unsplash.com/@d_mccullough?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\non [Unsplash](https://unsplash.com/search/photos/write?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[894,806,110,1115,935],{"slug":2792,"featured":6,"template":681},"developers-write-secure-code-gitlab","content:en-us:blog:developers-write-secure-code-gitlab.yml","Developers Write Secure Code Gitlab","en-us/blog/developers-write-secure-code-gitlab.yml","en-us/blog/developers-write-secure-code-gitlab",{"_path":2798,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2799,"content":2805,"config":2810,"_id":2812,"_type":17,"title":2813,"_source":18,"_file":2814,"_stem":2815,"_extension":21},"/en-us/blog/software-test-at-gitlab",{"title":2800,"description":2801,"ogTitle":2800,"ogDescription":2801,"noIndex":6,"ogImage":2802,"ogUrl":2803,"ogSiteName":667,"ogType":668,"canonicalUrls":2803,"schema":2804},"An inside look at software testing at GitLab","Director of quality engineering Mek Stittri talks test technology and the future of automation at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680800/Blog/Hero%20Images/softwaretestlaunch.jpg","https://about.gitlab.com/blog/software-test-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"An inside look at software testing at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-08-30\",\n      }",{"title":2800,"description":2801,"authors":2806,"heroImage":2802,"date":2807,"body":2808,"category":14,"tags":2809},[890],"2019-08-30","\n\n_In our [just-released survey of over 4,000 developers, security\nprofessionals, and operations team members](/developer-survey/), there was one thing everyone agreed on: 50% of each group\nsaid software testing is the biggest reason why development is delayed. Testers have long\nbeen the underdogs in the SDLC and that viewpoint is apparently very slow to change.\nTo understand what’s really going on, and how things work at GitLab, we\nasked [Mek Stittri](/company/team/#mekdev), director of quality engineering, to share his\nperspective on what’s working with test today and what’s in need of improvement._\n\n## Why is test a continued DevOps problem?\n\nIt’s a two-part answer, Mek says. First, there are simply not enough tests run and second, the tests that are used are often flaky (meaning their results aren’t necessarily trustworthy).\n\nTackling the issue of not running enough tests, Mek says it’s an area GitLab is addressing. “At GitLab, I think we are better than other companies where developers write unit tests and integration tests every time a change goes in,” he says. “That is great, but that testing is at a lower level, and it doesn't really map to a business use case.” To write better tests a team needs test requirements, but there can be so many different sets of stakeholders that it can be tough to get their input about *test* requirements and not just feature requirements. “We are improving it here at GitLab where our VP of Product [Scott Williamson](https://gitlab.com/sfwgitlab) is doing a great job. We have a section for test requirements right now (in the issue and merge request templates). It's now a blank and free form for people to fill in, but it should be highlighted going forward as a required section taking input from product discovery and validation as a deliverable.”\n\nThe bottom line: the stakeholders who are delivering the code need to understand the end goal better. “Unit tests test code at a smaller scale, and that’s great, but it doesn’t really verify the functionality works end to end as a whole. We need more coverage and more understanding of what needs to be tested.”\n\n![The Apollo 11 launch framework](https://about.gitlab.com/images/blogimages/apollo11framework.png){: .shadow.small.center}\nApollo 11 is held up by a framework and software is no different.\n{: .note.text-center}\n\nMek likens this process to Apollo 11. Everyone is excited about the rocket (the software features, in other words) but no one pays attention to the red scaffolding on the right that’s actually holding the rocket up. “That’s the side that nobody looks at but it’s a lot of work,” he says. “It’s taller than the rocket. We need to build that platform to have adequate testing (functional, performance, etc).” The ideal situation to get a company there? Start building the test framework and add test coverage at the exact same time the product is being built. “You assemble it together, run it, it’s passing and we go for launch and it’s shipped. We’re not there yet. And I can assure you a lot of companies out there aren’t there yet either.”\n\n## About those flaky tests…\n\n“There are a lot of test automation engineers and test developers out there, but not all of them know how to write and design a good test,” Mek explains. Automated tests needs to function like a flow of self-retrying dominoes where if one step is not completed it needs to keep retrying to reach the next step. Tests need to mimic what a manual tester would do, he says. No manual tester is going to click on a button and then wait 10 minutes. The tester will click again, or try other strategies. “At GitLab [we put emphasis on test framework reliability](/handbook/engineering/quality/#test-framework-reliability-and-efficiency) and we treat each user workflow step like a piece of retrying dominoes. We need to make sure all the dominoes fall over so the workflow is completed,” Mek says.\n\n>We need more coverage and more understanding of what needs to be tested.\n\nSo companies need to think through how the tests work, but also test the right things. If that happens, quality can be everyone’s responsibility in the end, Mek says. “We want developers to contribute to the end-to-end test so you want to make a test framework that is easy to use and easy to read. I think this all factors in.” And Mek points out it really is in everyone’s best interests to think about quality first. “Let's make the process better so we work smarter, right? We achieve more without having to work weekends or get pinged during your family dinner. Nobody wants that.”\n\n## Test automation and machine learning\n\nTest automation is a cornerstone of successful [DevOps](/topics/devops/) but it remains difficult for many companies to achieve. Mek’s take: “We need to design the product such that the test automation framework can integrate into it well,” he says flatly. That requires good collaboration with development teams due to frontend UI locators and backend APIs that are the interfaces to enable better and stable test automation. “Go back to Apollo 11,” Mek says. “It's like the connections along the rocket's fuselage. I need to integrate with this to make sure things are working fine. The probes and sensors need to be there. So if those aren't there, then your test automation engineers need to code around these obstacles. It's not working smart.” In other words, the test automation framework should not take the longer route when executing user interactions to the application because this can be the source of unstable and in-efficient tests.\n\nOne step that can help companies – including GitLab – get there is [machine learning](https://medium.com/machine-learning-for-humans/why-machine-learning-matters-6164faf1df12). “We are having discussions here at GitLab about where we want a bot,” Mek says. “I think machine learning will come and help, but the input and output needs to be clearly defined so you have a clear implementation direction, TensorFlow, Linear Regression, or whatever techniques. You can write a bot that just lives in the product, meaning it looks at all the UI locators (dedicated to test automation) on a page and randomly clicks one of those links.” This GitLab bot of the future will work 24/7, clicking, clicking, clicking on the page until it errors out or runs into a 404, Mek says. The goal is to create a bot that is like a “menacing QA engineer” that can be programmed to keep banging on the problematic areas until everything is solved. To get there will require lots of data – machine learning literally needs to learn from data and experience – and although there are a handful of companies experimenting with this now, this is all still very early stage.\n\n## Where we’re headed with testing\n\nMek and his team hope to increase both quality and productivity this year which may be a bit of a balancing act, since more “quality” equals more testing which can result in a longer development cycle and perhaps reduced productivity (this is why we say test automation engineers are often unappreciated!). “My department is working this quarter to have a full suite of automated tests for our enterprise features. We want to have a big checkbox for the enterprise features every time we deploy. We need this because it is mapping to the business use case.” But Mek and team need to do all of that while shortening the test runtime for developers. “You want more test coverage but we need to keep the runtime low because we can’t have developers and release managers wait two hours.”\n\nThe plan is to add more runners, optimize them, de-duplicate some tests and make sure the process is as streamlined as it can be. “Right now it takes about an hour or so, but I would love to have it down to 30 minutes where we certify that this merge request going in checks all the boxes and all the enterprise features are not broken. We need to set ourselves an aggressive goal and I would say 30 minutes is a good first step.”\n\nCover image by [Kurt Cotoaga](https://unsplash.com/@kydroon) on [Unsplash](https://unsplash.com)\n{: .note}\n",[676,935,806,1255],{"slug":2811,"featured":6,"template":681},"software-test-at-gitlab","content:en-us:blog:software-test-at-gitlab.yml","Software Test At Gitlab","en-us/blog/software-test-at-gitlab.yml","en-us/blog/software-test-at-gitlab",{"_path":2817,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2818,"content":2824,"config":2831,"_id":2833,"_type":17,"title":2834,"_source":18,"_file":2835,"_stem":2836,"_extension":21},"/en-us/blog/cloudhealth-and-gitlab-reducing-overruns",{"title":2819,"description":2820,"ogTitle":2819,"ogDescription":2820,"noIndex":6,"ogImage":2821,"ogUrl":2822,"ogSiteName":667,"ogType":668,"canonicalUrls":2822,"schema":2823},"How to prevent deployments from overrunning your budget","Guest authors from VMware share how to include budget and resource checking into your continuous deployment with Cloudhealth and GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670389/Blog/Hero%20Images/gitlab-cloud-journey.png","https://about.gitlab.com/blog/cloudhealth-and-gitlab-reducing-overruns","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to prevent deployments from overrunning your budget\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Davis\"},{\"@type\":\"Person\",\"name\":\"Bahubali (Bill) Shetti\"}],\n        \"datePublished\": \"2019-08-26\",\n      }",{"title":2819,"description":2820,"authors":2825,"heroImage":2821,"date":2828,"body":2829,"category":14,"tags":2830},[2826,2827],"Tim Davis","Bahubali (Bill) Shetti","2019-08-26","\n\nManaging deployments is a complex task and DevOps admins generally consider it a victory when a deployment is\nachieved and somewhat repeatable. Unfortunately this process doesn't give DevOps admins time to\nconsider the impact of the outcome on the larger operations pipeline. We know the importance of\n[Continuous Verification](https://thenewstack.io/continuous-verification-the-missing-link-to-fully-automate-your-pipeline/)\n– it's just one of several day-two operations and best practices that need to be brought into the\ncontinuous deployment (CD) process to achieve efficiencies. But we also need to look at the budget.\n\n## Adding budget and resource checking into your CD\n\nMost developers and DevOps admins don't consider the impact of their deployment on the budget. They\nalso don't generally check if sufficient resources in AWS exist prior to deployment because, after\nall, aren't there \"unlimited\" resources on AWS?\n\nAdding the proper budget and resource checks into the pipeline helps avoid:\n\n* Potential rollbacks and clean-up actions\n* Redeployment (\"lift and shift\") into other regions in AWS\n* Long analysis to pinpoint budget overruns\n\nNot having to deal with these tasks improves the DevOps admin's metrics, such as mean time to change (MTTC),\ndeployment time, etc., and subsequently efficiency goes up.\n\n## Understanding the policy\n\nPrior to implementing any of these checks, it’s important to understand the \"policy.\" While every\norganization is different, and the iterations of \"policy\" are endless, there are some basic checks\nthat should always be implemented:\n\n* Ensure the project-specific budget is not already overrun\n* Will this deployment exceed the project budget?\n* Is the project already over project-specific limits and restrictions? (i.e. cannot use RDS, or\ncan't have more than 10 EC2 instances in a deployment)\n* Will this deployment exceed the project-specific resource policy?\n\nWith these basic checks in place, at least some initial sanity is achieved during a pipeline execution.\nMore and more complex iterations can be added as more is learned about the project and processes are improved.\n\n## How do you do it?\n\nRegardless of the policy complexity, implementing these checks can be easily accomplished with\nstandard off-the-shelf tools like [CloudHealth by VMware](https://cloudhealthtech.com) and [GitLab](/).\n\n* CloudHealth by VMware allows you to define \"perspectives\" specific to your project, create governance\nrules, and access this information through an API for easy integration into any CI/CD tool.\n* GitLab allows you to easily add in scripts and/or pre-built code (containers) enabling\nany possible check against any potential external system.\n\nIn order to highlight how to implement this type of check into the CI/CD pipeline, we've\ndelivered an [example configuration](https://cloudjourney.io/articles/multicloudops/budget_check_cicd-td/)\nusing both CloudHealth and GitLab. We hope this provides a nice baseline to build from.\n\n![CD WITH A CH check from GitLab CI/CD pipelines](https://about.gitlab.com/images/blogimages/glcdpipeline.png){: .shadow.medium.center}\n\n## In summary\n\nAlthough we've provided a baseline that we hope can be used for more complex policy checks in CD,\nconvincing DevOps admins to implement this is another problem. Improving metrics should provide\nan incentive for DevOps admins but it is not sufficient for them to simply add budget and resource checks.\nWhile every enterprise has its own process and metrics, we recommend adding a budgetary efficiency\nmetric for DevOps admins.\n\nUsing the configuration above, it’s easy to add in CloudHealth to continuously check the project's\nbudget and utilization, and adding a DevOps budget metric will not only ensure that these checks\nare deployed but will also lead to more efficient deployments.\n\nIf you have any questions regarding this or any other issue, feel free to reach out\nto us [@cloudjourneyio](https://twitter.com/cloudjourneyio) on Twitter!\n\n### About the guest authors\n\n_Bahubali (Bill) Shetti is the director of public cloud solutions for VMware Cloud Services at VMware.\nHe leads a team of cloud architects that evangelize and develop solutions for improving public cloud\noperations (AWS/Azure/GCP). Bahubali was part of the initial team that developed and launched\nVMware Cloud Services. Previous to VMware, he was director of product management at VCE\n(now Dell) for Cloud Management Products. Between 2011-2014, Bahubali lead operations at Cumulus\nNetworks, lead AWS cloud operations at several startups, and headed an open source routing\nsoftware project. Between 2008-2010, Bahubali lead the cloud investment practice at Storm Ventures.\nHe spent 9 years at Cisco in product management and business development. He holds an M.S. in\nInformation Networking from Carnegie Mellon and a B.S. in Electrical Engineering from Rutgers._\n\n_Tim Davis is a cloud advocate at VMware where he focuses on public cloud operations and cloud native\napplications. He provides consulting guidance to a wide range of customers on these topics and\nprovides a bridge between customers and product teams at VMware. He also works to evangelize\nnative cloud usage including AWS, Azure and GCP. Prior to his current role, he was a specialist systems\nengineer focused on VMware’s Networking and Security product line. Before VMware, Tim worked as a\nconsultant and VMware architect at Dell Services, which wasone of the largest contracts held at\nthe time. His background is in operations/management and architecture. He holds numerous\nindustry certifications including from VMware and Amazon Web Services._\n",[110,723,806,232],{"slug":2832,"featured":6,"template":681},"cloudhealth-and-gitlab-reducing-overruns","content:en-us:blog:cloudhealth-and-gitlab-reducing-overruns.yml","Cloudhealth And Gitlab Reducing Overruns","en-us/blog/cloudhealth-and-gitlab-reducing-overruns.yml","en-us/blog/cloudhealth-and-gitlab-reducing-overruns",{"_path":2838,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2839,"content":2845,"config":2850,"_id":2852,"_type":17,"title":2853,"_source":18,"_file":2854,"_stem":2855,"_extension":21},"/en-us/blog/manage-agile-teams-with-microservices",{"title":2840,"description":2841,"ogTitle":2840,"ogDescription":2841,"noIndex":6,"ogImage":2842,"ogUrl":2843,"ogSiteName":667,"ogType":668,"canonicalUrls":2843,"schema":2844},"How to manage Agile teams with microservices","GitLab Groups and Projects can help teams divide work by product or system.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669575/Blog/Hero%20Images/agilemultipleteams.jpg","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":2840,"description":2841,"authors":2846,"heroImage":2842,"date":2847,"body":2848,"category":14,"tags":2849},[1635],"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",[1447,974,806,1255],{"slug":2851,"featured":6,"template":681},"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":2857,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2858,"content":2864,"config":2869,"_id":2871,"_type":17,"title":2872,"_source":18,"_file":2873,"_stem":2874,"_extension":21},"/en-us/blog/making-builds-faster-autoscaling-runners",{"title":2859,"description":2860,"ogTitle":2859,"ogDescription":2860,"noIndex":6,"ogImage":2861,"ogUrl":2862,"ogSiteName":667,"ogType":668,"canonicalUrls":2862,"schema":2863},"How to make builds faster","How GitLab uses autoscaling to reduce build times and make developers happy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673173/Blog/Hero%20Images/autoscaling-balance.jpg","https://about.gitlab.com/blog/making-builds-faster-autoscaling-runners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to make builds faster\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-08-21\",\n      }",{"title":2859,"description":2860,"authors":2865,"heroImage":2861,"date":2866,"body":2867,"category":14,"tags":2868},[1483],"2019-08-21","\nPicture this: It’s 5:30 pm on a Friday and a project manager has an urgent request. A\nbug is affecting a group of customers and it needs to be fixed ASAP. You find the discrepancy\nand, _phew_, it looks like it’s going to be a relatively easy fix. You make the update and\nstart the CI pipeline… and then you wait… and wait. Two hours later, you’re still waiting. What was\nsupposed to be a quick fix has turned into another long night sitting in a queue.\n\n[The team at Ticketmaster](/blog/continuous-integration-ticketmaster/) certainly felt the\npain with their Jenkins pipelines, and many [DevOps](/topics/devops/) teams are all too familiar with sluggish CI.\n\nSlow builds hinder development speed. Plus – they’re annoying. It’s just one more thing developers\nhave to deal with in order to do their jobs. Organizations might dedicate more servers to process\nthese builds in an effort to solve the problem, but often that creates more problems. More servers\nmean higher cloud and computing costs. When it comes to long builds, many developers have\nresigned themselves to just “grin and bear it.”\n\n## Making builds _faster_\n\n[Continuous integration](/features/continuous-integration/) allows you to run a number of tasks as you\nprepare to deploy your software, like building a software package or running tests. These tasks\nneed to be run by something. At GitLab we call these task enablers runners, though other [CI tools](/features/continuous-integration/) call them\nagents. Runners are an application that processes builds: If all of these runners are in use, work\nis queued until one becomes available. Let's say your peak usage is 100 jobs, but your average\nusage is around 25 jobs. You have to decide how many servers to provision. If you go with the\naverage, you will have to wait during peak usage times. So why not just add more runners? Some\nservices actually charge for each of these virtual machines, and if you’re not using them all\nthe time, those costs can add up. If you're on a cloud infrastructure, you're paying for that\nserver time – even when it's not doing anything.\n\nFor ops teams, it’s been a never-ending balancing act of having the right amount of runners\nfor the right amount of work. But tasks don’t happen in a vacuum – every team has slow times\nand busier times that are unpredictable.\n\nNobody likes waiting. With this universal truth in mind, we introduced autoscaling to GitLab Runners.\n\n## What are autoscaling runners?\n\nAutoscaling gives teams the ability to utilize resources in a more elastic and dynamic way. What\nthis means is that our runners can be configured so that machines are created _on demand_.\nThose machines, after the job is finished, can wait to run the next jobs or be removed automatically.\nYou can even specify the `IdleTime` of a server before it shuts off. Once runners are set up to\nautoscale, your infrastructure contains only enough capacity to handle the load.\n\nAutoscaling runners ensure builds can be processed more efficiently and you aren’t paying for\nmore machines than you need. Developers can focus on their code instead of worrying about\ntheir infrastructure environment, and ops teams no longer have to moonlight as soothsayers.\n\nThe only thing you need to take advantage of autoscaling is one GitLab instance and\none [GitLab Runner](https://docs.gitlab.com/runner#features) that can be installed for free.\nOur runner is written in Go and can run on any platform where you can build Go binaries\nincluding Linux, macOS, Windows, FreeBSD, and Docker.\n\nSee how the team at [Substrakt Health](https://substrakthealth.com/) set up an autoscaling\ncluster of GitLab CI/CD runners using Docker-Machine and AWS – and saved 90% on EC2 costs in the process.\n\n[Read their story.](/blog/autoscale-ci-runners/)\n{: .alert .alert-gitlab-purple .text-center}\n\nSpeed and efficiency are important cornerstones of effective DevOps, so waiting for builds has\nalways felt like a step backward. As everyone strives to deploy more software, it seems only right\nthat your architecture be up for the task. Autoscaling runners let DevOps teams focus on what\nthey do best: Deploying better, faster software (yes, even on a Friday).\n\nPhoto by [Austin Neill](https://unsplash.com/@arstyy?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[110,995,806],{"slug":2870,"featured":6,"template":681},"making-builds-faster-autoscaling-runners","content:en-us:blog:making-builds-faster-autoscaling-runners.yml","Making Builds Faster Autoscaling Runners","en-us/blog/making-builds-faster-autoscaling-runners.yml","en-us/blog/making-builds-faster-autoscaling-runners",{"_path":2876,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2877,"content":2883,"config":2888,"_id":2890,"_type":17,"title":2891,"_source":18,"_file":2892,"_stem":2893,"_extension":21},"/en-us/blog/agile-pairing-sessions",{"title":2878,"description":2879,"ogTitle":2878,"ogDescription":2879,"noIndex":6,"ogImage":2880,"ogUrl":2881,"ogSiteName":667,"ogType":668,"canonicalUrls":2881,"schema":2882},"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":2878,"description":2879,"authors":2884,"heroImage":2880,"date":2885,"body":2886,"category":14,"tags":2887},[1635],"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",[1447,974,806,1255],{"slug":2889,"featured":6,"template":681},"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":2895,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2896,"content":2902,"config":2907,"_id":2909,"_type":17,"title":2910,"_source":18,"_file":2911,"_stem":2912,"_extension":21},"/en-us/blog/get-started-compliance-as-code",{"title":2897,"description":2898,"ogTitle":2897,"ogDescription":2898,"noIndex":6,"ogImage":2899,"ogUrl":2900,"ogSiteName":667,"ogType":668,"canonicalUrls":2900,"schema":2901},"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":2897,"description":2898,"authors":2903,"heroImage":2899,"date":2904,"body":2905,"category":14,"tags":2906},[1985],"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",[974,1115,806,894,935,1255],{"slug":2908,"featured":6,"template":681},"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":2914,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2915,"content":2921,"config":2927,"_id":2929,"_type":17,"title":2930,"_source":18,"_file":2931,"_stem":2932,"_extension":21},"/en-us/blog/all-remote-fundraising",{"title":2916,"description":2917,"ogTitle":2916,"ogDescription":2917,"noIndex":6,"ogImage":2918,"ogUrl":2919,"ogSiteName":667,"ogType":668,"canonicalUrls":2919,"schema":2920},"How to raise funds as an all-remote startup","GitLab CEO Sid Sijbrandij and podcast host Maren Kate unpack why venture firms struggle to fund all-remote startups.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673152/Blog/Hero%20Images/remotefundraisinghurdle.jpg","https://about.gitlab.com/blog/all-remote-fundraising","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to raise funds as an all-remote startup\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-08-16\",\n      }",{"title":2916,"description":2917,"authors":2922,"heroImage":2918,"date":2923,"body":2924,"category":14,"tags":2925},[890],"2019-08-16","\nIt’s possible to be an all-remote startup and get venture capital – GitLab is proof of that – but that doesn’t mean it’s easy. GitLab CEO [Sid Sijbrandij](/company/team/#sytses) spoke with [Maren Kate](https://www.linkedin.com/in/marenkate), host of the From 5 to 50 podcast, about why venture capitalists don’t love all-remote companies and how to work around that challenge. The [Remote AF](https://podcasts.apple.com/us/podcast/gitlab-raised-$100m-got-valued-at-over-billion-by-starting/id1467214647?i=1000444691471) podcast is aimed at startups looking to scale their companies from 5 to 50 employees and beyond.\n\nMaren starts by asking Sid how the concept of all-remote was received by the venture capital community. Sid’s response: “They don’t like remote. We missed out on investors because we are remote. We have skepticism from investors because we are remote.”\n\n## Stages of fundraising\n\nFundraising changes as a company grows, and it gets easier with time, Sid explains. “In the beginning they assess your team, then they assess your product, and then they assess your financials.” That’s why it can be hard for a newly-minted, all-remote startup to get fundraising traction in the early stages, he says. “When it comes to the team, they’re super skeptical they will be able to create something with all-remote. Then when it’s about the product they say, ‘Yes, maybe, but what about scaling?’ And then when it’s about the financials you can let the numbers speak for themselves so it’s less of a concern.”\n\nAnd in the early days of GitLab, even Sid was skeptical enough about all-remote to open an office. That office made our [series A financing](/blog/gitlab-announces-4m-series-a-funding-from-khosla-ventures/) easier, he says. But Sid soon realized that people weren’t coming into the office (San Francisco Bay Area traffic being what it is) so committed to an [all-remote philosophy](/company/culture/all-remote/). That decision made [series B fundraising efforts](/blog/gitlab-master-plan/) difficult. Some investors just said no to GitLab, but a few at least asked for an explanation. Even after an explanation, many remained dubious and in the end it took an enthusiastic VC who’d actually stayed up late reading through the handbook and vouched for GitLab to seal the deal.\n\n>Some of the best ideas are the least plausible.\n\nAll-remote companies are getting a toehold today, Sid offers, pointing to [InVision](/blog/pyb-all-remote-mark-frein/), WordPress, and Zapier. But there are still some factors that can inhibit fundraising options. “If we were to be acquired there’s probably a 50% discount, because for the acquiring company it’s so hard to bring people over to their headquarters,” Sid says. “Since an acquisition is the most likely outcome (for most startups), if you raise venture capital that depresses the evaluation you will get.”\n\n## Has co-location hit the wall?\n\nOn the upside, though, Sid thinks the limits of co-location are being made very clear. “Investors in San Francisco are all battling it out. They’re saying ‘Our portfolio companies are getting outbid by Google, by eBay, by Airbnb for engineering talent.’ Retention is an enormous problem at these companies. So they don’t like remote yet, but they’re starting to sour on the co-located model and all the disadvantages.”\n\nAnd while the all-remote path might be tough, Sid continues to stress the benefits to startups. “Remote offers you much easier hiring and scaling. Remote forces you to do the things you should be doing anyway, but you do them sooner.”\n\nAt the end of the day, Maren wonders whether some unconscious bias is at play. “If you see someone in an office, it makes them more successful,” she says, “but it’s not really that, it’s just human instinct.”\n\nSid agrees, and then adds perhaps the strongest argument in favor of all-remote – co-location can have a very dampening effect on innovation. “There's a lot of detrimental things that happen because some of the best ideas are the least plausible, like run an illegal taxi service, have people rent out their own home to strangers, or start competing with GitHub. And if you co-locate people, they're going to have to tell everyone what they do. And when they see people frowning, they're going to switch to something more plausible. And that's what you want to prevent.”\n\nListen to the whole conversation [here](https://podcasts.apple.com/us/podcast/gitlab-raised-$100m-got-valued-at-over-billion-by-starting/id1467214647?i=1000444691471).\n\nCover image by [Pau Casals](https://unsplash.com/@paucasals) on [Unsplash](https://unsplash.com)\n{: .note}\n",[676,785,2926],"startups",{"slug":2928,"featured":6,"template":681},"all-remote-fundraising","content:en-us:blog:all-remote-fundraising.yml","All Remote Fundraising","en-us/blog/all-remote-fundraising.yml","en-us/blog/all-remote-fundraising",{"_path":2934,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2935,"content":2941,"config":2946,"_id":2948,"_type":17,"title":2949,"_source":18,"_file":2950,"_stem":2951,"_extension":21},"/en-us/blog/agile-best-practices",{"title":2936,"description":2937,"ogTitle":2936,"ogDescription":2937,"noIndex":6,"ogImage":2938,"ogUrl":2939,"ogSiteName":667,"ogType":668,"canonicalUrls":2939,"schema":2940},"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":2936,"description":2937,"authors":2942,"heroImage":2938,"date":2943,"body":2944,"category":14,"tags":2945},[1635],"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](/features/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",[1447,974,806,1255],{"slug":2947,"featured":6,"template":681},"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":2953,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2954,"content":2960,"config":2965,"_id":2967,"_type":17,"title":2968,"_source":18,"_file":2969,"_stem":2970,"_extension":21},"/en-us/blog/developer-intro-sast-dast",{"title":2955,"description":2956,"ogTitle":2955,"ogDescription":2956,"noIndex":6,"ogImage":2957,"ogUrl":2958,"ogSiteName":667,"ogType":668,"canonicalUrls":2958,"schema":2959},"Why you need static and dynamic application security testing in your development workflows","Bolster your code quality with static and dynamic application security testing. Learn why you need SAST and DAST for your projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680714/Blog/Hero%20Images/intro-developer-sast-dast.jpg","https://about.gitlab.com/blog/developer-intro-sast-dast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why you need static and dynamic application security testing in your development workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-08-12\",\n      }",{"title":2955,"description":2956,"authors":2961,"heroImage":2957,"date":2962,"body":2963,"category":14,"tags":2964},[1985],"2019-08-12","\n\nDevOps is a quickly growing practice for companies in almost every market. With\nthe influx of cyber attacks over the past decade, security has slowly crept\nforward in the SDLC to the point where we’re now hearing the term [DevSecOps](/blog/announcing-gitlab-devsecops/) in developer circles.\n\nTo keep things tidy and help developers manage additional security\nresponsibilities, tools for static and dynamic [application security](/topics/devsecops/) testing\n(SAST and DAST) have made their way into the fray. In this post, we’ll\nexplain what SAST and DAST are, how they fit into developers’ workflows, and\nwhen they should be used.\n\n## What is application security testing (AST)?\n\nApplication security testing (AST) refers to the process of testing code to make sure it is free of vulnerabilities. There are many ways to test code, though static application security testing (SAST) and dynamic application security testing (DAST) are two of the more well-known options. \n\nApplication security testing has traditionally been a manual (and time-consuming) process, but the growing popularity of DevOps and the risk of insecure code have driven the majority of development teams to automate at least some of the processes. These days, most organizations use a variety of security testing tools to complete AST.\n \n## What are SAST and DAST?\n\nWhat are SAST and DAST? As previously mentioned, under the AST umbrella, there live two different security testing approaches: SAST and DAST. Though different, neither is better than the other and the security \ntesting outcome is superior when both are used together to detect security vulnerabilities in web applications and source code. SAST is a security testing approach that is performed on the application's code, while DAST is an approach that is performed on the running application. Both SAST and DAST are \nessential components of a comprehensive security testing strategy for software applications.\n\nIn summary, SAST and DAST help to ensure that computer systems are both safe and secure. These security measures help make sure that information is protected from hackers and other people who may try to steal it. They are critical tools for successful DevSecOps. Each runs a set\nof automated tests, and both introduce security at the beginning of the\nsoftware development lifecycle.\n\n### Static application security testing (SAST)\n\n[SAST](https://docs.gitlab.com/ee/user/application_security/sast/) can\nbe used to analyze source code for known vulnerabilities – and is also a type\nof white box testing. The test will run before your code is deployed, ensuring\nthat developers are alerted to fixes during the development phase.\nSAST can help remediate situations where your code has a potentially dangerous\nattribute in a class or unsafe code that can lead to unintended code execution.\n\n![An example of a SAST summary within a GitLab merge request](https://about.gitlab.com/images/secure/sast.png){: .shadow.medium.center}\n\nWithin GitLab, SAST will automatically generate a summary of fixes and unresolved\nvulnerabilities following every code commit, but before your code is merged to the target\nbranch. Tools that allow SAST reports to sit within the developer’s work\ninterface enable ease of remediation and streamline testing procedures within\nthe development phase.\n\nSAST takes an inside-looking-out approach, looking for security problems that might have been missed during source code development. It is effective when used after development is complete but before the finished project (and any missed security vulnerabilities) is deployed. Lots of developers nowadays integrate SAST testing into their CI/CD pipelines.\n\n### Dynamic application security testing (DAST)\n\n[DAST](https://docs.gitlab.com/ee/user/application_security/dast/), a\ntype of black box testing, analyzes your running web applications or known\nruntime vulnerabilities. GitLab’s DAST tool runs live attacks on a review app\nduring QA, meaning developers can iterate on new apps and updates earlier and\nfaster.\n\nAs with SAST, DAST should auto-run so that the developer doesn’t have to take measures to initiate the test. In other situations, DAST can also be used to\ncontinuously monitor live web applications for issues like cross-site scripting\nor broken authentication flaws. Test results should inform developers of\npotential vulnerabilities and serve as a catalyst for ongoing updates.\n\nDAST tools help you see your web application through the eyes of a hacker in a deployed environment. It constantly scans for security vulnerabilities during web application runtime, as well as checking the other API or web services that your application connects to. This makes DAST excellent for testing your complete IT environment where your application or web services run.\n\n## Test early and often using SAST and DAST\n\nStatic and dynamic application security testing are two helpful tools to keep\nyour code secure, but don’t rely on them to handle all of your security needs.\nIt’s still important to do manual code reviews, test high-level behaviors and\nfunctionality, conduct database scanning, and ensure that your whole team is\noperating with a security-first mindset.\n\nCover image by [Mikael Kristenson](https://unsplash.com/@mikael_k?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\non [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[935,894,110],{"slug":2966,"featured":6,"template":681},"developer-intro-sast-dast","content:en-us:blog:developer-intro-sast-dast.yml","Developer Intro Sast Dast","en-us/blog/developer-intro-sast-dast.yml","en-us/blog/developer-intro-sast-dast",{"_path":2972,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2973,"content":2979,"config":2984,"_id":2986,"_type":17,"title":2987,"_source":18,"_file":2988,"_stem":2989,"_extension":21},"/en-us/blog/built-in-ci-cd-version-control-secret",{"title":2974,"description":2975,"ogTitle":2974,"ogDescription":2975,"noIndex":6,"ogImage":2976,"ogUrl":2977,"ogSiteName":667,"ogType":668,"canonicalUrls":2977,"schema":2978},"The market figured out GitLab’s secret","Why we decided to combine version control with CI, and the rise of the single application.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663648/Blog/Hero%20Images/gitlab-joins-cd-foundation.jpg","https://about.gitlab.com/blog/built-in-ci-cd-version-control-secret","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The market figured out GitLab’s secret\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2019-08-08\",\n      }",{"title":2974,"description":2975,"authors":2980,"heroImage":2976,"date":2981,"body":2982,"category":14,"tags":2983},[911],"2019-08-08","\n\nThere’s a movement in the DevOps industry and the world right now: to do more in a simple way that inspires us to innovate. GitLab started this trend in the DevOps space by simplifying the delivery of code by combining GitLab CI and [GitLab version control](/topics/version-control/). We didn't originally buy into the idea that this was the right way to do things, but it became our secret capability that we’ve doubled down on.\n\n## Let’s combine applications\n\nThe story starts with [Kamil Trzciński](/company/team/#ayufanpl), now a distinguished engineer at GitLab. Soon after Kamil came to work for GitLab full time, he began talking with me and my co-founder, [Dmitriy Zaporozhets](/company/team/#dzaporozhets), suggesting that we bring our two projects together – GitLab Version Control and GitLab CI, making it into one application. Dmitriy didn’t think it was a good idea. GitLab version control and CI were already perfectly integrated with single sign-on and APIs that fit like a glove. He thought that combining them would make GitLab a monolith of an application, that it would be disastrous for our code quality, and an unfortunate user experience. After time though, Dmitriy started to think it was the right idea as it would deliver a seamless experience for developers to deliver code quickly.\n\nAfter Dmitriy was convinced, they came to me. I also didn’t think it was a good idea. At the time I believed we needed to have tools that are composable and that could integrate with other tools, in line with the Unix philosophy. Kamil convinced me to think about the efficiencies of having a single application.\n\n>“Well, if you don’t believe that it’s better for a user, at least believe it’s more efficient for us, because we only have to release one application instead of two. Efficiency is in our values.” - Kamil Trzcinski, distinguished engineer at GitLab\n\n## Realizing the future of DevOps is a single application\n\nThat made sense to me and I no longer stood in their way. The two projects merged and the results were beyond my expectations. The efficiencies that were so appealing to us, also made it appealing to our customers. We realized we stumbled on a big secret because nobody believed that the two combined together would be a better way of continuously delivering code to market. We doubled down on this philosophy and we started doing [continuous delivery](/topics/continuous-delivery/).\n\nFrom that day on, I saw the value of having a single application. For example, a new feature we are implementing is auto-remediation. When a vulnerability comes out, say a heart bleed, GitLab will automatically detect where in your codebase that vulnerability exists, update the dependency, and deliver it to your production environment. This level of automation would be hard to implement without being in a single application. By combining the projects we unified teams – helping them realize the original intent of DevOps – and that is magical to see.\n\n## The market validates our secret\n\nAnd while we bet on this philosophy the industry is now seeing it as well. In September of 2015 we [combined GitLab CI and GitLab version control](/releases/2015/09/22/gitlab-8-0-released/) to create a single application. By March of 2017, Bitbucket also realized the advantages of this architecture and [released Pipelines as a built-in part of Bitbucket](https://dzone.com/articles/bitbucket-adds-pipelines). In 2018, [GitHub announced Actions](https://techcrunch.com/2018/10/16/github-launches-actions-its-workflow-automation-tool/) with CI-like functionality built into a single application offering. In the last six months, [JFrog acquired Shippable](https://techcrunch.com/2019/02/21/jfrog-acquires-shippable-adding-continuous-integration-and-delivery-to-its-devops-platform/) and [Idera acquired Travis CI](https://hub.packtpub.com/idera-acquires-travis-ci-the-open-source-continuous-integration-solution/), showing a consolidation of the DevOps market and a focus on CI. The market is validating what we continually hear from our users and customers: that a simple, single DevOps application meets their needs better.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/MNxkyLrA5Aw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWe hope you will continue to join us in our effort to bring teams together to innovate. [Everyone can contribute](/company/mission/#mission) here at GitLab and as always, we value your feedback, thoughts, and contributions.\n\nWant to hear me talk through the origin story? Listen to the [Software Engineering Daily podcast](https://softwareengineeringdaily.com/2019/03/15/gitlab-with-sid-sijbrandij/) where I talk about combining GitLab CI and GitLab Version Control.\n",[110,806],{"slug":2985,"featured":6,"template":681},"built-in-ci-cd-version-control-secret","content:en-us:blog:built-in-ci-cd-version-control-secret.yml","Built In Ci Cd Version Control Secret","en-us/blog/built-in-ci-cd-version-control-secret.yml","en-us/blog/built-in-ci-cd-version-control-secret",{"_path":2991,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2992,"content":2998,"config":3004,"_id":3006,"_type":17,"title":3007,"_source":18,"_file":3008,"_stem":3009,"_extension":21},"/en-us/blog/navigation-state-of-play",{"title":2993,"description":2994,"ogTitle":2993,"ogDescription":2994,"noIndex":6,"ogImage":2995,"ogUrl":2996,"ogSiteName":667,"ogType":668,"canonicalUrls":2996,"schema":2997},"Explore the past, present, and future of GitLab's Navigation design","Dive into the history of GitLab's navigation design and learn how GitLab's UX department is making incremental improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678236/Blog/Hero%20Images/navigation.jpg","https://about.gitlab.com/blog/navigation-state-of-play","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Explore the past, present, and future of GitLab's Navigation design\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Katherine Okpara\"}],\n        \"datePublished\": \"2019-07-31\",\n      }",{"title":2993,"description":2994,"authors":2999,"heroImage":2995,"date":3001,"body":3002,"category":14,"tags":3003},[3000],"Katherine Okpara","2019-07-31","\nAs a UX department, we are responsible for creating navigational structures that are intuitive,\nin tune with user needs, and representative of the numerous workflows of our community of users.\nHowever, when designing for the needs of so many different people, we often have to make compromises\nand not everyone is pleased with the result. Navigation is not just about getting from point A to\nB; it can shape workflows, empower users to discover new, more efficient ways of working, and\nultimately determine how comfortable users are with a product. From the moment users log in for\nthe first time to when they start diving deeper into GitLab’s diverse feature set, our navigation\nstructure is critical for shaping the user's path and, ultimately, their success in using GitLab.\n\n### Why does this matter?\nOur UX Research team is always concerned with investigating and advocating for the needs of all\nGitLab users. We have a [history of research](https://gitlab.com/gitlab-org/uxr_insights/blob/master/Navigation-Research-Summary.md)\nthat has resulted in incremental improvements to GitLab’s navigation over time. After gathering\nfeedback from many sources over the years, we are excited to lead a strategic, dedicated\ninitiative to improve GitLab’s navigation. As part of this initiative, we will consider the\ngoals and frustrations of all users and assess the experiences shaped by the most common workflows\nthroughout GitLab. We will continue to gather feedback from our product users, customers, and\ninternal stakeholders as a way to identify key opportunities for improvement.\n\n### History of GitLab's navigation\nBefore we outline our future research and design plans, let’s take a look back and understand GitLab’s\nnavigation design journey.\n\n![Original design](https://i.imgur.com/9oZq3de.png){: .medium.center}\n\nGitLab's original design\n{: .note.text-center}\n\nThere are two ways to navigate throughout GitLab: globally and contextually. Global navigation refers\nto elements that are always available (e.g., browsing between groups and projects using the top navigation bar).\nContextual navigation refers to the elements that change based on the page a user is viewing.\nBalancing these levels of navigation has consistently been one of the top challenges in each\nphase of GitLab’s navigation design.\n\nIn a [June 2016 blog post describing the pain points that led to\nGitLab’s first navigation redesign](/blog/navigation-redesign/), [Dmitriy Zaporozhets](/company/team/#dzaporozhets),\nGitLab’s co-founder and engineering fellow, stated the following as reasons why GitLab’s UI did not\nwork very well:\n\n- *The current navigation is not well organized. There are places where it does not follow logic or best practices.*\n- *We cannot use muscle memory with the collapsed menu sidebar for fast click on links because the menu has too many items, with new ones added every once in a while.*\n- *It's hard to navigate when you come to GitLab via a link from another app (like chat, for example) because of the lack of a logical hierarchy in our UI navigation.*\n\nTo address these pain points, Dmitriy worked with GitLab’s UX designer to iterate through proposed\nchanges. They landed on a navigation design that introduced a dark-colored, collapsible left\nsidebar to house global navigation elements, along with a contextual top navigation that changed\nrelative to pages the user visited in GitLab.\n\n| Group-level navigation | Project-level navigation|\n|------------------------|-------------------------|\n|![Group level](https://i.imgur.com/HD7ElxQ.png){: .shadow}| ![Project level](https://i.imgur.com/w04Zq6D.png){: .shadow} |\n\nAfter this redesign, the team continued to iterate and make incremental changes to the navigation.\nThese changes became more significant when the option to “pin” (to the screen) or “unpin” the left\nsidebar was introduced. “Pinning” would keep the sidebar static while “unpinning” would remove\nit from the screen and place it under a hamburger menu icon. There were more unfavorable reactions\nto the changes after [GitLab’s 9.0 release](/releases/2017/03/22/gitlab-9-0-released/#updated-navigation-ce-ees-eep),\nwhen the [left sidebar was converted into a dropdown](https://gitlab.com/gitlab-org/gitlab-ce/issues/26200)\nfor all users, permanently placed in a hamburger menu at the far left of the top navigation bar.\n\n| \"Pinned\" | \"Unpinned\" |\n|----------|------------|\n| ![Pinned](https://i.imgur.com/IMYn45r.png){: .shadow} | ![Unpinned](https://i.imgur.com/Jag1HeG.png){: .shadow} |\n\nAfter receiving this feedback, our UX team conducted additional rounds of usability testing and [in\n2017 we made significant improvements to the navigation](/blog/redesigning-gitlabs-navigation/).\nThe decision to reorganize the structure of global and contextual content was one of the more prominent changes.\nGlobal navigation elements would now exist in the top navigation while contextual navigation elements\nwould exist in the left sidebar. These changes were first implemented behind a feature flag, to give\nusers a chance to try out the new flow and tell us how they felt about it. We created\na [feedback issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917) so users could discuss\ntheir experiences and share their likes and dislikes in an open, collaborative space.\n\nThe feedback issue led to additional improvements and highlighted more opportunities to optimize\nGitLab’s navigation. Our design team used this feedback to iterate for two release cycles and\nidentify changes that would bring the most benefit, such as\n[flyout menus in the left sidebar](https://gitlab.com/gitlab-org/gitlab-ce/issues/34026)\nand [improvements to breadcrumbs](https://gitlab.com/gitlab-org/gitlab-ce/issues/35269).\nIn September 2017, [GitLab’s navigation redesign became official](/blog/unveiling-gitlabs-new-navigation/)\nand turned on for all users.\n\n![2017 redesign](https://i.imgur.com/ovRRBwE.png){: .shadow.medium.center}\n\nOur 2017 redesign\n{: .note.text-center}\n\nGitLab’s navigation design has not drastically changed since the 2017 redesign, aside\nfrom incremental changes made when adding new feature links to the left sidebar and the\nintroduction of instance-wide workflows. However, even with all of these notable improvements,\nsome users are still confused by finding their way around GitLab, especially when interacting\nwith the left sidebar. Many users have unique workflows based on the features they use, companies\nthey work with, and the amount of time they’ve been using GitLab. As a result, even design decisions\nthat are informed and supported by research can receive negative feedback from those who are\nimpacted by the changes.\n\nEven in 2019, our users describe usability issues that reflect the pain points described in our\nfirst navigation redesign blog post. Presently, a large portion of the pain points can be attributed to\nGitLab’s rapid growth and increased focus on\n[shipping features for the entire DevOps lifecycle](/stages-devops-lifecycle/). As the product\ncontinues to grow, users who only interact with specific features can become overwhelmed by all\nof the information and paths available in the interface. In order to avoid a future pattern\nof frequent changes to the navigation structure, we need to create a systematic approach for\naddressing the diverse use cases that come along with a rapidly growing product.\n\n### What we've learned\n\nThe outcome of all of the research we have conducted over the years is an understanding of the\ncore pain points and usability issues users face when navigating throughout GitLab. I believe that\nthe main themes of our research initiative should be **context** and **discoverability**.\n\n- **Context:** How can we help users maintain context and stay oriented while switching between levels\nof navigation and features in different product stages?\n\n- **Discoverability:** How can navigation be a method of promotion and discovery for new features\nwhile still preserving the findability of commonly used features?\n\nThese two themes are important for creating a systematic approach to organizing content in GitLab's UI.\nWe've had [internal discussions](https://gitlab.com/gitlab-org/ux-research/issues/108) around aligning\nGitLab's UI with [our DevOps stages](/handbook/product/categories/#devops-stages) to categorize\ncontent in a way that reflects the evolution of our product and organization. However, the findings\nfrom [a series of research studies](https://gitlab.com/groups/gitlab-org/-/epics/1236) cautioned us\nagainst moving in that direction, to prevent a negative impact on findability and confusion in users\nwho are not familiar with GitLab's DevOps stages.\n\nWhile it may be possible to teach users about the DevOps stages over time, the feedback from this\nresearch showed us that the additional layers of sub-navigation could make navigation a more\ncumbersome experience. Additionally, some of the names of the DevOps stages are broad and not\nimmediately descriptive (e.g., “Manage” and “Create”). This may require users to do more guesswork\nto understand the variety of features that could fall under each stage. Our upcoming research\ninitiative provides us with the opportunity to explore how we can build an intuitive, logical\nsystem for categorizing new features and guiding users through tasks that cross multiple product stages.\n\nTo read more about the key findings from our prior navigation research, please visit\nthe [UX research insights repository](https://gitlab.com/groups/gitlab-org/-/epics/1555) for a summary of\nour research.\n\n## What comes next?\nWe will investigate the paths that users take throughout GitLab and consider how we should balance\nthe needs of users who have contrasting team sizes, roles, and product tiers. Our goal is to find ways\nto align with the principle of [convention over configuration](/handbook/product/product-principles/#convention-over-configuration)\nwhile still addressing the diverse needs of our users. Please see\nthe [navigation research initiative epic](https://gitlab.com/groups/gitlab-org/-/epics/1342) for more information.\n\nThis research initiative will be conducted in the following phases:\n\n1. [Stakeholder interviews](https://gitlab.com/gitlab-org/ux-research/issues/211): Understand what\ninternal stakeholders need and expect from the flow of GitLab's navigation, feature discoverability,\nand usability.\n2. [User interviews](https://gitlab.com/gitlab-org/ux-research/issues/236): Gather insight from GitLab\ncustomers about their experiences navigating throughout GitLab, learning how to use the product, and\ndiscovering new features. Focus on use cases that cross\nmultiple DevOps stages.\n3. [Explore and assess key user journeys](https://gitlab.com/gitlab-org/ux-research/issues/221): Work with\nGitLab product designers to document the common paths and tasks\nour [user personas](/handbook/product/personas/#user-personas) complete,\nhighlighting usability issues and ranking them by severity.\n3. [Share UX research recommendations](https://gitlab.com/gitlab-org/ux-research/issues/222): Recommended\nchanges based on information architecture best practices and feedback from users and\nstakeholders. Share results with Product and UX teams, discuss solutions, and outline next steps.\n\n### We need your help!\nIf you could wave a magic wand, what would be your ideal vision for GitLab’s navigation?\n\nPlease share your top pain points, suggestions for improvement, or things you like about GitLab's\nnavigation design in the comments below!\n",[676,677,701],{"slug":3005,"featured":6,"template":681},"navigation-state-of-play","content:en-us:blog:navigation-state-of-play.yml","Navigation State Of Play","en-us/blog/navigation-state-of-play.yml","en-us/blog/navigation-state-of-play",{"_path":3011,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3012,"content":3018,"config":3023,"_id":3025,"_type":17,"title":3026,"_source":18,"_file":3027,"_stem":3028,"_extension":21},"/en-us/blog/three-teams-left-jenkins-heres-why",{"title":3013,"description":3014,"ogTitle":3013,"ogDescription":3014,"noIndex":6,"ogImage":3015,"ogUrl":3016,"ogSiteName":667,"ogType":668,"canonicalUrls":3016,"schema":3017},"3 Teams left Jenkins: Here’s why","How three different teams – Alteryx, ANWB, and EAB – shifted away from Jenkins for smoother sailing with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671932/Blog/Hero%20Images/jenkins-to-gitlab-sailboat.jpg","https://about.gitlab.com/blog/three-teams-left-jenkins-heres-why","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 Teams left Jenkins: Here’s why\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2019-07-23\",\n      }",{"title":3013,"description":3014,"authors":3019,"heroImage":3015,"date":3020,"body":3021,"category":14,"tags":3022},[2386],"2019-07-23","\nAs many companies know, continuous integration and build processes are challenging. Complex tool\nintegrations, pieced-together pipelines, and overall system breakdowns are time consuming for\neven the most experienced teams. The longer it takes for system recovery, the more costly it\nbecomes, creating more risk for the organization as a whole. Competitive companies are always on\nthe lookout for better solutions and they're increasingly turning to GitLab to do just that.\n\nThree companies – Alteryx, ANWB, and EAB – all experienced unique challenges with Jenkins.\nWe highlight how each of these teams made the successful move to\n[GitLab from Jenkins](/solutions/jenkins/). Learn how each team\naccelerated deployment, improved CI/CD pipelines, created developer transparency, and\nalleviated toolchain stressors after making the switch to GitLab.\n\n## Alteryx: Builds down from 3 hours to 30 minutes\n\nAlteryx, a prominent end-to-end analytics platform, was using a legacy system with Jenkins\nthat was older, clunky, and difficult to manage. The team was looking to modernize their architecture\nand to improve their overall software development lifecycle.\n\nThey turned to GitLab because it offers many solutions in one tool. With GitLab, the Alteryx team is now\ncapable of managing source code, CI/CD, code reviews, and security scanning all in one place.\nA build that took three hours with Jenkins is now just 30 minutes in GitLab.\n\nAs Alteryx continues to grow in the analytics space, GitLab will continue to add new features\nto support the company's expanding needs. Learn more about [Alteryx’s journey](/customers/alteryx/).\n\n## ANWB: Increased deployments\n\nWith over 4.4 million members, ANWB offers services for credit cards, bicycle maintenance,\ncar sales, and travel throughout the Netherlands. Both the mobile and web development\nteams have their hands full with popular offerings like mapping and driver intelligence services.\n\nANWB was struggling with an outdated toolchain that included Jenkins version 1 as a build server.\nThe company wanted to speed up development, eliminate isolated and outdated processes and give\nits teams autonomy.\n\nWith GitLab, ANWB can now manage separate teams, increase deployments, and support a culture\nwhere everyone contributes freely to colleagues' code repositories. ANWB has plans to move toward a\ncloud-centric framework and GitLab has helped to pave that road. Learn more about [ANWB’s path to success](/customers/anwb/).\n\n## EAB: \"Quality first\" culture\n\nServing over 1,500 schools, colleges, and universities, EAB uses data analytics and transformative\nmeasures to help students stay enrolled in education. The EAB team had to rely on several tools,\nincluding Jenkins, which made continuous integration overly complex and time consuming.\nDevelopers wanted to consolidate their various tools to create faster builds with much less maintenance.\n\nEAB initially turned to GitLab because of our regular feature releases and [tiered (and affordable) pricing](/pricing/).\nThe EAB development team soon realized they could have a steady pace of\nbuild releases without having to use multiple tools to make it happen. In just six months, workflow increased\nand the company plans to continue to roll out a \"quality first\" culture using GitLab as a guide.\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nWatch the [Migrating from Jenkins to GitLab](https://www.youtube.com/watch?v=RlEVGOpYF5Y) demo\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 [Fab Lentz](https://unsplash.com/@fossy) on [Unsplash](https://unsplash.com)\n{: .note}\n",[1791,807,110],{"slug":3024,"featured":6,"template":681},"three-teams-left-jenkins-heres-why","content:en-us:blog:three-teams-left-jenkins-heres-why.yml","Three Teams Left Jenkins Heres Why","en-us/blog/three-teams-left-jenkins-heres-why.yml","en-us/blog/three-teams-left-jenkins-heres-why",{"_path":3030,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3031,"content":3036,"config":3041,"_id":3043,"_type":17,"title":3044,"_source":18,"_file":3045,"_stem":3046,"_extension":21},"/en-us/blog/concurrent-devops",{"title":3032,"description":3033,"ogTitle":3032,"ogDescription":3033,"noIndex":6,"ogImage":2976,"ogUrl":3034,"ogSiteName":667,"ogType":668,"canonicalUrls":3034,"schema":3035},"Making the case for \"concurrent DevOps\"","DevOps goes by a lot of different names, but we’ve settled on concurrent DevOps for now at least.","https://about.gitlab.com/blog/concurrent-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Making the case for \"concurrent DevOps\"\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-07-17\",\n      }",{"title":3032,"description":3033,"authors":3037,"heroImage":2976,"date":3038,"body":3039,"category":14,"tags":3040},[890],"2019-07-17","\nWhat’s in a name? Quite a lot, apparently, when it comes to the software development space. Over the last few years companies have come up with a number of different names to describe their DevOps efforts – BizDevOps, DevSecOps, and even “modern software development.” But here at GitLab we prefer the term “[concurrent DevOps](/topics/devops/).”\n\nTo explain the thought process behind our choice of concurrent DevOps and what it all might mean moving forward, GitLab CEO [Sid Sijbrandij](/company/team/#sytses) sat down with chief marketing officer [Todd Barr](/company/team/#tbarr) and corporate marketing senior director [Melissa Smolensky](/company/team/#melsmo). It’s safe to say [a healthy discussion ensued](https://www.youtube.com/watch?v=bDTYHGEIeM0).\n\n## Why “concurrent”?\n\n“In GitLab you’re not passing (code) along multiple stages,” explains Sid. “You don’t wait until something is ready and then send it off to some security testing. People can work in parallel. We call it concurrent because it can be parallel but it doesn't have to be.\"\n\nAnd concurrent DevOps stands out from what Sid calls “sequential DevOps.” Because no one is waiting for a handoff, or permission, everything goes faster, Sid offers. “I think concurrent DevOps could be a rallying cry,” he says. “If we can spread that idea, make it bigger than GitLab, it’s going to be easier for people to demand something like that and trust (us) with other solutions.”\n\n## Start with a mission (statement)\n\nBut Todd needs convincing that concurrent DevOps is the right term. “Concurrent DevOps isn’t really a category, it’s a benefit statement,” he says. He suggests a different approach, using our mission statement [“everyone can contribute”](/company/mission/#mission) as a starting point. “I think that has a lot of legs if we actually put more thought into what that means and what category that would mean if we’re creating a platform where everyone can contribute.”\n\n> Concurrent DevOps could be a rallying cry if we can spread that idea – make it bigger than GitLab\n\nSid agrees, in theory, that GitLab is creating a broader platform but doesn’t think the time is right, yet, to make that our main marketing message. “Yes, our visions are bigger. But if you’re too far ahead of where people think you are, you might fall flat on your face. If we can own DevOps I’d settle for that for the next few years.” Melissa agrees, pointing to the fact that enterprises still have a long way to go to integrate DevOps into their development lifecycles.\n\n## Size matters\n\nAnd there’s no question the DevOps market is sufficiently large to support GitLab’s growth, Sid says, referring to a report from Grand View Research that forecasts the market will be worth [nearly $13 billion in 2025](https://www.grandviewresearch.com/press-release/global-development-to-operations-devops-market). So the market opportunity is there, Todd agrees, and offers that both he and Melissa have been in the DevOps space so long they’ve sort of taken it for granted, which is why he suggested different terminology. “DevOps has become a term that's almost synonymous with future software lifecycle development,” he says. “But there's a people element that we've got to help people understand. With concurrent DevOps we're trying to be more inclusive in the process, or that's at least one benefit.”\n\nWe need to make the case that concurrent DevOps is better, Sid stresses, even if we eventually change the name later on. “Our big benefit is a single application for the entire DevOps lifecycle.”\n\n Watch the entire video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bDTYHGEIeM0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPhoto by [YIFEI CHEN](https://unsplash.com/photos/FPMRxKd7MxI?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/spiral-lights?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,676],{"slug":3042,"featured":6,"template":681},"concurrent-devops","content:en-us:blog:concurrent-devops.yml","Concurrent Devops","en-us/blog/concurrent-devops.yml","en-us/blog/concurrent-devops",{"_path":3048,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3049,"content":3055,"config":3060,"_id":3062,"_type":17,"title":3063,"_source":18,"_file":3064,"_stem":3065,"_extension":21},"/en-us/blog/third-party-code-risks",{"title":3050,"description":3051,"ogTitle":3050,"ogDescription":3051,"noIndex":6,"ogImage":3052,"ogUrl":3053,"ogSiteName":667,"ogType":668,"canonicalUrls":3053,"schema":3054},"4 Risks to consider when implementing third-party code","Third-party code is a great resource for businesses, but comes with a number of risks. Explore four ways developers can keep their code secure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680662/Blog/Hero%20Images/third-party-code-risks.jpg","https://about.gitlab.com/blog/third-party-code-risks","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 Risks to consider when implementing third-party code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-07-16\",\n      }",{"title":3050,"description":3051,"authors":3056,"heroImage":3052,"date":3057,"body":3058,"category":14,"tags":3059},[1985],"2019-07-16","\n\nManaging a complex ecosystem of software and partnerships is a fundamental need\nfor today’s businesses. Most enterprises run hundreds of mission-critical apps,\nmany of which are either out-of-the-box or customized third-party solutions.\nThe benefit of third-party software is clear: It saves time, resources, and\nallows you to implement new capabilities quickly, efficiently, and at scale.\n\nUnfortunately, with great reward comes some risk. Many of last year’s most\nsignificant breaches – like CSC, Best Buy, and Delta – were due to missed\nvulnerabilities in the company's third-party applications. For example, Best Buy suffered a breach\nvia their online chat service, [24]7.ai, [which had stored BestBuy customer\npayment data on its servers](https://www.pcmag.com/news/360306/best-buy-suffers-customer-payment-data-breach).\n\nBringing on new, third-party software can be an exciting step forward for your\nworkload and projects, allowing you to add new capabilities, build on the open source\ncommunity, and leverage some of the best code out there. However, each new\npartnership creates an opportunity for hackers to access your systems and\ndata. Even if your vendors claim to be secure, their code might not necessarily\nlive up to the security standards and compliance requirements of your business.\nDevelopers can’t leave all risk management up to their security counterparts;\ndevelopers need to share that responsibility just as they share responsibility\nfor writing their own secure code.\n\n## Risks developers should know about third-party code\n\n1. As Bogdan Rancea writes, open source code fragments are downloaded hundreds\nor thousands of times a day – [and not everyone is contributing secure code or\nmaintaining a secure code sharing system](https://ecommerce-platforms.com/articles/the-dangers-of-third-party-code-dependency).\nThe more complex the code, the easier it is for a few lines of malicious code\nto go undetected.\n1. Rigorous testing is often overlooked for third-party code. If third-party code touches your\ndata, it should be tested – but many businesses either don’t test or complete the\nbare minimum required by their compliance teams.\n1. Standard third-party script tracking is documented, but [there may be\nadditional tracking that isn’t disclosed](https://css-tricks.com/potential-dangers-of-third-party-javascript/).\nThese scripts may be collecting data across your website and apps, storing\npersonally identifiable information from your customers as they engage with your business.\n1. When a breach occurs, your brand will be held responsible. When your\ncustomers’ data is at stake, it doesn’t matter if the breach happens on\nthird-party soil; if it’s your data, it’s your problem.\n\n## Protect your company and customers by planning ahead\n\nWhile a breach may be inevitable, the disastrous aftermath isn’t. Proactive\nsecurity measures in third-party relationships can save your company a lot of\nheartache in the long run, and developers are well suited to lead the charge.\nHere are a few best practices to follow:\n\n### 1. Take inventory of all of your current third-party relationships\n\nBegin with where you are now: Create a list of every third-party program used across your\ncompany. Make sure you know what code is being used, who the contact person is\nboth internally and at the vendor (if applicable), and understand what data is\nbeing accessed or stored by the third party. You may choose to pursue security\nconversations and testing with certain vendors based on the classification of\nthe data they work with, making an inventory of third-party relationships a valuable tool to prioritize.\nOnce your inventory is complete, it may be useful to consider a third-party or\nopen source code audit to thoroughly investigate your code ecosystem.\n\n### 2. Work with security to create formal requirements for all new third parties\n\nEstablishing standards will allow your team to vet potential collaborators and\nensure that any new software or code isn’t posing an unnecessary risk to your\nbusiness. It will also help to serve as a requirements guide during the\nprocurement process and can mitigate internal conflict when trying to get new tools\napproved. If you’re unsure where to start, begin by looking at the\nrequirements of all the legal regulations that apply to your business, such as\nGDPR. You could also look at how the third-party code or tools will interact\nwith your data, systems, and software and create requirements based on what\nwill help you best protect the business.\n\n### 3. Take on a security mindset: It’s everyone’s responsibility\n\nWhen hackers are trying to find any possible way in, it’s important that your entire\norganization – not just the security department – feels responsible for and capable of\ncontributing to your company’s security posture. Widespread security awareness\nwill hopefully make security a priority whenever a team is evaluating a new\ntool or code fragment.\n\n### 4. Data encryption: Start your security practices with the data\n\nSet policies to protect data based on certain trigger actions – like the creation\nof data or external sharing – or based on the level of data sensitivity. By making\nencryption a standard practice across all systems, you’re adding a layer of\nsecurity that requires identity-based authentication, which can give insight to\nwho is accessing your data and when. Moreover, any stolen data will only be\nuseful to hackers if it can be decrypted.\n\nCover image by [Kelly Sikkema](https://unsplash.com/@kellysikkema?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/collections/4571277/programming?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[852,894],{"slug":3061,"featured":6,"template":681},"third-party-code-risks","content:en-us:blog:third-party-code-risks.yml","Third Party Code Risks","en-us/blog/third-party-code-risks.yml","en-us/blog/third-party-code-risks",{"_path":3067,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3068,"content":3074,"config":3079,"_id":3081,"_type":17,"title":3082,"_source":18,"_file":3083,"_stem":3084,"_extension":21},"/en-us/blog/global-developer-report",{"title":3069,"description":3070,"ogTitle":3069,"ogDescription":3070,"noIndex":6,"ogImage":3071,"ogUrl":3072,"ogSiteName":667,"ogType":668,"canonicalUrls":3072,"schema":3073},"2019 Global Developer Report: DevSecOps finds security roadblocks divide teams","Over 4,000 software professionals shared their DevOps experiences, helping us uncover what they require in order to innovate rapidly.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672611/Blog/Hero%20Images/2019-global-developer-report-blog.png","https://about.gitlab.com/blog/global-developer-report","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2019 Global Developer Report: DevSecOps finds security roadblocks divide teams\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-07-15\",\n      }",{"title":3069,"description":3070,"authors":3075,"heroImage":3071,"date":3076,"body":3077,"category":14,"tags":3078},[1635],"2019-07-15","\nWe have liftoff! The 2019 Global Developer Report: DevSecOps has arrived! Thanks to the 4,071 crew members – across various industries, roles, and geographic locations – we’ve uncovered what helps and hurts software professionals on the journey to bring developers, security professionals, and operations team members together.\n\nAccording to our survey respondents, the primary mission for all software professionals today is improvement.  Everyone wants more secure code, increased visibility, reduced cycle times, and continuous deployment, but how do teams get there? Based on our survey results, DevOps done right can help realize these goals. But DevOps itself can be challenging to implement, creating other difficulties.\n\nHere are a few key takeaways from the survey that might help you create a more nuanced and strategic DevOps flight plan for your organization.\n\n## Good DevOps: The answer to security problems?\n\nSecurity teams in a longstanding DevOps environment reported they are 3 times \nmore likely to discover bugs before code is merged and 90% more likely to test \nbetween 91% and 100% of code than teams who encounter early-stage DevOps. Nearly \nhalf of all mature DevOps respondents practiced continuous deployment in at least \nsome part of their organizations. But at the same time, only about a third of \nrespondents actually rated their organizations’ DevOps efforts as “good.”\n\n> “The big takeaway from this survey is that early adopters of strong DevOps \nmodels experience greater security and find it easier to innovate, but barriers \nstill prevent developers and security teams from achieving true DevSecOps,” said \nSid Sijbrandij, CEO and co-founder of GitLab. “Teams need a single solution that \ncan provide visibility into both sides of the process for streamlined deployment.”\n\nClearly challenges remain, and nowhere is that more obvious than in security. \nWhile 69% of developers indicate they’re expected to write secure code, nearly \nhalf of security pros surveyed (49%) said they struggle to get developers to make \nremediation of vulnerabilities a priority. And 68% of security professionals feel \nthat fewer than half of developers are able to spot security vulnerabilities \nlater in the lifecycle. Roughly half of security professionals said bugs were \nmost often found by them after code is merged in a test environment.\n\n![2019 Developer Report security findings](https://about.gitlab.com/images/blogimages/security-vulnerabilities.png){: .large.center}\n\n## Choosing DevOps\n\nMore companies are making the move to DevOps than before, and for good reason – \nteams that have successfully implemented a mature [DevOps model](/solutions/security-compliance/) experience major \nimprovements in their workflow. According to the survey, developers who work at \norganizations with immature DevOps models feel their processes inhibit them, \nwhile those who work with mature models are almost 1.5 times more likely to feel \ninnovative and 3 times more likely to discover security vulnerabilities earlier \non in the pipeline.\n\nPoor DevOps practices slow teams down. Those organizations are 2.5 times more \nlikely to encounter significant delays during the planning stage and 2.6 times \nmore likely to wade through red tape, slowing efforts to quickly fix security \nvulnerabilities.\n\n## Remote work works\n\nAccording to our survey respondents, working remotely leads to greater \ncollaboration, better documentation, and transparency. In fact, developers in a \nmostly remote environment are 23% more likely to have good insight into what \ncolleagues are working on and rate the maturity of their organization’s security \npractices 29% higher than those who work in a traditional office environment.\n\n## About the survey\n\nGitLab surveyed 4,071 software professionals across various industries, roles,\nand geographic locations. The margin of error is 2%, assuming a population size\nof 23 million software professionals and a 95% confidence level.\n\n## Methodology\n\nWe launched a Global Developer Survey on Jan. 23, 2019, collecting responses\nuntil Feb. 27, 2019. During that time, we promoted the survey primarily on GitLab’s\nsocial media channels and newsletter.\n\n### Frequently asked questions\n\n| -------- | -------- |\n| **How can I read the report?**   | You can [download the full report here](/developer-survey/).   |\n| **Are the raw results publicly available?**  | Yes, you can [view the raw data here](https://www.surveymonkey.com/results/SM-8LLKL2N87/).   |\n| **Did only GitLab users take the survey?** | No, it was open to all software professionals across various industries, roles, and geographic locations.  |\n| **How can I ask questions or give feedback about the survey and results?** | Please direct questions or comments about the survey to surveys@gitlab.com. |\n| **I’d like to participate in the next survey. Can I sign up for alerts?** | The best way to receive news about the Global Developer Survey is to [sign up for our bi-weekly newsletter](/company/preference-center/). |\n",[722,806,745],{"slug":3080,"featured":6,"template":681},"global-developer-report","content:en-us:blog:global-developer-report.yml","Global Developer Report","en-us/blog/global-developer-report.yml","en-us/blog/global-developer-report",{"_path":3086,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3087,"content":3092,"config":3097,"_id":3099,"_type":17,"title":3100,"_source":18,"_file":3101,"_stem":3102,"_extension":21},"/en-us/blog/guide-to-ci-cd-pipelines",{"title":3088,"description":3089,"ogTitle":3088,"ogDescription":3089,"noIndex":6,"ogImage":947,"ogUrl":3090,"ogSiteName":667,"ogType":668,"canonicalUrls":3090,"schema":3091},"A quick guide to GitLab CI/CD pipelines","How GitLab is making a better pipeline with Auto DevOps.","https://about.gitlab.com/blog/guide-to-ci-cd-pipelines","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A quick guide to GitLab CI/CD pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-07-12\",\n      }",{"title":3088,"description":3089,"authors":3093,"heroImage":947,"date":3094,"body":3095,"category":14,"tags":3096},[1483],"2019-07-12","\nTo be successful with [DevOps](https://about.gitlab.com/topics/devops/), teams must use [automation](https://docs.gitlab.com/ee/topics/autodevops/), and [CI/CD pipelines](https://about.gitlab.com/topics/ci-cd/) are a big part of that journey. At its most basic level, a pipeline gets code from point A to point B. The quicker and more efficient the pipeline is, the better it will accomplish this task.\n## What is a CICD pipeline?\n\nA pipeline is the lead component of continuous integration, delivery, and deployment. It drives software development through building, testing and deploying code in stages. Pipelines are comprised of jobs, which define what will be done, such as compiling or testing code, as well as stages that spell out when to run the jobs. An example would be running tests after stages that compile the code.\n\nA CI/CD pipeline automates steps in the SDLC such as builds, tests, and deployments. When a team takes advantage of automated pipelines, they simplify the handoff process and decrease the chance of human error, creating faster iterations and better quality code. Everyone can see where code is in the process and identify problems long before they make it to production.\n\nBefore we dive in, let's cover some basics:\n\n## The GitLab pipeline glossary\n\n**Commit**: A code change.\n\n**Job**: Instructions that a runner has to execute.\n\n**Pipeline**: A collection of jobs split into different stages.\n\n**Runner**: An agent or server that executes each job individually that can spin up or down as needed.\n\n**Stages**: A keyword that defines certain stages of a job, such as `build` and `deploy`. Jobs of the same stage are executed in parallel.\nPipelines are configured using a version-controlled YAML file, `.gitlab-ci.yml`, within the root of a project. From there, you can set up parameters of your pipeline:\n\n*   What to execute using [GitLab Runner](https://docs.gitlab.com/ee/ci/runners/#configuring-gitlab-runners)\n*   What happens when a process succeeds or fails\n\nNot all jobs are so simple. For larger products that require cross-project interdependencies, such as those adopting a [microservices architecture](/blog/strategies-microservices-architecture/), there are [multi-project pipelines](/blog/use-multiproject-pipelines-with-gitlab-cicd/).\n\n![multi-project pipelines](https://about.gitlab.com/images/topics/multi-project_pipelines.png){: .shadow.medium.center }\n\nIn GitLab 9.3 we made it possible to display links for upstream and downstream projects directly on the pipeline graph, so developers can check the overall status of the entire chain in a single view. Pipelines continue to evolve, and in our [CI/CD product vision](https://about.gitlab.com/direction/ops/) we’re looking into making pipelines even more cohesive by implementing [Multiple Pipelines in a single `.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-ce/issues/22972) in the future.\n\n## Pipeline as code\n\nDefining deployment pipelines through source code such as Git, is known as pipeline as a code. The pipeline as code practice is part of a larger “as code” movement that includes infrastructure as code. Teams can configure builds, tests, and deployment in code that is trackable and stored in a centralized source repository. They can use a declarative YAML approach or a vendor-specific programming language, such as Jenkins and Groovy, but the premise remains the same.\n\nA pipeline as code file specifies the stages, jobs, and actions for a pipeline to perform. Because the file is versioned, changes in pipeline code can be tested in branches with the corresponding application release.\n\nThe pipeline as code model of creating continuous integration pipelines is an industry best practice. There are multiple benefits, such as the ability to store CI pipelines and application code in the same repository. Developers can also make changes without additional permissions, working with tools they’re already using.\n\nOther benefits are more efficient collaboration and the ability to keep information accessible so team members can act on their decisions. Pipeline changes are subject to a code review process, avoiding any break in the pipeline migration.\n\nDeployment pipelines are in a version control system independent of continuous integration tools. Pipelines can be restored if the continuous integration system goes down. If a team wants to switch CI tools at another point, pipelines can be moved into a new system.\n\nIn the early iterations of [CI/CD](/topics/ci-cd/), DevOps tools set up pipelines as point-and-click or through a GUI. This originally presented a number of challenges:\n\n*   Auditing was limited to what was already built in\n*   Unable to collaborate\n*   Difficulty troubleshooting\n\nSomething as simple as rolling back to the last known config was an exercise in futility. CI/CD pipelines during this time were prone to breaking, lacked visibility, and were difficult to change.\n\nThe pipeline as code model corrected a lot of these pain points and offered the flexibility teams needed to execute efficiently. With source code, teams could use Git to search and introspect changes.\n\nToday, many tools have adopted YAML configuration as a best practice. GitLab CI/CD has used code, rather than GUI, since the beginning for pipeline configuration. \"Pipeline as code\" comes with many of the same benefits the other \"as code\" trends have:\n\n*   **Version control** – keep track of changes over time and revert to previous configurations easily\n*   **Audit trails** – know when and what changes were made to the source code\n*   **Ease of collaboration** – code is available to the team for improvements, suggestions, and updates\n*   **Knowledge sharing** – import templates and code snippets so teams can share best practices\n*   **Built-in Lint tool** – ensures YAML file is valid and assists new users\n\nThe principles of software development apply not only to the applications we deliver but also to _how_ we build them. The pipeline as code model creates automated processes that help developers build applications better and faster. Having everything documented in a source repository allows for greater visibility and collaboration so that everyone can continually improve processes, which is what DevOps is all about.\n\n## What are the different stages of a GitLab CI/CD pipeline?\n\nPipelines are comprised of jobs, which define _what_ to do, such as compiling or testing code; stages, which define _when_ to run the jobs; and runners, which are agents or servers that execute each job, and can spin up or down as needed.\n\nPipelines are generally executed automatically and don’t need any intervention once they are created. \n\nA typical pipeline generally consists of a few stages in the following order:\n\n### Test\nThe test stage is where the code is assess to ensure there are no bugs and it is working the way it was designed to before it reaches end users. The test stage has a job called deploy-to stage. Unit testing on small, discrete functions of the source may also done. All unit tests running against a code base are required to pass. If they don’t that creates a risk that must be addressed right away.\n\n### Deploy\nThe staging stage has a job called deploy-to-stage, where a team can conduct further tests and validation. It is followed by a production stage with a job called deploy-to-production. If the code passes a series of automated tests, often the build will automatically deploy. [The endpoint is typically pre-production deployment](https://www.techtarget.com/searchsoftwarequality/CI-CD-pipelines-explained-Everything-you-need-to-know). Once the build’s integrity is completely validated by stakeholders, it can be deployed to an actual production environment. Once the build passes pre-deployment testing, in a continuous deployment pipeline, it is automatically deployed to production.Then, it is monitored. To do so effectively requires collecting and [analyzing metrics](https://about.gitlab.com/topics/ci-cd/continuous-integration-metrics/) such as deployment frequency, deployment time and lead time for changes.\n\n## How do I set up a GitLab CI/CD pipeline?\nPipeline templates are useful because writing them from scratch is a time-consuming and onerous process. GitLab has pipeline templates for more than 30 popular programming languages and frameworks. Templates to help you get started can be found in our [CI template repository](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates).\n\nA GitLab pipeline executes several jobs, stage by stage, with the help of automated code.\n\nA continuous integration pipeline involves building something from the scratch and testing the same in a development environment. It might occur to the developers to add something after building the application and pushing it into production. This can be done with the help of continuous integration where we can add the code even after it is deployed.\n\nThis phase includes testing as well where we can test with different approaches in the code.\n\n### CD Pipeline prerequisites \nTo get started, you need to set up an [Ubuntu 18.04 server](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04) along with a sudo non-root user and firewall. You also need at least 1 GB RAM and 1 CPU.\n\n[Docker](https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04) must be installed on the server.\nA user account on a GitLab instance with an enabled container registry. The free plan of the [official GitLab instance](https://gitlab.com/) meets the requirements. You can also host your own GitLab instance by following the [How To Install and Configure GitLab on Ubuntu 18.04 guide](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-gitlab-on-ubuntu-18-04).\nThen you should create a GitLab project, adding an HTML file to it. Later, you’ll copy the HTML file into an Nginx Docker image, which in turn, you will deploy to the server.\n\n1. Log in to your GitLab instance and click new project.\n2. Give it a proper Project name.\n3. Optionally add a Project description.\n4. Make sure to set the Visibility Level to Private or Public depending on your requirements.\n5. Finally click Create project\n\n## Building better pipelines with Auto DevOps\n\nCI/CD pipelines have automated so much of the development process, however, it will still take time to do the initial work of building and configuring them in your environment. But what if you aren’t sure what all the parts of your CI/CD pipeline should be? What are the best practices you should know at every stage?\n\nIn the past, there have only been two choices: Time-consuming configuration from scratch with complete customization, or an easier auto-configuration with much less flexibility. Developers have longed for the moment where they could click a button and have a complete pipeline with code quality, language detection, and all scripts included with very little manual work.\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) is our solution to this problem. It is a pre-built, fully-featured CI/CD pipeline that automates the entire delivery process. Instead of having to choose between time and flexibility, GitLab offers both. In addition to the Auto DevOps template, GitLab offers several CI templates that can be modified as necessary, or you can override specific settings. Want all the power of Auto DevOps for a custom test job? Just override the `script` block for the `test` job and give it a try. Since templates are also modular, teams have the option to pull in only the parts they need.\n\nWe hope this blog post gives you some insight into how we approach pipeline as code and our larger vision for how we’re improving the CI/CD pipeline experience in the future. Automated pipelines increase development speed and improve code quality, and we’re actively working on making them even better and easier to use.\n\nCover image by [Gerrie van der Walt](https://unsplash.com/photos/m3TYLFI_mDo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/pipes?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,1255,110],{"slug":3098,"featured":15,"template":681},"guide-to-ci-cd-pipelines","content:en-us:blog:guide-to-ci-cd-pipelines.yml","Guide To Ci Cd Pipelines","en-us/blog/guide-to-ci-cd-pipelines.yml","en-us/blog/guide-to-ci-cd-pipelines",{"_path":3104,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3105,"content":3111,"config":3116,"_id":3118,"_type":17,"title":3119,"_source":18,"_file":3120,"_stem":3121,"_extension":21},"/en-us/blog/positive-outcomes-ci-cd",{"title":3106,"description":3107,"ogTitle":3106,"ogDescription":3107,"noIndex":6,"ogImage":3108,"ogUrl":3109,"ogSiteName":667,"ogType":668,"canonicalUrls":3109,"schema":3110},"4 Benefits of CI/CD","Learn how to implement and measure a successful CI/CD pipeline strategy and help your DevOps team deliver higher quality software, faster!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670016/Blog/Hero%20Images/modernize-cicd.jpg","https://about.gitlab.com/blog/positive-outcomes-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 Benefits of CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-06-27\",\n      }",{"title":3106,"description":3107,"authors":3112,"heroImage":3108,"date":3113,"body":3114,"category":14,"tags":3115},[1483],"2019-06-27","\n[CI/CD](/topics/ci-cd/) helps DevOps teams ship higher quality software, faster, for improved software deployment. But is all [CI/CD](/topics/ci-cd/) created equal? What do the benefits of continuous integration, continuous delivery, and continuous deployment look like and how do you know you're on the right track?\n\nIn this four-part series, we talk about modernizing your CI/CD: Challenges, impact, outcomes, and solutions. In [part one](/blog/modernize-your-ci-cd/), we focused on common CI/CD challenges. In [part two](/blog/business-impact-ci-cd/), we talked about the revenue impacts. Today, we’ll talk about what CI/CD can deliver and how to measure its success.\n\nIf these problems hit a little too close to home, stay tuned for part four where we dive deeper into finding the right CI/CD solution for you.\n\n## What are some of the benefits of a good CI/CD strategy?\n\n### 1. Increased speed of innovation and ability to compete in the marketplace\n\nTwo identical companies: One implements [CI/CD technology](/topics/ci-cd/) and the other doesn’t. Who do you think deploys applications faster? While this seems like a silly comparison, because _of course_ the company with more automation deploys faster, there are organizations out there still convinced they don’t need CI/CD because they’re not looking at their competition. Organizations that understand the importance of CI/CD are setting the pace of innovation for everyone else.\n\n### 2. Code in production is making money instead of sitting in a queue waiting to be deployed\n\nOrganizations that have implemented CI/CD are making revenue, satisfying customers, and getting user feedback on the product features they deploy, not waiting for a manual check to see if the code is up to par. They already know the code is good because they have tests that are automated, and continuous delivery means that code is deployed automatically if it meets certain standards. They’ve removed human error and delays from the process so they can ship more code to production.\n\n### 3. Great ability to attract and retain talent\n\nEngineers that can focus on what they’re best at will be happier and more productive, and that has far-reaching impact. Turnover can be expensive and disruptive. A good CI/CD strategy means engineers can work on important projects and not worry about time-consuming manual tasks. They can also work confidently knowing that errors are caught automatically, not right before deployment. This kind of cooperative engineering culture inevitably attracts talent.\n\n### 4. Higher quality code and operations due to specialization\n\nThe development team can focus on dev. The operations team can focus on ops. Bad code rarely makes it to production because continuous testing is automated. Developers can focus on the code rather than the production environment, and operations doesn’t have to feel like a gatekeeper or a barrier. Both teams can work to their strengths, and automated handoffs make for seamless processes for the entire team. [This kind of cooperation makes DevOps possible](/topics/devops/build-a-devops-team/) and improves code quality.\n\n## What capabilities are required to make this happen?\n\n### 1. Robust CI/CD\n\nWhen we use the term “robust,” it’s all about avoiding half-baked or partial solutions. There are several CI/CD solutions out there but there are varying degrees of effectiveness. Continuous integration and continuous delivery go hand in hand, so having a solution that offers both is ideal. The tool you use should offer the automation you need, not just some. If your CI/CD tool is prone to failure or “brittle,” it can be just one more thing to manage. This was precisely why [the team at Ticketmaster replaced Jenkins CI and moved to weekly releases](/blog/continuous-integration-ticketmaster/), decreasing their pipeline execution time from two hours to only _eight minutes_ to build, test, and publish artifacts.\n\n### 2. Containers and Kubernetes\n\nContainers have made a huge impact on the way companies build and deploy code. While it was once difficult to develop applications with a [microservices architecture](/blog/strategies-microservices-architecture/), over the past five years it has become considerably easier with container orchestration tools like Kubernetes, comprehensive CI/CD tools that automate testing and deployments, and APIs that update automatically. Breaking up services so they can run independently reduces dependencies and creates better workflows.\n\n### 3. Functionality for the entire DevOps lifecycle\n\nVisibility is a huge asset when improving DevOps workflows. For some teams, they can have several tools handling different facets of the software development lifecycle (SDLC), which creates integration issues, maintenance issues, visibility issues, and is [just plain expensive](/calculator/roi/) from a cost standpoint. A complex toolchain can also weaken security. In a [Forrester survey of IT professionals](/resources/downloads/201906-gitlab-forrester-toolchain.pdf), 45% said that they had difficulty ensuring security across the toolchain.\n\n## How would you measure the success of a CI/CD strategy?\n\n### 1. Cycle time\n\nCycle time is the speed at which a [DevOps team](/topics/devops/) can deliver a functional application, from the moment work begins to when it is providing value to an end user.\n\n### 2. Time to value\n\nOnce code is written, how long before it’s released? This delay from when code is written to running in production is the time to value, and is a bottleneck for many organizations. Continuous delivery as well as [examining trends in the QA process](/blog/trends-in-test-automation/) can help to overcome this barrier to quick deployments and frequent releases.\n\n### 3. Uptime, error rate, infrastructure costs\n\nUptime is one of the biggest priorities for the ops team, and with a good CI/CD strategy that automates different processes, they should be able to focus more on that goal. Likewise, error rates and infrastructure costs can be easily measured once CI/CD is put in place. Operations goals are a key indicator of process success.\n\n### 4. Team retention rate\n\nHappy developers stick around, so looking at retention rates is a reliable way to gauge how well new development processes and applications are working for the team. It might be tough for developers to speak up if they don’t like how things are going, but looking at retention rates can be one step in identifying potential problems.\n\nThe benefits of a good CI/CD strategy are felt throughout an organization: From HR to operations, teams work better and achieve goals. In such a competitive development landscape, having the right CI/CD in place gives any company an edge.\n\nSo what makes “good” CI/CD? We invite you to compare GitLab CI/CD to other CI tools and see why we were rated #1 in the Forrester CI Wave™.\n",[806,110,1255],{"slug":3117,"featured":6,"template":681},"positive-outcomes-ci-cd","content:en-us:blog:positive-outcomes-ci-cd.yml","Positive Outcomes Ci Cd","en-us/blog/positive-outcomes-ci-cd.yml","en-us/blog/positive-outcomes-ci-cd",{"_path":3123,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3124,"content":3129,"config":3135,"_id":3137,"_type":17,"title":3138,"_source":18,"_file":3139,"_stem":3140,"_extension":21},"/en-us/blog/business-impact-ci-cd",{"title":3125,"description":3126,"ogTitle":3125,"ogDescription":3126,"noIndex":6,"ogImage":3108,"ogUrl":3127,"ogSiteName":667,"ogType":668,"canonicalUrls":3127,"schema":3128},"The business impact of CI/CD","How a good CI/CD strategy generates revenue and keeps developers happy.","https://about.gitlab.com/blog/business-impact-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The business impact of CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"},{\"@type\":\"Person\",\"name\":\"William Chia\"}],\n        \"datePublished\": \"2019-06-21\",\n      }",{"title":3125,"description":3126,"authors":3130,"heroImage":3108,"date":3132,"body":3133,"category":14,"tags":3134},[1483,3131],"William Chia","2019-06-21","\n\n[Continuous integration and delivery](/features/continuous-integration/) helps [DevOps](/topics/devops/) teams ship higher quality software, faster. But is all [CI/CD](/topics/ci-cd/) created equal? What does successful CI/CD implementation look like and how do you know you’re on the right track?\n\nIn this four-part series, we talk about modernizing your CI/CD: Challenges, impact, outcomes, and solutions. In [part one](/blog/modernize-your-ci-cd/), we focused on common CI/CD challenges. Today, we’ll talk about the revenue impact of a poor or non-existent CI/CD strategy.\n\nIf these problems hit a little too close to home, stay tuned for part three where we dive deeper into what organizations gain when they implement better CI/CD.\n\n## What are the business impacts of bad CI/CD?\n\n### 1. A large portion of IT budget is spent on undifferentiated engineering\n\nOpportunity costs play a much larger role in the development process than we realize. Organizations can only afford so many engineers at one time, and systems that require extensive maintenance means fewer engineers are working on revenue-generating projects. This will lead to slower innovation and slower growth in the long term. Undifferentiated engineering means too many individuals are having to focus on one thing – maintenance.\n\n### 2. Delayed (and even unrealized) revenue\n\nThis is the impact of lost opportunity costs. When there are too many dependencies, too many handoffs, and too many manual tasks, it causes delays between when code is written and when the business gets value from that code. In worst cases, code is written and the business never gets any value from it at all. Code can sit in limbo waiting for others to manually test it, and by the time it’s finally reviewed it’s already irrelevant. The opportunity cost essentially doubles: Engineers were paid to work on code that never deployed, and the business loses out on revenue the code could have generated.\n\n### 3. Lower developer productivity, lower developer happiness, and less reliable software\n\nDowntime = lost revenue. To avoid that dreaded downtime, developers are spending time working on infrastructure and configuration, and they’re also not spending that time delivering business logic. In both cases, they’re being less productive and working outside of their core competencies. Developer hiring and retention will inevitably suffer. Uptime and resiliency are also affected because people who aren’t domain experts are put in charge of determining infrastructure. It’s a self-fulfilling prophecy.\n\n## What does it look like if a magic wand were to solve it today?\n\n### 1. More engineers are working on the app instead of maintenance\n\nThe organization has the right amount of developers devoted to driving business value and spends more time on innovation instead of undifferentiated heavy lifting. Less of the budget is spent on activities that don't generate revenue.\n\n### 2. Developers see their code in production quickly\n\nInfrastructure and deployment are [fully automated](https://docs.gitlab.com/ee/topics/autodevops/). Everyone loves to see the output of their work, developers especially, and the business gets to see the benefits of this code right away. Deploying smaller chunks of code is less risky when developers can take advantage of test automation, so they have less overhead and coordination with a QA team forced to test manually.\n\n### 3. Developers are focused on solving business problems\n\nCode is written to be environment and cloud agnostic. Development teams own the uptime of their own services, but they are fully supported by the ops team. Ops owns the infrastructure, dev owns the service, and both teams can work according to their strengths.\n\nSolving these problems doesn’t require waving a wand or any magic at all. Modernizing your architecture and embracing CI/CD is what other companies are doing to release better software, faster. When organizations implement CI/CD best practices, they get the added benefit of generating more revenue in the long run.\n\nSo what makes “good” CI/CD? We invite you to compare GitLab CI/CD to other CI tools and see why we were rated #1 in the Forrester CI Wave™.\n\n[Explore GitLab CI/CD](/features/continuous-integration/)\n{: .alert .alert-gitlab-purple .text-center}\n\nPhoto by [Jungwoo Hong](https://unsplash.com/photos/cYUMaCqMYvI?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/arrow?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,110,1255],{"slug":3136,"featured":6,"template":681},"business-impact-ci-cd","content:en-us:blog:business-impact-ci-cd.yml","Business Impact Ci Cd","en-us/blog/business-impact-ci-cd.yml","en-us/blog/business-impact-ci-cd",{"_path":3142,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3143,"content":3149,"config":3154,"_id":3156,"_type":17,"title":3157,"_source":18,"_file":3158,"_stem":3159,"_extension":21},"/en-us/blog/issue-labels-can-now-be-scoped",{"title":3144,"description":3145,"ogTitle":3144,"ogDescription":3145,"noIndex":6,"ogImage":3146,"ogUrl":3147,"ogSiteName":667,"ogType":668,"canonicalUrls":3147,"schema":3148},"Issue labels can now be scoped!","A small change with a huge impact: Scoped Labels can help teams customize their workflow and speed up delivery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679729/Blog/Hero%20Images/scopedlabels.jpg","https://about.gitlab.com/blog/issue-labels-can-now-be-scoped","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Issue labels can now be scoped!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-06-20\",\n      }",{"title":3144,"description":3145,"authors":3150,"heroImage":3146,"date":3151,"body":3152,"category":14,"tags":3153},[1635],"2019-06-20","\n\nGreat news, everyone!\n[Hailed as one of the best inventions since sliced bread](https://gitlab.com/gitlab-com/marketing/corporate-marketing/issues/682),\n[Scoped Labels](/releases/2019/04/22/gitlab-11-10-released/#scoped-labels) can make your\ncustom workflows even cooler. We’re excited to share how using this small feature can\naccelerate delivery.\n\nPlease note that this is a paid feature available to Premium and Ultimate for [self-managed](/pricing/#self-managed) GitLab\nor Silver and Gold tiers for [GitLab.com](/pricing/).\n{: .alert .alert-info.text-center}\n\n## What are GitLab Scoped Labels?\n\nIt all started with\n[an issue detailing a feature with a simple idea](https://gitlab.com/gitlab-org/gitlab-ee/issues/9175):\nHelp teams that use issue boards for workflow. With Scoped Labels, teams can apply\nmutually exclusive labels (that share the same scope) to an issue, merge request,\nor epic, solving custom fields and custom workflow states use cases. Scoped Labels\nmake it possible for teams to define a basic custom field that avoids confusion and\ncleans up issue lists (i.e. fewer duplicate labels).\n\n![Scoped labels](https://about.gitlab.com/images/blogimages/scoped-labels.png){: .shadow.center.medium}\n\nBy using Scoped Labels, teams can create custom labels and apply them to a\ngiven issue, automatically removing any other existing, related labels. For example,\nif you have the labels `workflow::development`, `workflow::review`, and `workflow::deployed`,\nrepresenting the workflow states of your team, you can advance the issue\n(e.g., `workflow::development` to `workflow::review`) by applying the next label\nwithout having to remove the original one.\n\nYou may already be familiar with this behavior, since it’s similar to moving\nissues across label lists in an issue board. Now, team members who don’t directly work\nin an issue board or who want to advance workflow states consistently in\nissues themselves can do so using Scoped Labels.\n\n## How Scoped Labels accelerate delivery\n\nYou might be thinking that Scoped Labels is too small of a feature to make a splash,\nbut hear me out, it can help reduce cycle time. Here's how:\n\n1. If you want a custom field on your issues, like a drop-down with a few items\nyou can select (e.g., colors or stages), Scoped Labels prevent conflicts where\nnormally only one color or one stage is possible. By removing conflicts, multiple\nteams can scope an issue, merge request, or epic.\n1. You can define the workflow steps for an issue (e.g., proposal, design,\ndevelopment, QA, acceptance, deploy), creating the basis for how you can eventually\nmeasure the flow of work though the system (based on how long issues have specific labels).\n\nThese two use cases illustrate how Scoped Labels can help teams work concurrently\non features and measure their efforts.\n\n## Scoped Labels: A feature film\n\nWant to see Scoped Labels in action? Get your popcorn ready and enjoy the show! 🍿\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4BCBby6du3c\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCheck out the [documentation on Scoped Labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) for more.\n\nCover image by [ Jo Szczepanska](https://unsplash.com/@joszczepanska?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/9OKGEVJiTKk)\n{: .note}\n",[995,1255,1447],{"slug":3155,"featured":6,"template":681},"issue-labels-can-now-be-scoped","content:en-us:blog:issue-labels-can-now-be-scoped.yml","Issue Labels Can Now Be Scoped","en-us/blog/issue-labels-can-now-be-scoped.yml","en-us/blog/issue-labels-can-now-be-scoped",{"_path":3161,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3162,"content":3168,"config":3173,"_id":3175,"_type":17,"title":3176,"_source":18,"_file":3177,"_stem":3178,"_extension":21},"/en-us/blog/strategies-microservices-architecture",{"title":3163,"description":3164,"ogTitle":3163,"ogDescription":3164,"noIndex":6,"ogImage":3165,"ogUrl":3166,"ogSiteName":667,"ogType":668,"canonicalUrls":3166,"schema":3167},"Implementing microservices architectures and deployment strategies","Want to dump the monolith and get into microservices? Consider these three methods.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/strategies-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Implementing microservices architectures and deployment strategies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-06-17\",\n      }",{"title":3163,"description":3164,"authors":3169,"heroImage":3165,"date":3170,"body":3171,"category":14,"tags":3172},[1483],"2019-06-17","\n\nMicroservices can have a major impact on organizations looking to increase automation and deployment speed. The biggest companies in the world – Amazon, Netflix, Google, etc. – all work on this architecture model and release at lightning speed. So why is using microservices so effective? The easiest way to understand [microservices architecture](/blog/what-are-the-benefits-of-a-microservices-architecture/) is by comparing it to its counterpart – the monolith.\n\nWith a monolithic architecture, all of the components are part of a single unit: Everything is developed, deployed, and scaled together. In comparison, [microservices](/topics/microservices/) have each component broken out and deployed individually as services, and these services communicate with each other via API calls. For complex applications that need to run at scale, microservices can offer greater flexibility, reliability, and a faster pace of innovation than monoliths.\n\nNo, monoliths aren’t inherently bad, but teams stuck in a monolith system often sacrifice speed for simplicity, and that could haunt them in the long term. So what do you do when you want to make the switch to microservices and start implementing faster? Consider these options.\n\n## The strangler method\n\n[Martin Fowler’s strangler method](https://www.martinfowler.com/bliki/StranglerApplication.html) was inspired by a trip he took to Australia:\n\n> “One of the natural wonders of this area [Australia] is the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.”\n\nIt sounds brutal based on this description, but it’s actually one of the gentlest and most effective transitions for an organization. Essentially, parts of the monolith become microservices little by little until eventually the monolith is cut out completely. The benefit is that this transition is much more gradual, so uptime and availability are largely unaffected while the organization modernizes. The con? Speed.\n\n## The Lego strategy\n\nLet’s say you don’t necessarily want to ditch the monolith completely. Maybe it has a valuable use for a certain product or facet of the organization, or maybe you just don’t have the resources to dismantle it or don’t want to. The Lego strategy could be the right choice.\n\nThe team at Kong use this term because you’re essentially building on top of what you already have (like Lego blocks). Instead of switching over to microservices completely, you commit to [building new features as microservices](https://konghq.com/blog/transition-to-microservices-what-now/) while still keeping the existing monolithic codebase. While this approach doesn’t fix current issues, it will help with future expansions and buy much-needed time. This hybrid environment can exist relatively pain-free but has some risks: Increased technical debt, navigating code versions between the monolith and the new microservices features, and maintenance costs.\n\n## The nuclear option\n\nImagine: Your monolith is kaput, finito, dunzo. It can’t be fixed and it can’t stay. What now? As the name suggests, going nuclear is the riskiest and rarest option of all. The upside is that you can start from scratch. The downside is... you start from scratch. This approach is risky because you do run the risk of downtime when everything shifts over to microservices – which is a real no-no for user experience. Infrastructure is best when it’s invisible, and a new microservices architecture won’t win back the favor of users that were inconvenienced. Then again, maybe your new microservices architecture was built perfectly and cloud, software, and staff are perfectly in place and users will never know the difference. That’s the risk of a full rip-and-replace.\n\n## A successful transition to microservices\n\n[The team at Verizon was able to reduce its data center deploys from 30 days to _under eight hours_ by utilizing microservices](/blog/verizon-customer-story/), and their application modernization strategy centered around four key goals:\n\n*   Architecture\n*   Automation\n*   Extensibility\n*   Being proactive\n\nBy having clear goals throughout the process, the Verizon team was able to remove manual deployments and streamline their processes. When adopting a microservices model, it helps to have some clear objectives about what you would like to achieve, and prioritize certain outcomes over others. Modernization projects almost never go according to plan, and if you have to make tough decisions, having a list of ‘must-haves’ can guide the conversation.\n\nThe oldest argument for monoliths has always been their simplicity: They’re easy to build and easy to run. While it was once difficult to develop applications with a microservices architecture, over the past five years it has become considerably easier with container orchestration tools like Kubernetes, [comprehensive CI/CD tools](/features/continuous-integration/) that automate testing and deployments, and APIs that update automatically. Developers can focus on innovating rather than completing manual tasks and maintaining legacy systems. Organizations that adopt microservices get their simplicity through automated processes, and while it’s not as simple as a monolith, the benefits far outweigh the cons.\n\nRegardless of which method you choose, the willingness to modernize to the latest [DevOps](/topics/devops/) architecture is the most important first step. Ready to dive into microservices?\n\n[Just commit](/blog/application-modernization-best-practices/).\n{: .alert .alert-gitlab-purple .text-center}\n",[806,110],{"slug":3174,"featured":6,"template":681},"strategies-microservices-architecture","content:en-us:blog:strategies-microservices-architecture.yml","Strategies Microservices Architecture","en-us/blog/strategies-microservices-architecture.yml","en-us/blog/strategies-microservices-architecture",{"_path":3180,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3181,"content":3187,"config":3192,"_id":3194,"_type":17,"title":3195,"_source":18,"_file":3196,"_stem":3197,"_extension":21},"/en-us/blog/agile-mindset",{"title":3182,"description":3183,"ogTitle":3182,"ogDescription":3183,"noIndex":6,"ogImage":3184,"ogUrl":3185,"ogSiteName":667,"ogType":668,"canonicalUrls":3185,"schema":3186},"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":3182,"description":3183,"authors":3188,"heroImage":3184,"date":3189,"body":3190,"category":14,"tags":3191},[1635],"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",[1447,974,806,1255],{"slug":3193,"featured":6,"template":681},"agile-mindset","content:en-us:blog:agile-mindset.yml","Agile Mindset","en-us/blog/agile-mindset.yml","en-us/blog/agile-mindset",{"_path":3199,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3200,"content":3205,"config":3211,"_id":3213,"_type":17,"title":3214,"_source":18,"_file":3215,"_stem":3216,"_extension":21},"/en-us/blog/manage-conversation-staying-agile",{"title":3201,"description":3202,"ogTitle":3201,"ogDescription":3202,"noIndex":6,"ogImage":2938,"ogUrl":3203,"ogSiteName":667,"ogType":668,"canonicalUrls":3203,"schema":3204},"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":3201,"description":3202,"authors":3206,"heroImage":2938,"date":3208,"body":3209,"category":14,"tags":3210},[3207],"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",[1447,974,676],{"slug":3212,"featured":6,"template":681},"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":3218,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3219,"content":3225,"config":3231,"_id":3233,"_type":17,"title":3234,"_source":18,"_file":3235,"_stem":3236,"_extension":21},"/en-us/blog/proximus-customer-story-clearcase-to-gitlab",{"title":3220,"description":3221,"ogTitle":3220,"ogDescription":3221,"noIndex":6,"ogImage":3222,"ogUrl":3223,"ogSiteName":667,"ogType":668,"canonicalUrls":3223,"schema":3224},"Proximus shares its #movingtoGitLab story","Moving to GitLab resulted in an 80 percent drop in support tickets and an increase in developer productivity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678603/Blog/Hero%20Images/traffic-at-sunset.jpg","https://about.gitlab.com/blog/proximus-customer-story-clearcase-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Proximus shares its #movingtoGitLab story\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bert Van Eyck\"}],\n        \"datePublished\": \"2019-06-07\",\n      }",{"title":3220,"description":3221,"authors":3226,"heroImage":3222,"date":3228,"body":3229,"category":14,"tags":3230},[3227],"Bert Van Eyck","2019-06-07","\n[Proximus](https://www.proximus.com/) is a telecommunication company providing services to residential, enterprise, and public users. We are the leading provider of telephony, internet, television, and network-based ICT services in Belgium, with more than 2 million customers.\n\n## Our road to GitLab\n\nThe technical divisions of Proximus deliver a big part of the applications and systems required for delivering the best possible service to our end users. It includes all types of capabilities such as network construction, network maintenance, product ordering, product selling, billing, etc.\nSome examples of our development include:\n\n- Our website, [Proximus.be](https://www.proximus.be), on which users can find product info, support info and so much more.\n- A mobile app where everyone can check their usage, products, bills, etc.\n- Television interface.\n- A television app.\n\nTo ensure a performant and stable working environment for our developers, we have been working for several years to create a CI/CD DevOps workflow.\n\nThe first complete chain started in 2014 and used tools like ClearCase, Jenkins, Nexus, etc. By 2015 we had about 200 applications which were using our end-to-end chain to build and deploy in all different environments.\n\nIn 2016, to continue to improve our delivery chain, we considered switching ClearCase to Git. Despite ClearCase being a powerful tool, we noticed that the learning curve and the ease of use of ClearCase was not optimal. Also some of the tools we used were starting to lose compatibility.\n\nWe quickly came across GitLab and decided to try our first setup with [GitLab CE](/blog/gitlab-tiers/) in mid-2016.\n\n## The evolution of GitLab inside Proximus\n\nOur first implementation of Gitlab was rapidly a real success and the popularity of GitLab was increasing exponentially within our developer community. So, we decided to set up a corporate GitLab CE server at Proximus and to promote the creation of all new applications using our existing CI/CD chain with GitLab as source code management.\nIn just one year of using GitLab, we grew to 325 projects and about 600 users.\n\nBecause GitLab was becoming a big part of our tool set, we switched to GitLab EE in Q2 of 2017. This allowed us to use more features of GitLab such as: LDAP groups, push rules, mirror repositories, etc.\nAnd of course, with the enterprise edition you also receive additional support. With the enterprise edition we also started moving applications from ClearCase to GitLab.\n\nWe were also investigating and testing other features to expand our use of GitLab in the meantime:\n\n- Some projects have started using GitLab CI to build.\n- Integration with Jira has been implemented.\n- Currently experimenting with a first setup of GitLab’s global search function in combination with Elasticsearch.\n\nBy the end of 2018 we had grown to almost 1,000 users and 1,700 projects.\n\n## Challenges\n\nOur biggest challenge was to maintain and ensure a stable environment while growing rapidly. When we started using GitLab CI we encountered some issues with the large number of pipelines and jobs being created, which were consuming a lot of our resources. But [as of GitLab 11.6 a feature has been provided to remove pipelines with their job logs when using API](/releases/2018/12/22/gitlab-11-6-released/#pipelines-can-now-be-deleted-by-project-maintainers-using-api), which helped a lot.\n\n## Results\n\nSince we started using GitLab, we have been able to provide our developers with faster setup and support. Another very noticeable side effect of switching to GitLab was the significant drop in the number of support tickets created by the developers. Our first full year of using GitLab inside our CI/CD setup resulted in **80 percent** fewer tickets.\n\nEven in 2018, after our total number of users had grown to almost 1,000, the number of projects had multiplied by five and we migrated 75 applications to GitLab. We still had **65 percent** fewer tickets.\n\nIn the future, we will continue looking into expanding our GitLab environment and we hope to continue the positive evolution together with the support of GitLab.\n",[268,973,232,1791,852],{"slug":3232,"featured":6,"template":681},"proximus-customer-story-clearcase-to-gitlab","content:en-us:blog:proximus-customer-story-clearcase-to-gitlab.yml","Proximus Customer Story Clearcase To Gitlab","en-us/blog/proximus-customer-story-clearcase-to-gitlab.yml","en-us/blog/proximus-customer-story-clearcase-to-gitlab",{"_path":3238,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3239,"content":3244,"config":3249,"_id":3251,"_type":17,"title":3252,"_source":18,"_file":3253,"_stem":3254,"_extension":21},"/en-us/blog/modernize-your-ci-cd",{"title":3240,"description":3241,"ogTitle":3240,"ogDescription":3241,"noIndex":6,"ogImage":3108,"ogUrl":3242,"ogSiteName":667,"ogType":668,"canonicalUrls":3242,"schema":3243},"3 CI/CD challenges to consider","If these DevOps challenges hit close to home, the right CI/CD could be the answer.","https://about.gitlab.com/blog/modernize-your-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 CI/CD challenges to consider\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-06-05\",\n      }",{"title":3240,"description":3241,"authors":3245,"heroImage":3108,"date":3246,"body":3247,"category":14,"tags":3248},[1483],"2019-06-05","\n[Continuous integration and delivery](/features/continuous-integration/) helps DevOps teams ship higher quality software, faster. But is all [CI/CD](/topics/ci-cd/) created equal? What does successful CI/CD implementation look like and how do you know you’re on the right track?\n\nIn this four-part series, we talk about modernizing your CI/CD: Challenges, impact, outcomes, and solutions. Today, we’ll focus on [DevOps](/topics/devops/) challenges and situations where a comprehensive CI/CD approach could be the answer you’ve been looking for.\n\nIf these problems hit a little too close to home, stay tuned for part two where we dive deeper into how these roadblocks impact the rest of the SDLC.\n\n## What challenges do I face?\n\n### 1. Maintenance and integration costs, predominantly human resources costs.\n\nA large percentage of the overall IT budget goes to support teams of engineers needed to integrate and maintain a complex toolchain. An enterprise company with 1,000 developers could need up to 40 engineers just to maintain the DevOps toolchain instead of allocating these resources towards delivering business value.\n\n### 2. Development is slowed/blocked by the operations team.\n\nThe quintessential challenge of the pre-DevOps world is that dev teams are incentivized to increase innovation velocity by shipping new features. Operations teams are incentivized for stability, uptime, and error reduction. The higher the development velocity, the greater the chance for downtime and errors – so these teams are naturally at odds with each other. Dev leaders don’t always have enough enticing evidence or incentive to go to the Ops team to advocate for increased deployment velocity, and vice versa.\n\n### 3. Developers doing ops.\n\nToday, teams and individual developers base the code they produce on the capabilities of their environment rather than the needs of the business.\n\n## What do these look like in practice?\n\n### A big portion of resources and budget goes to undifferentiated integration and maintenance.\n\nTeams are siloed by their tools – each team has their favorite and is optimized to work within these specialized tools only. It is difficult to collaborate and troubleshoot across the stack due to a lack of visibility.\n\n### Code sometimes never gets to production at all.\n\nThere is a delay between code being written and driving value. When problems or errors arise and need to be sent back to the developer, it becomes difficult to troubleshoot because the code isn’t fresh in their mind (context switching). They have to stop working on their current project and go back to the previous code to troubleshoot. So much time might have passed that the code is no longer deployable in its current state. In addition to wasting time and money, this is demoralizing for the developer who doesn’t get to see the fruit of their labor.\n\n### Developers worry about environments, not business logic.\n\nEnvironment dependencies and configuration distracts developers from tasks they’re better equipped to handle. They may even be spending time trying to decide what size VM they need to deploy to. In this order “DevOps” means “Developers have to do both dev and ops.” Only a small percentage of developers actually enjoy this arrangement with most asking, “I’m a developer, please stop asking me to do operations.”\n\nIf you’ve already implemented CI/CD but are still experiencing these roadblocks, it might be time to modernize your CI/CD. We invite you to compare GitLab CI/CD to other CI tools and see why we were rated #1 in the Forrester CI Wave™.\n\n[Explore GitLab CI/CD](/features/continuous-integration/)\n{: .alert .alert-gitlab-purple .text-center}\n\nPhoto by [Jungwoo Hong](https://unsplash.com/photos/cYUMaCqMYvI?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/arrow?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,110,1255],{"slug":3250,"featured":6,"template":681},"modernize-your-ci-cd","content:en-us:blog:modernize-your-ci-cd.yml","Modernize Your Ci Cd","en-us/blog/modernize-your-ci-cd.yml","en-us/blog/modernize-your-ci-cd",{"_path":3256,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3257,"content":3263,"config":3270,"_id":3272,"_type":17,"title":3273,"_source":18,"_file":3274,"_stem":3275,"_extension":21},"/en-us/blog/monkton-moves-to-gitlab-customer-story",{"title":3258,"description":3259,"ogTitle":3258,"ogDescription":3259,"noIndex":6,"ogImage":3260,"ogUrl":3261,"ogSiteName":667,"ogType":668,"canonicalUrls":3261,"schema":3262},"Monkton's #movingtogitlab story: Going all in on automation and repeatability","Monkton is migrating from a suite of disparate tools to GitLab, enabling them to better help their customers build safe, secure mobile apps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670123/Blog/Hero%20Images/moving-to-gitlab-cover.png","https://about.gitlab.com/blog/monkton-moves-to-gitlab-customer-story","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Monkton's #movingtogitlab story: Going all in on automation and repeatability\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"},{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2019-05-21\",\n      }",{"title":3258,"description":3259,"authors":3264,"heroImage":3260,"date":3267,"body":3268,"category":14,"tags":3269},[3265,3266],"Rebecca Dodd","Aricka Flowers","2019-05-21","\n\nEven with all the [#movingtogitlab](/blog/movingtogitlab/) excitement last year, it never gets old to hear about folks migrating to us.\nSo when Harold Smith, CEO and co-founder of [Monkton Incorporated](https://monkton.io/) – a company dedicated to helping enterprises build safe, secure, and compliant mobile solutions – wrote about [moving Monkton to GitLab](https://medium.com/@h3smith/migration-to-gitlab-dde59fc98315) earlier this year, we asked him to sit down with us to talk about the whys and hows.\n\n## From hodge podge of tools, to consolidated lifecycle\n\n\"We’ve been using some of your competitors’ tools.\nIt sort of became a hodge podge of tools – they’re still good tools, but there are different tools to do different things in the development life cycle. We had known GitLab had existed for a while.\nAnd I think, like many others who know about GitLab, it was an assumption on our end that it's just a source control repository.\nThen we started to realize and peel back a little bit of everything GitLab does – the continuous integration, integrations with other services, the whole pipeline.\nWe really started to focus on it and say, 'This is something we should spend time looking into and investing in.'\n\n\"It turned out to be a really good investment of time – we’ve seen time savings just in our ability to watch projects, our onboarding.\nIt’s cutting out a lot of the managing of all these different tools and different servers.\nIt’s just one thing to go in and manage that does most of the work we need.\nIt's also a huge advantage for us and our customers operating under the constraints of a higher-security environment, that we're able to do continuous integration and development, secure DevOps, in a secure environment that passes their auditing needs.\n\n>It’s cutting out a lot of the managing of all these different tools and different servers.\nIt’s just one thing to go in and manage that does most of the work we need.\n\n\"A lot of tools we were using, like some of the other continuous integration tools, are all open source software, which is great.\nBut that comes with some responsibilities: you need to really dig to figure out how to manage it correctly, how to set things up.\nSo, that was probably the biggest disadvantage of working with a collection of open source tools that didn’t have the proper documentation that we needed to move forward.\nSo, once we started looking at GitLab, it really enabled us to consolidate those things.\nAll the documentation is one place. The services that were available …\nIt was really easy to figure out what we needed to do.\nAnd your support has been a big help as well in enabling us to rapidly deliver and stand up these environments.\n\n\"Before, some of our processes were manual, like uploading code scans to Fortify.\nWe’ve automated all of that now on specific branches of the software that we’re building.\nSo, it’s taken out those manual processes that had to go through the checks.\nWhen we build a mobile application and push it through the pipeline, we’re working on how can we automatically publish that to MDM.\nSo, as soon as that code is checked in, scanned, what’s the process to get that into production?\nAnd that’s where we’ve focused a lot of effort of just entirely automation.\"\n\n## Automate all.the.things.\n\n\"Our collective vision within Monkton, and working with you at GitLab, and all these other companies, is how do we automate and take out human error from the equation?\nOur goal is that the moment code is checked in and has been reviewed, the testing lifecycle, the deployment lifecycle, the security vulnerability scanning lifecycle, should all be automated.\nSo, it’s more of humans reviewing reports at the end versus humans having to do the inspections themselves. We really envisioned that these tools could do a much better job than humans can.\n\n\"We’re not trying to replace human jobs. But how can we free people up to do what people do best, versus laborious efforts like pen testing mobile applications or pen testing web applications?\nA lot of that can be automated through scripting tools – Amazon Device Farm – all of which GitLab can automate and push out.\nSo, we’re focusing on what tools can we bring in to automate that process, tie them into GitLab, and automate everything. Or virtually everything.\"\n\n## Repeatability is key\n\n\"Repeatability is probably from our vantage point, one of the cornerstones of what we have to be able to do.\nIf we have a Department of Defense customer that builds a hundred mobile apps using our software, and they discover a vulnerability in one of them – if there’s not a repeatable process to build and deliver the solutions, it would take a year to update those hundred mobile apps if they’re doing it in a very siloed environment.\nBut with a repeatable process, they could change it out once and propagate it out, they can patch and push everything within an hour.\nA repeatable process allows you to have repeatable, consistent outcomes every single time, so you know that you can trust the process as part of your security program versus maybe a hodge podge of different tools and manual processes.\"\n\n## Lessons from the migration process\n\n\"It’s been a learning opportunity for us to see what are the best practices that we can collectively share – even with you at GitLab, there might be things that we’re all collectively learning, that we can use to help the community together.\nBecause this isn’t just a proprietary company effort on our end and your end, or even our customers’ end.\nI look at it as a good learning experience for all of us to improve processes, security, compliance, and everything that goes along with that.\"\n\nHere's a bit more from our chat with Harold:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/kT5qZ8W7yXM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n",[268,232,852,1791],{"slug":3271,"featured":6,"template":681},"monkton-moves-to-gitlab-customer-story","content:en-us:blog:monkton-moves-to-gitlab-customer-story.yml","Monkton Moves To Gitlab Customer Story","en-us/blog/monkton-moves-to-gitlab-customer-story.yml","en-us/blog/monkton-moves-to-gitlab-customer-story",{"_path":3277,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3278,"content":3284,"config":3289,"_id":3291,"_type":17,"title":3292,"_source":18,"_file":3293,"_stem":3294,"_extension":21},"/en-us/blog/secure-containers-devops",{"title":3279,"description":3280,"ogTitle":3279,"ogDescription":3280,"noIndex":6,"ogImage":3281,"ogUrl":3282,"ogSiteName":667,"ogType":668,"canonicalUrls":3282,"schema":3283},"A shift left strategy for the cloud","Protect your software in the cloud by bringing vulnerability testing closer to remediation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670146/Blog/Hero%20Images/containers-for-five-things-kubernetes-blog-post.jpg","https://about.gitlab.com/blog/secure-containers-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A shift left strategy for the cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"},{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-05-03\",\n      }",{"title":3279,"description":3280,"authors":3285,"heroImage":3281,"date":3286,"body":3287,"category":14,"tags":3288},[1463,1985],"2019-05-03","\n\nBusinesses continually adopt new technologies to become more efficient and\neffective. This move toward efficiency in IT has brought a “shift left” to\n[application security](/topics/devsecops/) testing. Methodologies like DevOps and Agile work with iterative\nand [MVP](https://www.agilealliance.org/glossary/mvp/) states, meaning that apps are constantly updating and constantly need\ntesting and retesting – sometimes daily or multiple times per day.\n\n[Serverless](/topics/serverless/), cloud native, containers, and Kubernetes are changing how apps are\ndeployed and managed. This has expanded the attack surface in the form of new\nlayers of complexity and more settings and updates to manage, which also means\nmore room for manual error. In a container, this includes the image, registry,\nand east-west traffic, while in Kubernetes, this includes access and\nauthentication, runtime resources, and network policies. Traffic between apps\nin a container does not cross perimeter network security, but should still be\nmonitored for malicious traffic between apps and the resources they use.\n\n## Your cloud-based ecosystem doesn’t provide comprehensive security\n\nCloud providers, orchestrators, and other partners don’t provide a full\nspectrum of security capabilities out of the box – even with their help, your\nteam must create and maintain their own security policies and continuously\nmonitor your ecosystem for any unusual or malicious activity. While network\nsegmentation and perimeter security for your guest VMs or containers might be\navailable, your engineer will typically need to configure that.\n\nThe figure below outlines the responsibilities of cloud providers, security\nvendors, and end-users, across apps, hosts, networks, and foundation services.\nThe responsibilities in purple and orange are _primarily_ the responsibility of\nthe cloud provider and security vendors, but our engineers tell us that they\nare involved in every cell of this chart in some way.\n\n![Security responsibilities in your cloud ecosystem](https://about.gitlab.com/images/blogimages/container-security-responsibilities.png){: .shadow.medium.center}\n\n## Treat security as a critical outcome, not a department\n\nSecurity should be top of mind for everyone in the business, not just your\nsecurity team. While the complexity of your infrastructure builds, new tools\nand capabilities give opportunity for everyone to contribute to the security\neffort. Here are a few areas of change that will help you rally the masses in\ndefense of your business:\n- Cloud providers are beginning to offer more security capabilities.\n- System updates – and staying current with your patches – could very much save the day.\n- Automating your processes could make or break the business. While guidelines\nfor humans are necessary, you need automation to abstract the complexity of\nyour infrastructure. Soon, automated capabilities to translate plain-language\npolicies into the growing multitude of settings will make their way into the\nmarket.\n\n### Take a Zero Trust approach to your applications\n\nThe foundational idea of [Zero Trust](/blog/evolution-of-zero-trust/) is simple: Trust nothing and always assume\nthe bad guys are trying to get in. It’s time to take your security beyond the\ntraditional network-perimeter approach and extend Zero Trust from data,\nnetwork, and endpoints to your application infrastructure. It also wouldn’t\nhurt to protect the software development lifecycle (SDLC) to ensure the integrity of your software is not\ncompromised, given all of the automation in a typical DevOps toolchain.\n\n## Three key principles to secure next-generation IT\n\n### 1. Enhance your security practices with DevSecOps\n\nAs you iterate on software, dovetail security into each iteration through [DevSecOps](/solutions/security-compliance/) – not simply\nto test security for the entire history of the app, but to test the impact of\neach change made in every update. Retrofitting your apps and software for\nsecure functionality will slow down your release cycle. Marrying the two\nwill save both time in the present, and heartache in the future when\nyour software is inevitably attacked. Unfortunately, traditional methods don’t\nfit the bill when it comes to DevOps; it’s too expensive and too robust to\nscan every piece of code manually. With a [shift left](/topics/ci-cd/shift-left-devops/) strategy, security scans can be automated into every\ncode commit – meaning you no longer need to choose between risk, cost, and\nagility.\n\n[Arm your developers to resolve vulnerabilities early in the SDLC, leaving your\nsecurity team free to focus on exceptions](/blog/speed-secure-software-delivery-devsecops/).\nWith GitLab, a [review app](/stages-devops-lifecycle/review-apps/) is spun up at code commit – before the\nindividual developer’s code is merged to the master. The developer can see and\ntest the working application, with test results highlighting the impact of the\ncode change. [Dynamic application security testing](https://docs.gitlab.com/ee/user/application_security/dast/) (DAST)\ncan then scan the review app, and the developer can quickly iterate to resolve\nvulnerabilities reported in their pipeline report.\n\n![View dynamic application security testing within GitLab.](https://about.gitlab.com/images/blogimages/dast-example.png){: .shadow.medium.center}\n[Learn more about DAST in GitLab's product documentation.](https://docs.gitlab.com/ee/user/application_security/dast/)\n\n### 2. Secure horizontally before digging deeper\n\nWe often fall into the trap of going deep on a single aspect of security –\nleaving other obvious aspects completely exposed. For instance, you may\nuse a powerful scanner for your mission-critical apps but neglect to scan\nothers; or, you may choose to save resources by not scanning your third-party\ncode, with the assumption that its widespread use means it’s checked out.\n\nAvoid focusing so much on application security that you forget about container\nscanning, orchestrators, and access management.\n\n### 3. Simplicity and integration wins\n\nThe key is to bring security scanning to the development process by having a\ntool like GitLab that allows developers to stay within the same platform or\ninterface to both code and scan. Making the process easier increases the\nlikelihood that it’ll get done – and making the process automatic within the\ntool ensures that it will happen every time there is a code update.\n\nReady to deliver secure apps with every update? [Just commit.](/solutions/security-compliance/)\n{: .alert .alert-gitlab-purple .text-center}\n\nCover image by [Frank McKenna](https://unsplash.com/@frankiefoto) on [Unsplash](https://unsplash.com/photos/tjX_sniNzgQ?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[723,806,1076,894],{"slug":3290,"featured":6,"template":681},"secure-containers-devops","content:en-us:blog:secure-containers-devops.yml","Secure Containers Devops","en-us/blog/secure-containers-devops.yml","en-us/blog/secure-containers-devops",{"_path":3296,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3297,"content":3303,"config":3308,"_id":3310,"_type":17,"title":3311,"_source":18,"_file":3312,"_stem":3313,"_extension":21},"/en-us/blog/trends-in-test-automation",{"title":3298,"description":3299,"ogTitle":3298,"ogDescription":3299,"noIndex":6,"ogImage":3300,"ogUrl":3301,"ogSiteName":667,"ogType":668,"canonicalUrls":3301,"schema":3302},"3 Trends in test automation","Faster deployments, fewer bugs, better user experiences – see the latest trends in test automation and what they're bringing to the table.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663662/Blog/Hero%20Images/trends-in-test-automation.jpg","https://about.gitlab.com/blog/trends-in-test-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 Trends in test automation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-05-01\",\n      }",{"title":3298,"description":3299,"authors":3304,"heroImage":3300,"date":3305,"body":3306,"category":14,"tags":3307},[1483],"2019-05-01","\nAutomation is becoming a powerful tool in every industry.\nWith the pace of development at breakneck speed, [test automation](/topics/devops/devops-test-automation/) is a big asset in deploying applications quickly.\nThe volume and complexity of testing environments mean that machines are well-suited for the job, and a modern QA strategy is all about leveraging that automation effectively.\n\n[QASymphony recently surveyed testers and QA leaders](https://www.qasymphony.com/blog/test-automation-trends-infographic/) at mid-size and large enterprises and found that a significant number of respondents expect to be making a big leap towards test automation in the next year:\nAlmost half expect to be automating more than 50 percent in that time.\nThe test automation tool landscape is growing more complex, and 83 percent of organizations are using open source tools.\n\n## 1. Continuous testing\n\nIn traditional environments, testing gets completed at the end of a development cycle.\nAs more teams move toward a [DevOps](/topics/devops/) and [continuous delivery](/topics/ci-cd/) model in which software is constantly in development, leaving testing until the end can be a huge liability.\nIn the time between a project starting and going to testing, master files could have been changed thousands of times.\nWho knows what kinds of bugs can pop up over months of development?\nThis leads to either updates stuck in testing for far too long or deployments filled with bugs – neither of which is good.\nThat’s where continuous testing comes in.\n\nContinuous testing starts at the beginning.\nEach milestone along the way serves as a quality gate, [baking in excellence at each stage of the software development process](https://techbeacon.com/app-dev-testing/state-test-automation-7-key-trends-watch).\nAs each phase clears, more testing happens as needed.\nImplementing continuous testing methodologies is _already_ the biggest trend in test automation, but some organizations that embark on their DevOps journeys struggle with it.\n\nSubu Baskaran, senior product manager for Sencha, says that despite the desire to test early in the cycle, software development teams that are still maintaining legacy applications find it hard to go back and write unit or end-to-end tests:\n\n>\"The millions of lines of code make it extremely difficult for teams to think about unit testing, as that will severely hamper new feature development. Also, legacy applications have inherent complexities that make end-to-end testing very slow, vague, and brittle. [Hence, teams that maintain legacy applications resort to manual testing.](https://techbeacon.com/app-dev-testing/state-continuous-testing-its-journey-not-destination)\"\n\n## 2. Concurrent DevOps\n\nCode quality and speed go hand in hand, and teams must be able to make use of parallelization to keep up the pace.\nSplitting work across multiple servers has never been easier, and organizations will continue to expand their concurrent DevOps approach.\n\nYou could have multiple physical machines to handle the load but [VMs can be a more economical option for automation parallelization](https://techbeacon.com/app-dev-testing/parallelizing-test-automation-read-first).\nWhether those VMs are on premises or cloud-based largely depends on the cost and your company's ability to embrace the cloud.\n\nYou could also work with cloud partners, companies that host cloud-based execution environments\nfor testing and automation.\n\nAutoscaling is one way that teams can reduce the costs associated with running these concurrent jobs.\n[Autoscaling runners](/releases/2016/03/29/gitlab-runner-1-1-released/) split this work across multiple servers and spin up or down automatically to process queues – so developers don’t have to wait on builds and teams use as much capacity as needed.\nThis user [built out a CI testing pipeline using GitLab](https://medium.freecodecamp.org/4-steps-to-build-an-automated-testing-pipeline-with-gitlab-ci-24ccab95535e) that allowed for more effective bug catching, and more DevOps teams will be using these methods to automate their testing environments in years to come.\n\n## 3. AI and machine learning\n\nAt its core, machine learning is a pattern-recognition technology, [the main purpose of which is to make machines learn without being explicitly programmed](https://hackernoon.com/why-ai-ml-will-shake-software-testing-up-in-2019-b3f86a30bcfa).\nWhat makes this such an important trend in test automation is that it can make testing more predictive and reliable.\nWhile Selenium is still the standard for creating testing scripts, it requires a high level of programming skill to maintain.\nAutomation tools like Mabl, [TestCraft](https://www.testcraft.io/), Testim.io, and AutonomiQ are just some of the few incorporating AI and machine learning into test automation.\n\nDan Belcher, co-founder of testing tool company Mabl, and his team [developed an ML testing algorithm that can adapt to changes in frontend elements](https://techbeacon.com/app-dev-testing/how-ai-changing-test-automation-5-examples).\n\"Although Selenium is the most broadly used framework, the challenge with it is that it's pretty rigidly tied to the specific elements on the front end. Because of this, script flakiness can often arise when you make what seems like a pretty innocent change to a UI.\" he explains.\n\"One of the things that we did at the very beginning of creating Mabl was to develop a much smarter way of referring to frontend elements in our test automation so that those types of changes don't actually break your tests.\"\n\nAI and machine learning make it possible to go through millions of lines of code and identify patterns.\nBut what happens to the human testers? QA automation means that testers can devote more time to superior user experiences – the tasks that machines are _not_ always well-suited for.\nThe role of testers is now [ensuring that quality testing processes are being followed](https://www.qasymphony.com/blog/managing-testing-teams/), so it’s more about oversight than conducting actual tests.\nModern QA can be that bridge for beautiful user experiences that are intuitive and appealing.\nWith the volume of applications being deployed every day, having a great user experience is a way to stand out in a sea of apps.\n\n## These trends in test automation are just the tip of the iceberg\n\nThere is no shortage of exciting things happening: more focus on JavaScript testing, improvements in testing across devices, comprehensive testing dashboards, as well as Selenium-free options.\nThe testing automation landscape is full of new solutions, but none of them is viable in an outdated legacy environment.\n\nManual testing reduces application development speed and threatens code quality.\nThese two disadvantages are growth killers, especially in such a competitive development landscape.\nTest automation makes it possible for testers to use their skills where they add more business value: Creating great user experiences.\nLegacy applications can’t tap into all of these test automation capabilities because they aren’t supported.\nOrganizations forced to manually test their code are being left in the dust by those who automate.\n\nThe advantage of using a solution like GitLab is that we can incorporate a variety of continuous testing solutions.\nCustomers have integrated us with SaaS-based testing solutions or even their own homegrown Selenium grids.\nWe also integrate with JavaScript platforms like Cypress.io, and help teams create continuous integration pipelines.\n\nAre you ready to explore these trends in test automation but legacy applications are holding you back?\n\n[Just commit.](/blog/application-modernization-best-practices/)\n{: .alert .alert-gitlab-purple .text-center}\n\nCover image by [Mimi Thian](https://unsplash.com/photos/ZKBzlifgkgw?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/%22developers%22?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,110,1255],{"slug":3309,"featured":6,"template":681},"trends-in-test-automation","content:en-us:blog:trends-in-test-automation.yml","Trends In Test Automation","en-us/blog/trends-in-test-automation.yml","en-us/blog/trends-in-test-automation",{"_path":3315,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3316,"content":3322,"config":3327,"_id":3329,"_type":17,"title":3330,"_source":18,"_file":3331,"_stem":3332,"_extension":21},"/en-us/blog/speed-secure-software-delivery-devsecops",{"title":3317,"description":3318,"ogTitle":3317,"ogDescription":3318,"noIndex":6,"ogImage":3319,"ogUrl":3320,"ogSiteName":667,"ogType":668,"canonicalUrls":3320,"schema":3321},"Speed up secure software delivery with DevSecOps","It’s time to shift left: Embed security into your DevOps workflow to increase speed, quality, and efficiency in the SDLC.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671258/Blog/Hero%20Images/just-commit-blog-cover.png","https://about.gitlab.com/blog/speed-secure-software-delivery-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Speed up secure software delivery with DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-04-30\",\n      }",{"title":3317,"description":3318,"authors":3323,"heroImage":3319,"date":3324,"body":3325,"category":14,"tags":3326},[1985],"2019-04-30","\n\nDevOps is a revolutionary step forward in efficient software delivery, but teams\noften face painful delays when releases are put through security testing.\nSecurity is critical for every digital entity, but often adds tension to a\nprocess that is already under pressure for speed and cost efficiency. For many,\nsoftware delivery resembles an assembly-line style of work where employees have\nto constantly stop and start their work on different projects, breaking\ntheir mental flow and straining relationships between teams.\n\nTo illustrate, let’s trade software for [Ford’s Model Ts](https://www.history.com/this-day-in-history/fords-assembly-line-starts-rolling)\nfor a minute. Software development closely resembles development of those first cars\nmanufactured by Ford: Each worker makes a contribution and hands off to the\nnext, and then the security pros take it for a test drive (or look for\nvulnerabilities). But if the car doesn’t function properly, it’s sent back to\nthe beginning of the line to the developers who have already begun working on\na different vehicle.\n\nBack to software. How can teams solve this back-and-forth without foregoing\nquality? They must embed security into the development workflow.\n\n## Integrate and automate end-to-end security\n\nWhen security is embedded into the developer workflow, developers can respond\nto vulnerability alerts _while_ they’re writing code. Within the developer's\npipeline report in GitLab, individual vulnerabilities are presented to the developer for\nreview. Alerts could include unsafe code, dangerous attributes, and other\nvulnerabilities that could put your application at risk. The developer is able\nto look into each alert, determine whether it needs to be addressed or can be\ndismissed, and then address each alert while moving through the\ndevelopment process. In the [Security Group Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), the security analyst is able to see which alerts the developer was unable to resolve as well as what\nwas dismissed, making sure no vulnerabilities slip through the cracks.\n\n### Gain speed and efficiency with DevSecOps\n\nEmbedded security checks allow developers to pass off a streamlined workflow to\ntheir security peers. Security then focuses on the most important risks and\nthreats with the typical mountain of checks reduced to a much shorter list.\nShortened test times lead to much faster releases: Wag! (a dog-walking app)\n[brought their release time down from 40 minutes to just six.](/blog/wag-labs-blog-post/)\n\nStandard release processes place an unnecessary burden on your teams when a\nlimited number of engineers can work on them and project handoff actually\nimpedes completion. The ability to work concurrently within the same environment\nrepresents much more than a shift left: It redefines the entire DevOps\nlifecycle, enabling greater efficiency and collaboration on a single source\nof truth.\n\n### How it works\n\n[Static application security testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\nbrings vulnerabilities to developers so they can review gaps in their code\n_within_ their own working environment before passing the project off to\nsecurity. This integration mitigates the friction that often stands between dev\nand security, allowing security to graduate from roadblock status to critical\nworkflow component. The collaborative nature of [SAST within tools like GitLab](https://docs.gitlab.com/ee/user/application_security/sast/)\nallows different teams to access the project at any time, eliminating any\ncumbersome linear processes and breaking down silos within the larger\norganization.\n\n## Accelerate delivery and build productivity by testing closer to remediation\n\nShifting left might ring alarm bells for some, but don’t worry – developers\nwon’t be solving _every_ security problem. The idea is to alert your dev team to\nthe code fixes that would be easiest for them to solve, rather than making the\nsecurity team do the digging. This switch will streamline the overall workflow,\nallowing the security team to focus on more critical risks and reducing handoff\nbetween security and dev.\n\n[DevSecOps](/topics/devsecops/) integrates security into your CI/CD processes, allowing your teams to\nwork quickly, collaborate efficiently, and produce secure and\nquality software at every release.\n\nAre you ready to build security into your DevOps practices? [Just commit.](https://about.gitlab.com/solutions/security-compliance/)\n{: .alert .alert-gitlab-purple .text-center}\n",[110,806,894],{"slug":3328,"featured":6,"template":681},"speed-secure-software-delivery-devsecops","content:en-us:blog:speed-secure-software-delivery-devsecops.yml","Speed Secure Software Delivery Devsecops","en-us/blog/speed-secure-software-delivery-devsecops.yml","en-us/blog/speed-secure-software-delivery-devsecops",{"_path":3334,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3335,"content":3340,"config":3346,"_id":3348,"_type":17,"title":3349,"_source":18,"_file":3350,"_stem":3351,"_extension":21},"/en-us/blog/avoiding-foreclosure-on-your-technical-debt",{"title":3336,"description":3337,"ogTitle":3336,"ogDescription":3337,"noIndex":6,"ogImage":3319,"ogUrl":3338,"ogSiteName":667,"ogType":668,"canonicalUrls":3338,"schema":3339},"How to avoid foreclosure on your technical debt","There’s no need to be embarrassed — we all have technical debt. Here’s how you pay it off.","https://about.gitlab.com/blog/avoiding-foreclosure-on-your-technical-debt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to avoid foreclosure on your technical debt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Jeremiah\"}],\n        \"datePublished\": \"2019-04-29\",\n      }",{"title":3336,"description":3337,"authors":3341,"heroImage":3319,"date":3343,"body":3344,"category":14,"tags":3345},[3342],"John Jeremiah","2019-04-29","\n\nHow much debt can you afford? We all live with some form of debt, whether it’s a student loan, a car loan, a mortgage, or a credit card balance. Debt doesn’t have to be a bad thing. It can be a tool that gives us leverage and flexibility to make large purchases. But there are limits to how much debt is reasonable and that’s where people get into trouble. If they take on too much debt, bad things can happen. \n\nWhat does this have to do with GitLab? Everything.\n\n## What is technical debt?\n\nAccording to [Martin Fowler’s excellent summary on technical debt](https://martinfowler.com/bliki/TechnicalDebt.html), it seems that [Ward Cunningham coined the term](https://www.youtube.com/watch?v=pqeJFYwnkjE) around 1993 as a metaphor to describe a typical pattern that occurs on software projects. Technical debt is a pattern in which a development team does not have enough time, information, or capacity to refine and refactor their code, so their architecture, implementation, and testing may be incomplete. The challenge with technical debt is similar to financial debt in that it doesn’t magically go away. Unless it is managed and paid down, technical debt will grow over time, just like the balance on your credit card bill.\n\n## How to reduce technical debt\n\nYou may feel overwhelmed but there is a reason to be optimistic. The power of rapid, continuous delivery combined with small, incremental changes can help you manage your technical debt and avoid “foreclosure.” Here are three things you can do today to get your “technical finances” in order:\n\n1. **Find your technical debt and document it.**  It’s hard to pay off all your bills if you don’t know what they are. Begin this process by creating a list of issues that capture your specific technical “bills.” Assign them `technical debt` and `priority` labels. You probably won’t be able to pay them all off at one time, but now you know where to start.\n\n1. **Embrace small changes.**  At GitLab, we embrace [Minimum Viable Change (MVC)](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc). The goal of MVC is to make small, incremental improvements. Your goal is to pay down your debt one micro payment at a time.  \n\n1. **Let continuous delivery automate your payments.**  You can’t automate the improvements, but you can leverage CI/CD automation to streamline the process of testing, validating, and deploying code changes for you. Continuous delivery removes the friction and bottlenecks between your developers and the “bank.”  \n\nTechnical debt is a reality in almost every software product in the world. The point about technical debt isn’t how to avoid it, but how to _manage_ it so that you’re not in a situation where you are forced to foreclose on your project because the technical debt is out of control. The tools are readily available. The question is: Are you ready to start managing your technical debt? [Just commit](/blog/strategies-to-reduce-cycle-times/) to your future.\n",[806,1255],{"slug":3347,"featured":6,"template":681},"avoiding-foreclosure-on-your-technical-debt","content:en-us:blog:avoiding-foreclosure-on-your-technical-debt.yml","Avoiding Foreclosure On Your Technical Debt","en-us/blog/avoiding-foreclosure-on-your-technical-debt.yml","en-us/blog/avoiding-foreclosure-on-your-technical-debt",{"_path":3353,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3354,"content":3359,"config":3364,"_id":3366,"_type":17,"title":3367,"_source":18,"_file":3368,"_stem":3369,"_extension":21},"/en-us/blog/align-business-strategy-and-app-delivery",{"title":3355,"description":3356,"ogTitle":3355,"ogDescription":3356,"noIndex":6,"ogImage":3319,"ogUrl":3357,"ogSiteName":667,"ogType":668,"canonicalUrls":3357,"schema":3358},"Deliver business value at the speed of business","Read here on how DevOps helps delivering business value with faster cycle times","https://about.gitlab.com/blog/align-business-strategy-and-app-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Deliver business value at the speed of business\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Jeremiah\"}],\n        \"datePublished\": \"2019-04-23\",\n      }",{"title":3355,"description":3356,"authors":3360,"heroImage":3319,"date":3361,"body":3362,"category":14,"tags":3363},[3342],"2019-04-23","\n\nWhat’s the point of DevOps and digital transformation? Is this just another “IT project”\nwith limited business value, or will they deliver _real_ value to the business?\n\nThe goal of digital transformation is to change the business with new models,\nnew services, new value, and new ways to connect with customers. Consider the\nobservations of the\n[World Economic Forum’s Digital Transformation Initiative](http://reports.weforum.org/digital-transformation/),\nwhere they argue that a digital transformation will lead to improved customer\nexperience and outcomes, efficiencies, and business models. One of the key ways\nto enable these changes is “agile and digital-savvy leadership” and a technology\ninfrastructure that is ready to respond to changing demands.\n\n**In order to succeed in your digital transformation strategy, you must be able\nto transform your technology delivery processes and platforms.**\n\n## What’s the solution?\n\nThe good news is that many of the key techniques to facilitate faster and more\nresponsive delivery are known. For the past decade, enterprises large and small\nhave found success with adopting DevOps principles to extend Agile project\nplanning to deliver business value at the speed of business. In many ways, DevOps\nis one of the key enablers to unlock the velocity needed for delivery teams to\nrespond to rapidly changing business objectives.\n\nAny sort of IT transformation, such as DevOps, must be defined as a business\ninitiative with tangible business outcomes. However, too often, initiatives like\nAgile and DevOps are relegated to be backbench, IT-focused projects that are set\nup to fail. If your Agile or DevOps transformation project isn’t closely linked\nto business objectives, or if it doesn’t have business stakeholders, then it’s\ntime to go back to the drawing board and re-make the business case to sell the\nvision. As IT leaders, you cannot go it alone.\n\n## Taking a closer look at your value stream\n\nSo, how do you operate and stay focused on business objectives as you accelerate\napplication delivery?  I’ve heard from many customers who find their\n“portfolio planning” process and tools disconnected from the actual work developers\nand delivery teams do. The problem they face is not having visibility into the\ncadence and delivery of new features and capabilities that the business has requested.\nWhile they try to integrate disparate tools to keep track of everything, they\nultimately end up using a patchwork spreadsheets/PowerPoint hybrid to create\ndashboards and reports in the hopes of keeping executives informed. It’s a waste\nof effort, error prone, and frustrating to pull all the data together over and over again.\n\nTo solve this alignment puzzle you need three things:\n\n1. Effective visibility and traceability between business initiatives, coding, and delivery.\n1. Commitment to Agile planning and prioritization.\n1. Automation of manual, error-prone tasks, such as testing, configuring, reporting, and tracking activities.\n\nLet's dig into those:\n\n### Increase visibility\n\nThe first step in achieving success is breaking through the barriers to\ncommunication and collaboration in your organization. Too many different tools,\nspreadsheets, PowerPoint decks, and islands of information create friction and\nconfusion. You need to consider how you can align your policies, processes, and\ntechnology enablers to encourage collaboration, sharing, and visibility into business\ninitiatives. Only then will you be able to respond to the rapidly changing business needs.\n\n### Simplify workflows\n\nIf visibility is the first step in your transformation, then your second step is\nembracing the reality that yesterday’s business plans and priorities may well\nchange tomorrow. The days of annual planning and long-running projects that\ndeliver only after months of effort are gone. The pace of change in the market\ndemands a comparable level of flexibility in our planning and prioritization.\n\n### Favor automation\n\nIf your most valuable assets are your people, then don’t ask them to waste their\ntime and talents on routine manual effort. To improve your ability to accelerate\napplication delivery, you need to examine your processes and policies and\nautomate your manual, repetitive, low-value tasks. This will unlock the untapped\npotential in your team while speeding up your pipeline and reducing error rates.\nThe power of [modern automation](/blog/application-modernization-best-practices/) is a\nkey driver to deliver at the speed of business.\n\nA successful transformation is not only possible, but also crucial to long-term\nsuccess in a market that is moving at a radically faster pace than it was a few\nyears ago. Now is the time to start.\n\nJoin us for an upcoming webinar in which we'll learn how\nsoftware delivery leaders play a vital role in the success of digital transformations.\n\n[Register now](/webcast/justcommit-reduce-cycle-time/)\n{: .alert .alert-gitlab-purple .text-center}\n",[806,1255],{"slug":3365,"featured":6,"template":681},"align-business-strategy-and-app-delivery","content:en-us:blog:align-business-strategy-and-app-delivery.yml","Align Business Strategy And App Delivery","en-us/blog/align-business-strategy-and-app-delivery.yml","en-us/blog/align-business-strategy-and-app-delivery",{"_path":3371,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3372,"content":3378,"config":3383,"_id":3385,"_type":17,"title":3386,"_source":18,"_file":3387,"_stem":3388,"_extension":21},"/en-us/blog/reduce-it-costs",{"title":3373,"description":3374,"ogTitle":3373,"ogDescription":3374,"noIndex":6,"ogImage":3375,"ogUrl":3376,"ogSiteName":667,"ogType":668,"canonicalUrls":3376,"schema":3377},"How to reduce IT costs","Four ways organizations can spend less on IT and more on innovation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680558/Blog/Hero%20Images/reduce-it-costs.jpg","https://about.gitlab.com/blog/reduce-it-costs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to reduce IT costs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-04-11\",\n      }",{"title":3373,"description":3374,"authors":3379,"heroImage":3375,"date":3380,"body":3381,"category":14,"tags":3382},[1483],"2019-04-11","\n\nEfficient organizations do _more_ with _less_ – it's just simple math, really.\nBut even as teams try to stay lean and agile, some IT budgets are anything but. In a [recent survey that analyzed IT spending](https://searchcio.techtarget.com/magazineContent/How-Company-Size-Relates-to-IT-Spending)\nbased on company size, small companies spend on average 6.9 percent of their revenue on IT\n(enterprise spending is usually around 3 percent). Out of this IT spending, [more than 70 percent goes toward maintenance](https://phoenixnap.com/blog/it-cost-reduction-strategy) – just keeping things running.\n\nIT cost reduction could help fund the innovations all companies need to stay competitive,\nbut therein lies the problem. How do you prioritize what stays and what goes when _everything_ feels important?\nReducing IT costs doesn't happen in a vacuum – teams across the organization depend on these decisions.\n\n## Where do I start?\n\n### Reduce on-premise IT\n\n[On-premise IT has several costs](https://ianmartin.com/10-strategies-top-cios-use-reduce-costs/):\nthe servers themselves, power and cooling, staff to maintain them, software licenses, and the\nadditional leased space needed to house it all. [Virtualization hosts multiple virtual instances](https://www.bmc.com/blogs/6-ways-reduce-ongoing-maintenance-management-costs/)\n(Virtual Machines, VMs) of an operating environment on the same machine, reducing the\nnumber of physical servers needed. Virtual environments offer more flexibility, containers\nthat run independently, and fewer costs over the long term.\nTaking on cloud-based architecture embodies doing more with less.\n\n### Evaluate toolchain-management costs\n\nThose that spend more on their IT needs aren't typically the top performers – they just have more stuff.\nEvery application and plugin creates another potential point of failure, and added complexity\nalmost always spoils the efficiency party. Those in charge of IT have to keep up with more\nmaintenance, more patches, more logins, which in turn leads to more IT staff and even more\ncomplexity. Look at your toolchain – plugins, applications, and licenses – and evaluate the costs.\nSeveral \"inexpensive\" licenses that look harmless in micro add up quickly in macro.\nThis doesn't even factor the ongoing costs (upgrades, management, additional staff).\n\nSo much are you paying for your toolchain? We created this handy calculator that shows the\nannual cost for 100 users using some of the most common DevOps tools.\n\n[How much is your toolchain?](/calculator/roi/)\n{: .alert .alert-gitlab-purple .text-center}\n\n### Follow best practices to reduce downtime\n\nDowntime is every team's tech nightmare. It's estimated that [the cost of downtime for an\naverage-sized company is over $7,000 per minute](https://www.datafoundry.com/blog/6-cost-reduction-strategies-enterprise-IT)\n(yikes), and it can have far-reaching implications: worse customer relationships, employee turnover,\nand it can scare off investors, just to name a few.\nWhen facing a budget crunch, it might seem minor to skimp on a few steps when you're confident\nof the outcomes, but doing it right the first time saves much more in the long run.\nFollowing best practices like user testing and code reviews takes time up front, but they lower the chance of costly mistakes.\n\n### Modernize applications and migrate to lower-cost infrastructures\n\nConsolidating tools and an aggressive approach to application modernization are going to\nbe the greatest opportunities for enterprises to save budget dollars.\nA recent survey of top enterprise architects found that [36 percent cited application rationalization as the primary initiative they're working on](https://www.itbusinessedge.com/slideshows/show.aspx?c=93453).\nAnother survey of 250 senior IT executives found that 58 percent of them said\n[the best way to cut IT costs was to modernize or migrate existing applications to a lower-cost IT infrastructure](https://www.itbusinessedge.com/cm/blogs/vizard/application-modernization-tops-it-agenda/?cs=41480).\n\nReducing IT costs is essential for scale and funding innovations that keep organizations competitive,\nbut making the right cuts requires prioritization. For savings in the long term keep these four objectives in mind:\n\n*   Reduce on-premise IT.\n*   Evaluate toolchain-management costs.\n*   Follow best practices to reduce downtime.\n*   Modernize applications and migrate to lower-cost infrastructures.\n\nIT cost reduction directly correlates to increased revenue, but it isn't always easy. It just requires a little commitment.\n\n[Just commit.](/blog/application-modernization-best-practices/)\n{: .alert .alert-gitlab-purple .text-center}\n\nCover image by [Thomas Jensen](https://unsplash.com/photos/qTEj-KMMq_Q?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/computer-servers?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[723,806],{"slug":3384,"featured":6,"template":681},"reduce-it-costs","content:en-us:blog:reduce-it-costs.yml","Reduce It Costs","en-us/blog/reduce-it-costs.yml","en-us/blog/reduce-it-costs",{"_path":3390,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3391,"content":3396,"config":3401,"_id":3403,"_type":17,"title":3404,"_source":18,"_file":3405,"_stem":3406,"_extension":21},"/en-us/blog/why-improving-continuously-speeds-up-delivery",{"title":3392,"description":3393,"ogTitle":3392,"ogDescription":3393,"noIndex":6,"ogImage":3319,"ogUrl":3394,"ogSiteName":667,"ogType":668,"canonicalUrls":3394,"schema":3395},"Why improving continuously speeds up delivery","How do you keep pace with rapid changes in technology? The answer is continuous improvement.","https://about.gitlab.com/blog/why-improving-continuously-speeds-up-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why improving continuously speeds up delivery\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Jeremiah\"}],\n        \"datePublished\": \"2019-04-09\",\n      }",{"title":3392,"description":3393,"authors":3397,"heroImage":3319,"date":3398,"body":3399,"category":14,"tags":3400},[3342],"2019-04-09","\n\nI just finished Tom Friedman’s latest book “[Thank You for Being Late: An\nOptimist's Guide to Thriving in the Age of Accelerations](https://www.amazon.com/dp/B01F1Z0QHA),”\nin which he explores how our world is accelerating and everything is happening\nfaster and faster.  He explores the impact on business, society, economy, and\nenvironment. It’s a fantastic read – at times sobering and others exciting. I\nthink a fundamental takeaway from his research is that, from now on, business\nleaders must learn how to transform their organizations to operate at faster cycle\ntimes than ever before. While that sounds great, the obvious question is: How?\n\n## Operational efficiency and speed\n\nOne of the classic business books on operational efficiency and speed is Dr. Eli\nGoldratt’s classic, [“The Goal”](https://www.amazon.com/gp/product/0884271951).\nIn “The Goal,” the main character, Alex is a plant manager responsible for turning\naround a failing manufacturing plant. He learns a valuable lesson from his son’s\nscouting troop on a camping trip. As the group hikes into the woods, they spread\nout, because the slower hikers can’t keep up with the faster ones. No matter what\nAlex tries, he can't seem to keep them together. Then, he makes a small adjustment\nthat changes everything. He puts the slowest hiker in the front so that the entire\ntroop moves along at the speed of the slowest hiker. It’s the same in your\ndevelopment lifecycle: The fastest you can go depends on the most time-consuming\nstep in the [end-to-end value stream](/solutions/value-stream-management/).\n\nSo, how do you identify the most time-consuming step in your value stream? This\ndaunting task can be accomplished by adopting DevOps practices. In\n[“The Phoenix Project”](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592)\nand subsequent blog posts, Gene Kim describes the\n[“Three Ways”](https://itrevolution.com/the-three-ways-principles-underpinning-devops/)\nfrom which all DevOps patterns arise. These philosophies boil DevOps down to a set\nof three principles that can help organizations increase efficiency and speed by\ncarefully examining the value stream:\n\n1. **The First Way: Systems Thinking** – This first way is a flow of value from the business to the customer – or from Dev to Ops.\n1. **The Second Way: Amplify Feedback Loops** – The second way is to gather feedback from the customer, the business – or from Ops back to Dev.\n1. **The Third Way: Culture of Continual Experimentation and Learning** – Think of the third way as many smaller feedback loops of learning and improvement.\n\nWhat Alex learned in “The Goal” is an important lesson to remember: No matter\nwhat you change, you can only go as fast as the slowest. The same is true in your\nvalue stream. The principles of continuous improvement, exemplified by Gene’s\nThree Ways and [Kaizen](https://en.wikipedia.org/wiki/Kaizen) can be a powerful\nforce to help drive incremental and lasting change.\n\n## Continuous improvement through small changes\n\nWhy should you adopt a Kaizen approach?  Because it works. Kaizen is a strategy\nthat refers to continuous improvement through small changes that result in major\nimprovement. When applied in a business setting, Kaizen has significant impact\non culture, productivity, and quality.\n\nWhen teams practice continuous improvement, they;\n\n- Start with understanding their value stream.\n- Look for bottlenecks and waste.\n- Prioritize what to improve (remember the hikers).\n- Experiment with a minor change and learn.\n\nIn principle, continuous improvement and [DevOps isn’t difficult](/topics/devops/), if you approach\nit from a perspective of Kaizen and Gene Kim’s “Three Ways.” However, the\ncomplexity of fragmented toolchains and processes, siloed incentives, and lack\nof collaboration often get in the way of making lasting improvements in software\ndelivery.\n\n## Increase your DevOps success and reduce cycle time\n\nTo set the speed in the competitive race of software innovation, I have three suggestions:\n\n1. **Simplify your scope.** Focusing improvement efforts on one specific value \nstream at a time narrows your efforts to hone in on major problem areas rather\nthan becoming overwhelmed.\n1. **Empower your team.** Giving your delivery team the authority to experiment and\nimprove enables innovation to become a focus.   \n1. **Measure your value stream.** Understanding your cycle time and identifying \nbottlenecks enables you to take an objective look at what's slowing you down.\n\nIncreasing your DevOps success and reducing cycle time through continuous\nimprovement can help your organization continuously improve your value stream.\nAt GitLab, we’re helping teams reduce cycle time with our approach to DevOps,\nwhich unifies teams to focus on delivering value.\n\nAre you ready to reduce cycle\ntime? [Just commit.](/blog/strategies-to-reduce-cycle-times/)\n{: .alert .alert-gitlab-purple .text-center}\n",[806,1255],{"slug":3402,"featured":6,"template":681},"why-improving-continuously-speeds-up-delivery","content:en-us:blog:why-improving-continuously-speeds-up-delivery.yml","Why Improving Continuously Speeds Up Delivery","en-us/blog/why-improving-continuously-speeds-up-delivery.yml","en-us/blog/why-improving-continuously-speeds-up-delivery",{"_path":3408,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3409,"content":3414,"config":3419,"_id":3421,"_type":17,"title":3422,"_source":18,"_file":3423,"_stem":3424,"_extension":21},"/en-us/blog/reduce-cycle-time-digital-transformation",{"title":3410,"description":3411,"ogTitle":3410,"ogDescription":3411,"noIndex":6,"ogImage":3319,"ogUrl":3412,"ogSiteName":667,"ogType":668,"canonicalUrls":3412,"schema":3413},"How to reduce cycle time when faced with the digital transformation","With every industry facing change at an accelerated pace, how do you quickly deliver value to customers?","https://about.gitlab.com/blog/reduce-cycle-time-digital-transformation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to reduce cycle time when faced with the digital transformation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Jeremiah\"}],\n        \"datePublished\": \"2019-03-19\",\n      }",{"title":3410,"description":3411,"authors":3415,"heroImage":3319,"date":3416,"body":3417,"category":14,"tags":3418},[3342],"2019-03-19","\n\nOver the past several years, the “hot topic” in the tech world has been digital\ntransformation, the act of accelerating software innovation to deliver value to\ncustomers at high speed. Technology and innovation create disruptions across every\nindustry – from retail to financial services – meaning everyone faces change at\na faster pace. [A recent study by the\nWorld Economic Forum](http://reports.weforum.org/digital-transformation/) found\nthat “digital transformation” impacts almost every sector and offers critical\nexamples of how mobile devices, internet of things, machine learning, and big\ndata collectively reshape our future. If you're an IT leader, you may ask yourself,\n“What is fast and how does my team go faster?”\n\n## What _is_ fast?\n\nThe first step in preparing for the digital transformation is to look at how you\nmeasure speed: cycle time.\n\niSixSigma has a great\n[definition of cycle time](https://www.isixsigma.com/dictionary/cycle-time):\n“The total time from the beginning to the end of your process, as defined by you\nand your customer. Cycle time includes process time, during which a unit is acted\nupon to bring it closer to an output, and delay time, during which a unit of work\nis spent waiting to take the next action.” In a nutshell, cycle time is the total\nelapsed time to move a unit of work from the beginning to the end of a physical process.\n\n>In a nutshell, cycle time is the total\nelapsed time to move a unit of work from the beginning to the end of a physical process.\n\nIt’s important to note that cycle time is not the same as\n[lead time](https://www.linkedin.com/pulse/what-lead-time-why-important-how-do-you-reduce-roland-lester/).\nCycle time tells you how efficient your development and delivery processes are,\nand lead time tells you how long customers wait for a new feature. If you have a\nlot of ideas in your backlog, you could have a short cycle time, but a long lead\ntime due to the backlog. However, if you can improve your DevOps lifecycle to\nachieve a fast cycle time, you can then rapidly respond to new business priorities.\n\n## How does your team go faster?\n\nSo, now you know how to measure speed, how do you reduce your cycle time, let\nalone your lead time?\n\n### Take stock first\n\nIt starts with understanding where your current delivery process has problems –\nwhere you’re creating\n[bottlenecks](https://about.gitlab.com/solutions/remove-bottlenecks/index.html),\nrework, or merely waiting for someone to do something. The objective of\n[value stream management](/solutions/value-stream-management/) is to define,\nmeasure, and improve the flow of value to your customers. In the case of IT and\napplication delivery, value stream management starts with your backlog of feature\nrequests and ends with the delivery of the features to your users.\n\n### Here’s a recipe to reduce cycle time:\n\n1. Measure your cycle time and lead time (cycle time is your process and lead time is what customers see).\n1. Identify the bottlenecks in your value stream (those things that stretch your cycle time).\n1. Improve your processes, automate, and streamline your value stream.\n1. Repeat step 1.\n\nIf you’re concerned about how the digital transformation will impact your business, I\nhighly recommend the\n[Digital Transformation Initiative Executive Summary](http://reports.weforum.org/digital-transformation/wp-content/blogs.dir/94/mp/files/pages/files/dti-executive-summary-20180510.pdf),\na fantastic report that’ll provide you with a comprehensive understanding of how\nit will create business value. As you improve your cycle time, you’ll be able to\nlower your lead time, because your delivery processes will be faster and more\nefficient. The key is to measure, understand, and improve your process.\n\nAre you ready to tackle the digital transformation? [Just commit.](/blog/strategies-to-reduce-cycle-times/)\n",[1255,806],{"slug":3420,"featured":6,"template":681},"reduce-cycle-time-digital-transformation","content:en-us:blog:reduce-cycle-time-digital-transformation.yml","Reduce Cycle Time Digital Transformation","en-us/blog/reduce-cycle-time-digital-transformation.yml","en-us/blog/reduce-cycle-time-digital-transformation",{"_path":3426,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3427,"content":3432,"config":3436,"_id":3438,"_type":17,"title":3439,"_source":18,"_file":3440,"_stem":3441,"_extension":21},"/en-us/blog/reduce-cycle-time",{"title":3428,"description":3429,"ogTitle":3428,"ogDescription":3429,"noIndex":6,"ogImage":3319,"ogUrl":3430,"ogSiteName":667,"ogType":668,"canonicalUrls":3430,"schema":3431},"Want to reduce cycle time? Commit to a new approach.","We have a new way of looking at cycle time. Let’s talk about it.","https://about.gitlab.com/blog/reduce-cycle-time","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want to reduce cycle time? Commit to a new approach.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-03-04\",\n      }",{"title":3428,"description":3429,"authors":3433,"heroImage":3319,"date":3434,"body":3435,"category":14},[1635],"2019-03-04","\nTraditionally, software leaders use `cycle time` to refer to [the time between\nstarting and delivering software](https://www.isixsigma.com/tools-templates/software/software-projects-cycle-time-%E2%90%98are-we-there-yet%E2%90%99/).\nMore specifically, it's the time between an engineer beginning work on an\nissue/feature and when that code is finally deployed to production and accessible\nto users. Historically, this definition has arisen from a siloed view of software\ndevelopment. Engineering leaders talk about the cycle time that affects engineering,\nbut they don't include the planning cycle time that the PMO contributed before\nthe project was handed off to the engineering org. Ultimately, this widely accepted\ndefinition of cycle time doesn't fully capture every stage of the software development lifecycle.\n\nWe've seen how powerful it can be when teams collaborate rather than work in silos,\nso we recommend including the planning stage when measuring cycle time. By measuring\ncycle time in this way, you capture the full efficiency of your end-to-end process,\nwhich can help you focus on finding and fixing inefficiencies across the full\nlifecycle of your software – not just one part of it.\n\n## A new perspective on cycle time\n\n{::options parse_block_html=\"true\" /}\n\n\u003Cdiv class=\"panel panel-success\">\n\n**CYCLE TIME**\n{: .panel-heading}\n\n\u003Cdiv class=\"panel-body\">\n\n/ˈsīk(ə)l/ /tīm\n\n_noun_\n\n1. The elapsed time between starting to work on an idea and delivering to production.\n1. A determining factor in whether organizations can meet business demands while delivering value to customers.\n\n\u003C/div>\n\u003C/div>\n\n{::options parse_block_html=\"false\" /}\n\nThis new understanding of cycle time covers the entire software development\nlifecycle and accounts for the time invested in planning what actions\nto take to ship an idea. The planning stage of the software development lifecycle\nis one of the most crucial components, because it builds the foundation for\nworkflows, project management, and resource allocation.\n\n>Cycle time is a metric that measures the amount of time in a process between the start,\nwhich often begins with an idea, and the end when it’s finally in the hands of customers.\n\nReducing cycle time is a competitive advantage, and this new perspective enables\nteams to take an end-to-end approach to rapid delivery.\n\n## Why you should reduce cycle time\n\nSince software touches nearly every aspect of daily life, reducing the time\nbetween thinking of an idea and having the code in production is vital to\nproviding value to customers. Maintaining velocity is an important step in\nlistening to customers and meeting business demands. Because the market moves\nso quickly, organizations must find ways to simplify processes to empower teams\nto focus on delivering value to customers faster. When teams aren’t picking\nthrough tangled processes, they can quickly ship code and innovate to create\nfeatures that customers want.\n\n>“Cycle time compression may be the most underestimated force in determining winners and losers in tech.” — [Marc Andreessen](https://medium.com/digital-customer-experience/the-untapped-creative-potential-of-big-data-39dfe1916d07)\n\nWhen organizations experience long cycle time, they risk losing market share.\nSince competitors are faster to market and can rapidly respond to customer\nneeds, organizations with slow cycle time are left behind to perfect the\npast needs of users. Organizations face lost revenue and opportunities,\nsince they’re unable to react quickly to changing market needs. A build-up of\ntechnical debt and rising costs make problems worse, and organizations are\nforced to play catch-up with their competitors.\n\nOrganizations that rapidly deliver see an increase in the number of projects and\nbudgets that stay on track, with developers spending more time delivering new\nfunctionality rather than fixing defects, and faster response to constantly\nevolving customer needs.\n\nIf organizations want to differentiate their software and gain market share,\nreducing cycle time should be a business imperative.\n\n## How to start\n\nThere are several ways to reduce cycle time, but the two most immediate ways to\nrapidly see your ideas in the hands of customers is to increase visibility and\nadopt a CI/CD approach to development.\n\n### Visibility\n\nTeams require end-to-end visibility and traceability of issues\nthroughout the software development lifecycle – from idea to production – in\norder to ship features at the speed customers demand. An increase in visibility\nreduces silos and facilitates collaboration, ensuring that everyone is aware of\nwhat’s going on and where they’re needed. To give you an example of the power of\nvisibility, let's take a look at GitLab. If we calculated the average time to\ndeliver all the features in [11.8](/releases/2019/02/22/gitlab-11-8-released/), it would\nbe 250 days. With an increase in visibility, we're able to see that some features\nwe shipped took only 30 days, while others were in our backlog for three years.\nSince we're on a monthly release cadence, knowing that many of our features were\nstarted and delivered in 30 days helps us determine whether we're quickly\ndelivering value to our customers.\n\n### Continuous integration and continuous delivery\n\nQuickly delivering what customers\nwant requires a modernized software development lifecycle that saves time,\neffort, and cost. According to a 2017 Forrester Wave report, “CI enables software\ndevelopment teams to work collaboratively, without stepping on each other’s toes,\nby automating builds and source code integration to maintain source code integrity.”\nA [continuous delivery](/topics/ci-cd/) approach automates testing and deployment capabilities so\nthat software can be developed and deployed rapidly and reliably.\n\nAre you ready to reduce cycle time? **[Just commit](/blog/strategies-to-reduce-cycle-times/)**.\n",{"slug":3437,"featured":6,"template":681},"reduce-cycle-time","content:en-us:blog:reduce-cycle-time.yml","Reduce Cycle Time","en-us/blog/reduce-cycle-time.yml","en-us/blog/reduce-cycle-time",{"_path":3443,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3444,"content":3449,"config":3455,"_id":3457,"_type":17,"title":3458,"_source":18,"_file":3459,"_stem":3460,"_extension":21},"/en-us/blog/beyond-application-modernization-trends",{"title":3445,"description":3446,"ogTitle":3445,"ogDescription":3446,"noIndex":6,"ogImage":3319,"ogUrl":3447,"ogSiteName":667,"ogType":668,"canonicalUrls":3447,"schema":3448},"Beyond trends: Committing to application modernization","How to overcome analysis paralysis and take your digital transformation efforts from theory to practice.","https://about.gitlab.com/blog/beyond-application-modernization-trends","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Beyond trends: Committing to application modernization\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2019-02-25\",\n      }",{"title":3445,"description":3446,"authors":3450,"heroImage":3319,"date":3452,"body":3453,"category":14,"tags":3454},[3451],"Erica Lindberg","2019-02-25","\n\nJust commit. What’s so hard about that? In truth, there’s a reason why commitment phobia is a punchline and it’s tough to settle on a place to go to dinner, let alone make a critical choice like when or [how to start the application modernization process](/blog/application-modernization-best-practices/).\n\nFor starters, there are so many questions to ask. For example:\n\n  1. What is the status quo of each software initiative?\n  1. Which applications are driving value for the business? Which aren’t?\n  1. When and how should I break my monolith into microservices? What’s the risk?\n  1. Should I move to the cloud – private, public, hybrid?\n  1. Everyone is talking about containers and Kubernetes, do I need this?\n\nThis is by no means an exhaustive list, but a sample of what might come up when considering where and how to start a digital transformation journey. Questions, buzzwords, and trends abound, and it can be easy to get trapped by analysis paralysis until enough time has gone by that indecision has become the decision.\n\nAccording to [Forrester’s Predictions 2019](https://go.forrester.com/blogs/tag/predictions-2019/), 25 percent of firms will decelerate digital efforts in 2019. For many organizations, slowing the pace of innovation directly results in lost market share due to more nimble competitors entering their space.\n\n> “In 2019, digital transformation moves from super-wide enterprise efforts to a pragmatic, surgical portfolio view of digital investments with the goal of making incremental and necessary changes to operations. – Forrester Predictions 2019\n\nThe key to starting and committing to the application modernization process is to start small and scale up as you learn. Following trends is not going to bring the organizational change needed for a successful digital transformation. It takes practical, incremental, and iterative progress.\n\nHere are a few practical steps for getting started:\n\n## 1. Start small with a small team or innovation group and scale up from there.\n\nTrying to make a decision on how to proceed with digital transformation across your entire organization is a monumental task. You risk introducing a lot of variable change all at once that can turn chaotic if not managed well. Starting with a small team or innovation group reduces the stress and minimizes the initial impact of getting started. [Behavioral science experts call this the “pick one and go” method](https://bsci21.org/9-tips-to-avoid-paralysis-by-analysis/) for overcoming analysis paralysis. Essentially, if you are overwhelmed or unsure about all of your options, just pick one and try it. Collect feedback, evaluate the outcome, iterate, and scale up from there.\n\nWhen choosing a team or developing an innovation group, avoid thinking along legacy lines which divide teams by stages of the software lifecycle. Think about building a cross-functional team of 8–12 people who can focus on developing the culture, process, and tools needed to continuously deliver software.\n\n## 2. Make smaller changes.\n\nKeep in mind that the impetus for digital transformation and, more specifically, application modernization, is driven from a business need to deliver value to customers faster. So, making smaller changes to release faster is the single most important change you can make.\n\nAdopt the mindset: what is the smallest possible change I can make to improve something, and how do I get it out as quickly as possible? At GitLab, we call this the [minimally viable change (MVC)](/handbook/product/product-principles/#the-minimal-viable-change-mvc), and it’s what allows us to ship nearly anything within a single release. This is especially important when approaching legacy software. If you start making a ton of big changes over a few weeks, the risk of breaking something and not understanding what change caused the error grows exponentially with every change.\n\nWith an MVC mindset, you can experiment with what works best without risking downtime. Smaller changes are easier to review, understand, and roll back if necessary.\n\n## 3. Prioritize mastering continuous delivery and deployment (CD).\n\nYou have your team assembled, you’ve made MVC your mantra, and now it’s time to establish a clear goal. If you’re just [starting down the application modernization road](/blog/application-modernization-examples/), chances are that you don’t quite know what strategy is going to work for your organization yet (that’s what the innovation group is for!). What you do know is that you need to be able to ship features to production faster while maintaining stability and security. By prioritizing understanding your current deployment pipeline and how to [automate to achieve continuous delivery](/topics/continuous-delivery/), you discover how the underlying infrastructure needs to change.\n\nAuthor Gary Gruver outlines this philosophy in his book, [\"Starting and Scaling DevOps in the Enterprise\"](/resources/scaling-enterprise-devops/). He writes:\n\n> It is my personal experience that creating, documenting, automating, and optimizing deployment pipelines in large software/IT organizations is key to improving their efficiency and effectiveness. – Gary Gruver\n\nStart with a single application and document how a change goes from idea all the way to production and monitoring. This will give you a good understanding of how it’s currently operating, what its dependencies are, and how you can start to decouple.\n\nFinally, the end goal is to enable teams with [fully automated CI/CD pipelines](https://docs.gitlab.com/ee/topics/autodevops/) so developers can get their code to production faster. Taking both a cultural and technological approach to change is needed to adopt DevOps methodology.\n\nAre you ready to commit to your digital transformation journey? [Get inspired and learn how Ask Media Group modernized their architecture and development with microservices, containers, and kubernetes](/webcast/cloud-native-transformation/).\n",[1447,110,806],{"slug":3456,"featured":6,"template":681},"beyond-application-modernization-trends","content:en-us:blog:beyond-application-modernization-trends.yml","Beyond Application Modernization Trends","en-us/blog/beyond-application-modernization-trends.yml","en-us/blog/beyond-application-modernization-trends",{"_path":3462,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3463,"content":3468,"config":3474,"_id":3476,"_type":17,"title":3477,"_source":18,"_file":3478,"_stem":3479,"_extension":21},"/en-us/blog/just-commit-launch",{"title":3464,"description":3465,"ogTitle":3464,"ogDescription":3465,"noIndex":6,"ogImage":3319,"ogUrl":3466,"ogSiteName":667,"ogType":668,"canonicalUrls":3466,"schema":3467},"Let’s talk about commitment","What possibilities could you unlock by just making the choice, committing, and moving forward?","https://about.gitlab.com/blog/just-commit-launch","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Let’s talk about commitment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Todd Barr\"}],\n        \"datePublished\": \"2019-02-18\",\n      }",{"title":3464,"description":3465,"authors":3469,"heroImage":3319,"date":3471,"body":3472,"category":14,"tags":3473},[3470],"Todd Barr","2019-02-18","\n\nWe’re now solidly into 2019. Commitments you made to yourself, your health, your productivity, your career, your budget, or whatever the case may be – they’re probably becoming harder to keep. This pattern of making resolutions, being on our best behavior for a while, falling off the wagon, returning to our ways, then starting the whole process over in the new year is all too familiar.\n\nWith [50 percent of digital transformation efforts stalled in 2018](https://mktg.forrester.com/predictions-2019), you’ve likely experienced your own version of this at work, and are probably even somewhere in that cycle right now.\n\nThe thing is, commitment unlocks new potential. You often don’t get to the good stuff until you make that commitment – whether it’s committing to months of training and discipline, then experiencing the euphoria of completing your first marathon, or committing to your partner and building a life together.\n\nIn the software space, making that commitment can be the difference between paying lip service to DevOps transformation and actually realizing its promises. Making big changes, especially at an organizational level, is daunting. The trick is to commit to the process, not just to the goal. [Focusing on the processes and behaviors that support the goal is key to success](https://www.scienceofpeople.com/goal-setting/), so having a clear plan of attack rather than an abstract objective to achieve is what makes all the difference.\n\nHere at GitLab, we committed to being [all-remote](/company/culture/all-remote/) – allowing us to hire the best people, no matter where in the world they might be or at what times they choose to work. We went all in on [asynchronous communication](/handbook/communication/#internal-communication), conscientiously documenting everything so we could collaborate across time zones and borders. We committed to a monthly release cycle, a decision which has seen us ship, to date, 88 consecutive new releases, allowing us to work with a short feedback loop and make small adjustments and iterations along the way. It was our commitment to the process, to having a single vision and steadily marching toward it, that enabled us to build a single application for the entire DevOps lifecycle with an all-remote team.\n\nSo this is what we’re asking you to do! Just commit. To software modernization. To faster cycle times. To secure apps. And because commitment is easier when you have a plan, and accountability, we’re here to support you on the journey. Over the coming weeks, we will be rolling out a series of blog posts and guides to help you make meaningful, lasting change in your organization. From tips and success stories on how to modernize your application architecture, to finally getting on top of technical debt, and building more secure applications, we’re working with our experts, customers, and community to help you along the way.\n\nObviously, commit has a double meaning for us. Git unlocked a whole new way to collaborate on software with the humble commit. Now, at GitLab, committing unlocks a whole lot more value – faster time to market, more secure code, more modern applications. We’re asking you to just commit to these. [Are you up for the challenge?](/blog/application-modernization-best-practices/)\n\n## #JustCommit\nSo, you're committing to starting something new this year. Hooray! 🎉 It's always easier to stick to something with a buddy – tell us your commitments by tweeting us [@gitlab](https://twitter.com/gitlab) using #JustCommit, and we'll do our best to help (and enter you into our swag giveaway)! The [giveaway](/community/sweepstakes/) lasts through April, but we want to keep you committing all year long.\n",[806,973,676],{"slug":3475,"featured":6,"template":681},"just-commit-launch","content:en-us:blog:just-commit-launch.yml","Just Commit Launch","en-us/blog/just-commit-launch.yml","en-us/blog/just-commit-launch",{"_path":3481,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3482,"content":3488,"config":3493,"_id":3495,"_type":17,"title":3496,"_source":18,"_file":3497,"_stem":3498,"_extension":21},"/en-us/blog/2019-developer-survey-announcement",{"title":3483,"description":3484,"ogTitle":3483,"ogDescription":3484,"noIndex":6,"ogImage":3485,"ogUrl":3486,"ogSiteName":667,"ogType":668,"canonicalUrls":3486,"schema":3487},"The 2019 Global Developer Survey is now open! Share your thoughts to shape the industry.","What do you need in order to thrive? From fewer delays in the development process to early detection of security vulnerabilities, we want to identify what you need to move ideas into action.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679930/Blog/Hero%20Images/2019-developer-survey-cover.png","https://about.gitlab.com/blog/2019-developer-survey-announcement","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The 2019 Global Developer Survey is now open! Share your thoughts to shape the industry.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-01-23\",\n      }",{"title":3483,"description":3484,"authors":3489,"heroImage":3485,"date":3490,"body":3491,"category":14,"tags":3492},[1635],"2019-01-23","\n\nAs software professionals, you are the creators, builders, researchers, and\nproblem solvers of technology, and your opinions should be the pulse of the\nindustry. We passionately believe that [everyone can contribute](/company/mission/#mission),\nso we created the Global Developer Survey as a way to help you influence the way\nyou, your team, and your managers code, test, and deploy. By voicing your\nthoughts in the Developer Survey, you can shape a solution-focused approach\nto industry-wide challenges. We hope that, together, we can drive industry\ndialogue around the needs of today’s software professionals, sparking a movement\nto remove roadblocks and focus on helping teams thrive.\n\nWe'll examine the findings from the Developer Survey and provide a summary and\nanalysis in the Developer Report, which will be published in May.\nThis comprehensive report dissects cross-functional relationships and offers insights\ninto successful practices, problem areas, and potential solutions. In our\n[previous reports](/developer-survey/), we explored what teams need in order to\ndo their best work. This year, we want to uncover what software professionals\nneed in order to rapidly innovate. Whether you need more accurate estimates on\nplanning features, a decrease in development process delays, or early detection\nof security vulnerabilities, we want to identify your needs. Learn more and [share on Twitter](https://twitter.com/gitlab/status/1088116356405518343).\n\n## How the survey works\n\nThe survey takes less than 20 minutes to complete and includes\napproximately 45 questions. The survey is anonymous, and the data and results\nwill be reviewed in aggregate. We’re covering a large range of topics this year,\nincluding delays in the development lifecycle, planning features, and security analysis.\n\nTo ensure that the Developer Survey asks the right questions to elicit strong\nfindings, the UX research team collaborated on the survey, and we tested the\nquestions with the GitLab engineering team to gather feedback and suggestions\nfor improvement.\n\nThe survey is open to anyone involved in software engineering – from developers\nand engineers and security professionals to DevOps managers and IT executives.\nIf you're involved in software engineering, we'd love to hear your thoughts!\n\n## Swag and iPad Pro giveaway\n\nWe’re so grateful that you’re partnering with us to learn about the industry,\nso we’re giving away five GitLab messenger bags and one iPad Pro! Each week, we’ll\nrandomly select one respondent to receive a messenger bag. To enter to win the\niPad Pro, please take the survey, share the survey on social, and send a link to your\npublic post to giveaways@gitlab.com. We’ll randomly select a winner when the\nsurvey closes. Good luck! We hope you win. 😃\n\n## Frequently asked questions\n\n**What is the Global Developer Survey?**\n\nThe Developer Survey is an anonymous questionnaire that gathers insights from software\nprofessionals to reflect the growing needs and viewpoints of the industry.\n\n**What is the Global Developer Report?**\n\nThe Global Developer Report is a summary and analysis of the findings gathered in\nthe Developer Survey. It dissects cross-functional relationships and offers\ninsights into successful practices, problem areas, and potential solutions.\n\n**What is GitLab’s role?**\n\nWhile the Developer Report is published by GitLab, it’s not about GitLab. As\nsoftware professionals, your words have the power to shape the industry, inform\nleadership, and set trends, and your thoughts drive the survey. GitLab only\nwants to help you amplify your voices. \n\n**When does the survey open/close?**\n\nThe survey [opened on Jan. 23](https://twitter.com/gitlab/status/1088116356405518343) at 8am PT and closes on Feb. 27 at 11:59pm PT.\n\n**How do I win a prize?**\n\nTo enter to win a messenger bag, please complete the survey and enter your email address.\nTo enter to win the iPad Pro, please take the survey and enter your email address, share\nthe survey on social, and send a link to your public post to giveaways@gitlab.com.\n\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fab fa-gitlab\" style=\"font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \n[Take the survey](https://www.surveymonkey.com/r/KY2WBCK)\n  \u003Ci class=\"fab fa-gitlab\" style=\"font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\n*You must complete the survey and provide an email address to be eligible to\nwin a prize. Your privacy is important to us, so email addresses will only be used for the\ngiveaway draw and will not be saved.* [Please read the official sweepstake\nrules here.](https://about.gitlab.com/community/sweepstakes/2019-developer-survey.index.html)\n{: .note}\n",[722,806,268],{"slug":3494,"featured":6,"template":681},"2019-developer-survey-announcement","content:en-us:blog:2019-developer-survey-announcement.yml","2019 Developer Survey Announcement","en-us/blog/2019-developer-survey-announcement.yml","en-us/blog/2019-developer-survey-announcement",{"_path":3500,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3501,"content":3506,"config":3512,"_id":3514,"_type":17,"title":3515,"_source":18,"_file":3516,"_stem":3517,"_extension":21},"/en-us/blog/what-to-expect-at-predict-2019",{"title":3502,"description":3503,"ogTitle":3502,"ogDescription":3503,"noIndex":6,"ogImage":2420,"ogUrl":3504,"ogSiteName":667,"ogType":668,"canonicalUrls":3504,"schema":3505},"2019 cloud native predictions from the Predict 2019 Conference","Break out your sunglasses, because the cloud native forecast for 2019 is sunny.","https://about.gitlab.com/blog/what-to-expect-at-predict-2019","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2019 cloud native predictions from the Predict 2019 Conference\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tina Sturgis\"}],\n        \"datePublished\": \"2018-12-12\",\n      }",{"title":3502,"description":3503,"authors":3507,"heroImage":2420,"date":3509,"body":3510,"category":14,"tags":3511},[3508],"Tina Sturgis","2018-12-12","\n\nGet the latest 2019 predictions from GitLab and other industry experts. [Sign me up](https://predict2019.com/#join-us)!\n{: .alert .alert-info}\n\nI love this time of year!  But it isn't for the reasons you may be thinking ... it's not the holiday decorations, shopping for gifts for loved ones ... it is about PREDICTIONS! Yep, I am a prediction junkie! I love to stop, do a little research as the end of December rolls around, reflect on what happened in that year, and begin to forecast trends I believe will emerge in the new year.\n\nThis year, one of the most exciting areas I wanted to dive into a prediction of is [cloud native](/topics/cloud-native/). It is no longer just a ‘fad,’ enterprises are realizing benefits from adopting cloud native. So I got together with my closest GitLab team-members and we dove in to provide you with our top five predictions.\n\n## Top predictions around cloud native\n\nThe basis for cloud native applications to flourish has been set and we believe that 2019 will be a great cloud native year.\n\n* Enterprises will adopt a [multi-cloud strategy](https://medium.com/gitlab-magazine/multi-cloud-maturity-model-2de185c01dd7) for their long-term investments.\n* The cloud native stack is maturing with tools like Kubernetes, Prometheus, and Envoy.\n* We are going to see a lot more on [serverless](/topics/serverless/) with the likes of Lambda and Knative.\n* We will see some real movement in the application of artificial intelligence and machine learning.\n\n## What about DevOps and security predictions?\n\nOnce we completed our research and position on cloud native predictions, we teamed up with [DevOps.com](https://www.devops.com) to participate in their on-demand virtual conference, [Predict 2019](https://predict2019.com/#join-us), that includes predictions around cloud security, DevOps, and quality testing with a [cast of speakers](https://predict2019.com/#speakers) that will educate and inspire you as you move into 2019!\n\n[Sign up now to attend Predict 2019](https://predict2019.com/#join-us)!\n{: .alert .alert-info}\n\nPhoto by [Marc Wieland](https://unsplash.com/photos/zrj-TPjcRLA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/clouds?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,1076,723,278],{"slug":3513,"featured":6,"template":681},"what-to-expect-at-predict-2019","content:en-us:blog:what-to-expect-at-predict-2019.yml","What To Expect At Predict 2019","en-us/blog/what-to-expect-at-predict-2019.yml","en-us/blog/what-to-expect-at-predict-2019",{"_path":3519,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3520,"content":3526,"config":3531,"_id":3533,"_type":17,"title":3534,"_source":18,"_file":3535,"_stem":3536,"_extension":21},"/en-us/blog/aws-pre-event-post",{"title":3521,"description":3522,"ogTitle":3521,"ogDescription":3522,"noIndex":6,"ogImage":3523,"ogUrl":3524,"ogSiteName":667,"ogType":668,"canonicalUrls":3524,"schema":3525},"Our top 6 tips for making the most of AWS re:Invent","Here are our top tips, tricks, and not-to-be missed for AWS 2018.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678889/Blog/Hero%20Images/IMG_4756.jpg","https://about.gitlab.com/blog/aws-pre-event-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our top 6 tips for making the most of AWS re:Invent\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"William Chia\"}],\n        \"datePublished\": \"2018-11-19\",\n      }",{"title":3521,"description":3522,"authors":3527,"heroImage":3523,"date":3528,"body":3529,"category":14,"tags":3530},[3131],"2018-11-19","\nThis year's AWS re:Invent, Nov. 26-30, looks to be an amazing show. [GitLab works great together with AWS](/partners/technology-partners/aws/) and as an [AWS partner](/partners/#strategic-partners) we're excited to be a part of the show. To help you prepare, the team has put together some top tips for getting the most out of re:Invent, along with a list of all the places you can find GitLab on site.\n\n## Top 6 tips for AWS\n\n### 1. Strategize\n\nKnow what is a must-do/-see for you and plan accordingly, including all talks and networking events. The week has so much going on and you, unfortunately, cannot do it all, so prioritize what is most important to you, and what you will get the most value out of.\n\n### 2. Manage your time\n\nAll transportation takes longer than you think it will or should during your time in Las Vegas. The conference footprint is huge. Give yourself a buffer to get to talks and plan on arriving early if you want to attend some of the more popular talks.\n\n### 3. Set goals\n\nIt is easy to get sidetracked, so having a set list of things you want to accomplish or a reminder of why you have chosen to invest your resources and time to be there can be key. When you are starting to wear down on the morning of day three and need to remind yourself why you came, a list of goals can help you get out of bed 😃\n\n### 4. Take care of yourself\n\nThis is a simple tip that can make all the difference during networking and negotiations. It is a long week and to make the most of it you do need to practice some self-care. Hydrate regularly, eat meals at regular hours, and stick to your exercise routine. Bring your most comfortable shoes instead of your best looking ones. You will thank yourself when you are walking the strip for the 30th time. Actually, bring two pairs of comfortable shoes. Having the option to switch it up if one pair is rubbing you the wrong way can turn a frustrating experience into a non-issue.\n\n### 5. Pack your go-bag the night before\n\nBring a full stock of business cards and external power banks. The days are long and networking strong. Make sure to charge all your devices overnight and don't forget anything you may need for a full day away from your hotel.\n\n### 6. Be open to learning and new experiences\n\nThis takes us back to the underlying question of why we gather at conferences such as re:Invent. Simply put, to learn from thought leaders and our peers. You are there to connect, share best practices, and expand your point of view. Hopefully, you'll leave with some new approaches, more solutions, and more questions to explore when you get home. Plan on taking notes of your interactions and the connections you make. At GitLab, we create issues for all actionable takeaways from the event. This is a great way for us to make sure the info doesn't get lost and gets disseminated to the rest of the team.\n\n## Come join GitLab at AWS 2018\n\nGitLab will be on site in Las Vegas with pleny of demos and tutorials you won't want to miss.\n\n### Sign up to book a time with GitLab\n\nre:Invent can be an extraodinarily busy event with more people to meet and things to see than you'll have time for. To ensure you get time to talk with the GitLab experts on site, book some time in advance to make sure you get a scheduled slot you can count on.\n\n### Stop by booth 2608 on the expo floor in The Venetian\n\nThe team will be staffing our booth during all expo hours. We'll have some unique swag to hand out along with demos and experts to answer your questions.\n\n### Come see our CEO show off GitLab + EKS\n\nOn Tuesday, Nov. 27 at 12:10 p.m. in the Pilvi Theater, [Sid](https://www.linkedin.com/in/sijbrandij/) and [Priyanka](https://www.linkedin.com/in/pritianka/) will be showing how to [reinvent your pipelines with GitLab, Kubernetes, and Amazon EKS](https://www.portal.reinvent.awsevents.com/connect/search.ww#loadSearch-searchPhrase=%22GitLab%22&searchType=session&tc=0&sortBy=abbreviationSort&p=) along with a live demo.\n\n### Demo: Set up your pipelines in five minutes\n\nJoin [Joshua](https://www.linkedin.com/in/jshlmbrt/) at the GitLab booth (2608) on Wednesday, Nov. 28 at 1 p.m. for a live demo of GitLab [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/).\n\n### GitLab CI 101\n\nJoin [Reb](https://www.linkedin.com/in/reb33/) at the GitLab booth (2608) on Tuesday, Nov. 27 at 2 p.m. for a tutorial on getting up and going with [GitLab continuous integration](/features/continuous-integration/).\n\nSee you there!\n",[278],{"slug":3532,"featured":6,"template":681},"aws-pre-event-post","content:en-us:blog:aws-pre-event-post.yml","Aws Pre Event Post","en-us/blog/aws-pre-event-post.yml","en-us/blog/aws-pre-event-post",{"_path":3538,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3539,"content":3545,"config":3550,"_id":3552,"_type":17,"title":3553,"_source":18,"_file":3554,"_stem":3555,"_extension":21},"/en-us/blog/inside-our-new-product-manager-persona",{"title":3540,"description":3541,"ogTitle":3540,"ogDescription":3541,"noIndex":6,"ogImage":3542,"ogUrl":3543,"ogSiteName":667,"ogType":668,"canonicalUrls":3543,"schema":3544},"What do product managers need to do their best work?","Check out some of the findings that led to our new Product Manager Persona.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678857/Blog/Hero%20Images/investigating-how-product-managers-use-gitlab.jpg","https://about.gitlab.com/blog/inside-our-new-product-manager-persona","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What do product managers need to do their best work?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Katherine Okpara\"}],\n        \"datePublished\": \"2018-11-12\",\n      }",{"title":3540,"description":3541,"authors":3546,"heroImage":3542,"date":3547,"body":3548,"category":14,"tags":3549},[3000],"2018-11-12","\nRecently I spoke with several product managers and asked them about their experiences, as part of our [effort to create personas](/blog/personas-and-empathy-building/) for every one of GitLab's [product areas](/handbook/product/categories/). I gained a lot of insight through these interviews, including a better understanding of their daily duties, goals and motivations, challenges they face in their roles, and the tools they use throughout the software development lifecycle. Many of the findings have been included in our new [Product Manager Persona, Parker](/handbook/product/personas/), to help our own PMs brainstorm improvements and next steps for GitLab features. You can peruse the highlights and the persona itself below, and let us know what you think by tweeting us [@gitlab](https://twitter.com/gitlab)!\n\n## The research\n\nHere are some of the findings from my [eight interviews](https://gitlab.com/gitlab-org/ux-research/issues/88) conducted for the persona.\n\n### So, what’s the hardest part about being a product manager?\n\nThe product manager persona represents people who are responsible for prioritizing feature requests, product roadmapping, and tracking progress of the development of software applications. Since many of these factors depend on how other team members perform, most challenges related to communication and ensuring that their team delivers on time.\n\n#### Staying updated on team progress and important decisions\n\nIt can be difficult to know the status of certain requirements when other team members do not update the various tools that are being used. Important information can get lost along the way, which often leads to repetitive discussions or fixing incorrect work. Users were looking for ways to have this information readily accessible and consistently communicated throughout their teams.\n\n> \"Getting other people to use the tools. I need to make sure that other people are updating the Jira board for example – in my experience, many developers don’t exactly love to do this since it’s a tedious task. Or, if they have a question, adding it in the task so that we can keep a record of everything that’s being worked on. Sometimes someone will send me a question on Slack and I’ll copy-paste that into the ticket since sometimes it’s easier for me to do that than to ask someone to get used to doing that.\"\n\n#### Prioritizing features to build when dealing with limited resources\n\nProduct managers are often responsible for defining and scoping features, incorporating company objectives into the product roadmap, and giving developers and designers the requirements they need to deliver strong features. As a result, product teams often have trouble balancing feature requests with development capacity.\n\n> \"...Being able to find balance between being strategic and being practical. Being able to look into the future and be ambitious while at the same time having to put out fires and manage the day-to-day. Another challenge is staying in touch with the end user. We do not have as much time to be on top of the market and to interview customers. We're not as able to get market feedback and do market research as well...\"\n\n#### Simplifying information\u2028 for the different stakeholders involved in the product\n\nThe need to give clients and stakeholders timelines and estimates that are accurate but also realistic can be very stressful for a product manager. This is largely due to the fact that a cycle is often unpredictable. It can also be challenging to explain why certain features have been delayed or deprioritized, when customers and upper-level management are not working closely with the team.\n\n>\u2028\"Some of the challenges of working with the technical team leads is that they will forget to update things or they’ll give me a summary that is super technical so I have to ask more questions to make sure that I understand and have the ability to explain to other product managers where the developers are stuck, because they need more definition on what that feature should look like.\"\n\n### What motivates a product manager?\n\nProduct managers generally are motivated by the desire to deliver high-quality features in a timely manner. When company objectives shift, they want to have a standard process for communication, so that they can be in sync with all team members. They need to see an overview of all the relevant information related to a feature or product, so that they can monitor progress throughout a cycle. Additionally, they want to be able to help their teams accomplish more of their goals over time.\n\n### What’s the best part about being a product manager?\n\nAll in all, the interviewees all expressed the joy they receive from simply doing their jobs, whether that’s improving life for users or speeding up processes within the company. The best part of being a product manager is the opportunity to bring a concept to life and solve real problems for their users.\n\n## The persona\n\n![Parker, Product Manager persona](https://about.gitlab.com/images/blogimages/product-manager-persona.png){: .shadow.center}\n\nKeep an eye out for the rest of our series on the [new personas](/handbook/product/personas/)!\n\n[Photo](https://unsplash.com/photos/YiRQIglwYig) by [Hello I'm Nik](https://unsplash.com/@helloimnik) on Unsplash\n{: .note}\n",[935,676,1255],{"slug":3551,"featured":6,"template":681},"inside-our-new-product-manager-persona","content:en-us:blog:inside-our-new-product-manager-persona.yml","Inside Our New Product Manager Persona","en-us/blog/inside-our-new-product-manager-persona.yml","en-us/blog/inside-our-new-product-manager-persona",{"_path":3557,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3558,"content":3564,"config":3569,"_id":3571,"_type":17,"title":3572,"_source":18,"_file":3573,"_stem":3574,"_extension":21},"/en-us/blog/an-ode-to-stable-counterparts",{"title":3559,"description":3560,"ogTitle":3559,"ogDescription":3560,"noIndex":6,"ogImage":3561,"ogUrl":3562,"ogSiteName":667,"ogType":668,"canonicalUrls":3562,"schema":3563},"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":3559,"description":3560,"authors":3565,"heroImage":3561,"date":3566,"body":3567,"category":14,"tags":3568},[1635],"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",[1255,676,974],{"slug":3570,"featured":6,"template":681},"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":3576,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3577,"content":3583,"config":3588,"_id":3590,"_type":17,"title":3591,"_source":18,"_file":3592,"_stem":3593,"_extension":21},"/en-us/blog/going-virtual-with-all-day-devops",{"title":3578,"description":3579,"ogTitle":3578,"ogDescription":3579,"noIndex":6,"ogImage":3580,"ogUrl":3581,"ogSiteName":667,"ogType":668,"canonicalUrls":3581,"schema":3582},"Going virtual with All Day DevOps","The real value of virtual conferences.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671730/Blog/Hero%20Images/meeting_image.jpg","https://about.gitlab.com/blog/going-virtual-with-all-day-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Going virtual with All Day DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Kyle\"}],\n        \"datePublished\": \"2018-10-16\",\n      }",{"title":3578,"description":3579,"authors":3584,"heroImage":3580,"date":3566,"body":3586,"category":14,"tags":3587},[3585],"Emily Kyle","\n\nIn my role, I am very fortunate to get the opportunity to attend many events throughout the year. Every conference is another opportunity to learn from thought leaders and others in the industry. The real value in these events is the knowledge share that takes place, yet I find myself frustrated every time. I try to be a sponge absorbing all the information to share all the learnings with my team, but inevitably things get lost as more time passes and we all get back to our day-to-day.  \n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://player.vimeo.com/video/290793305\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nLuckily, All Day DevOps is different. It’s the largest DevOps conference of the year, and it’s 100% free and virtual. Anyone, from anywhere around the world, can register and tune in for 24 hours on October 17. In fact, about 200 people from our company have already registered. As a fully remote company, fully virtual events are particularly important to our team as they level the information playing field and allow everyone on our team in all 40 countries to participate and gain value.\n\nThose attending will be able to listen in on over 100 sessions from some of the industry’s brightest minds, and then ask them anything in Q&As on Slack. The other nice thing: zero vendor pitches are allowed -- a mainstay of the All Day DevOps community.\n\nThis year’s conference will feature 5 tracks this year: CI/CD, DevSecOps, Cloud Native Infrastructure, SRE, and Cultural Transformations.\n\n[Speaker](https://www.alldaydevops.com/addo-speakers) highlights include talks by:\n\n* Cindy Healy, her code sits on another planet inside the Mars Pathfinder\n* David Rensin, founder of Customer Reliability Engineering (CRE) at Google\n* George Swan, Director of Engineering Solutions at Autodesk\n* Priyanka Sharma, Director of Cloud Native Alliances at GitLab\n\nAfter you [register](https://www.alldaydevops.com/register) yourself, encourage your entire department to register.  After all, DevOps done right is a team sport.\n",[806,278],{"slug":3589,"featured":6,"template":681},"going-virtual-with-all-day-devops","content:en-us:blog:going-virtual-with-all-day-devops.yml","Going Virtual With All Day Devops","en-us/blog/going-virtual-with-all-day-devops.yml","en-us/blog/going-virtual-with-all-day-devops",{"_path":3595,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3596,"content":3602,"config":3608,"_id":3610,"_type":17,"title":3611,"_source":18,"_file":3612,"_stem":3613,"_extension":21},"/en-us/blog/cern-connect-global-researchers",{"title":3597,"description":3598,"ogTitle":3597,"ogDescription":3598,"noIndex":6,"ogImage":3599,"ogUrl":3600,"ogSiteName":667,"ogType":668,"canonicalUrls":3600,"schema":3601},"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":3597,"description":3598,"authors":3603,"heroImage":3599,"date":3605,"body":3606,"category":14,"tags":3607},[3604],"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",[1791,1115,974,785],{"slug":3609,"featured":6,"template":681},"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":3615,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3616,"content":3622,"config":3627,"_id":3629,"_type":17,"title":3630,"_source":18,"_file":3631,"_stem":3632,"_extension":21},"/en-us/blog/what-is-cloud-native",{"title":3617,"description":3618,"ogTitle":3617,"ogDescription":3618,"noIndex":6,"ogImage":3619,"ogUrl":3620,"ogSiteName":667,"ogType":668,"canonicalUrls":3620,"schema":3621},"A beginner's guide to cloud native","If you’re a little fuzzy on what makes an application cloud native, this explainer will help you get up to speed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665811/Blog/Hero%20Images/daytime-clouds.jpg","https://about.gitlab.com/blog/what-is-cloud-native","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A beginner's guide to cloud native\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2018-10-08\",\n      }",{"title":3617,"description":3618,"authors":3623,"heroImage":3619,"date":3624,"body":3625,"category":14,"tags":3626},[3266],"2018-10-08","\n\n## What is cloud native? Everything you need to know\n\nThe term [cloud native](/topics/cloud-native/) has been bandied about in the tech world a lot over the last few years, but it's still often misunderstood. Although it's an important part, simply being run in the cloud does not make an application cloud native; it must also be built in the cloud. One of the first and currently largest cloud computing providers, Amazon Web Services paved the way for cloud native app development, a now more than [$20 billion market](https://www.canalys.com/newsroom/cloud-infrastructure-spend-reaches-us%2420-billion-in-q2-2018-with-hybrid-it-approach-dominant) as of this year. With its growing popularity, organizations like the Cloud Native Computing Foundation (CNCF) have sprouted to help foster the growth of cloud native app development.\n\n[CNCF](https://www.cncf.io/), an open source software organization focused on promoting the cloud-based app building and deployment approach, [defines cloud native](https://github.com/cncf/toc/blob/master/DEFINITION.md) as the following:\n\n>Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.\n>\n>Containers, service meshes, [microservices](/topics/microservices/), immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.\n\nTo break it down even further: For an application to be cloud native, it must be built and run in the cloud. This requires multiple tools that allow app developers to make use of the architectural advantages of cloud infrastructure.\n\n## There are three main building blocks of cloud native architecture\n\n### Containers\n\n[Containers](/blog/containers-kubernetes-basics/) are an [alternative way to package applications](https://searchitoperations.techtarget.com/tip/What-are-containers-and-how-do-they-work) versus building for VMs or physical servers directly. Containers can run inside of a virtual machine or on a physical server. Containers hold an application’s libraries and processes, but don't include an operating system, making them lightweight. In the end, fewer servers are needed to run multiple instances of an application which reduces cost and makes them easier to scale. Some other [benefits of containers](https://tsa.com/top-5-benefits-of-containerization/) include faster deployment, better portability and scalability, and improved security.\n\n### Orchestrators\n\nOnce the containers are set, an orchestrator is needed to get them running. Container orchestrators direct how and where containers run, fix any that go down and determine if more are needed. When it comes to container orchestrators, also known as schedulers, Kubernetes is the [clear cut market winner](/blog/top-five-cloud-trends/).\n\n### Microservices\n\nThe last main component of cloud native computing is microservices. In order to make apps run more smoothly, they can be broken down into smaller parts, or microservices, to make them easier to scale based on load. Microservices infrastructure also makes it easier – and faster – for engineers to develop an app. Smaller teams can be formed and assigned to take ownership of individual components of the app’s development, allowing engineers to code without potentially impacting another part of the project.\n\nWhile public cloud services like AWS offer the opportunity to build and deploy applications easily, there are times when it makes sense to build your own infrastructure. A private or hybrid cloud solution is generally needed when sensitive data is processed within an application or industry regulations call for increased controls and security.\n\n## How to streamline cloud native development\n\nAs you can see, cloud native app development requires the incorporation of several tools for a successful deployment. It begs for a DevOps approach to efficiently streamline the multiple elements needed to get an app up and running in the cloud. This is where GitLab comes in.\n\nWe're aiming to make GitLab the best place to build cloud native apps. With [built-in registry](https://docs.gitlab.com/ee/user/packages/container_registry/index.html) and [Kubernetes integrations](https://docs.gitlab.com/ee/user/project/clusters/index.html) we're always working to offer new ways to simplify toolchains and speed up cycle times, making it easier to transition to a cloud native environment.\n\nFor a deeper dive into cloud native, check out our training video by GitLab Product Marketing Manager [William Chia](/company/team/#thewilliamchia):\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jc5cY3LoOOI?start=90\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover photo by [Sam Schooler](https://unsplash.com/photos/E9aetBe2w40) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[723,1076],{"slug":3628,"featured":6,"template":681},"what-is-cloud-native","content:en-us:blog:what-is-cloud-native.yml","What Is Cloud Native","en-us/blog/what-is-cloud-native.yml","en-us/blog/what-is-cloud-native",{"_path":3634,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3635,"content":3641,"config":3646,"_id":3648,"_type":17,"title":3649,"_source":18,"_file":3650,"_stem":3651,"_extension":21},"/en-us/blog/what-south-africa-taught-me-about-cybersecurity",{"title":3636,"description":3637,"ogTitle":3636,"ogDescription":3637,"noIndex":6,"ogImage":3638,"ogUrl":3639,"ogSiteName":667,"ogType":668,"canonicalUrls":3639,"schema":3640},"What our summit in South Africa taught me about cybersecurity","Cybersecurity is a necessity, but it's often treated as an afterthought. What it has in common with modern photography could tell us how to make it less painful to achieve.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671140/Blog/Hero%20Images/south-africa-cyber-security.jpg","https://about.gitlab.com/blog/what-south-africa-taught-me-about-cybersecurity","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What our summit in South Africa taught me about cybersecurity\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2018-09-11\",\n      }",{"title":3636,"description":3637,"authors":3642,"heroImage":3638,"date":3643,"body":3644,"category":14,"tags":3645},[1463],"2018-09-11","\nThe GitLab team [summit](/events/gitlab-contribute/) recently took place in Cape Town, South Africa, which, as you can imagine, promised to be memorable.\nWhen preparing to cross three continents over 22 hours on airplanes, you think carefully about what to pack. You are anticipating the most beautiful scenery ever and want to make sure you capture it in pictures. So you find your camera – the one you haven't used in a long time because you've grown accustomed to using your cellphone. After careful debate, you decide to take it because those awesome experiences and scenery deserve the best camera.\n\nThe camera requires certain things: You have to make sure it's charged or has batteries; it needs to have adequate storage; you may need additional lenses which also require special care. Everything must be protected and carefully packed, and requires additional space and weight to carry on board with you because it's too precious to put in checked baggage.\n\nWhen you get to South Africa and you see this incredible scenery, you take out your wonderful camera and you realize a few things:\n\n## 1. You have only a precious few moments to capture the image\n\nDo I really have time to fidget with f-stops and customizations, or do I just want to capture the picture and perhaps customize it a bit later by cropping and adjusting the light?\n\n## 2. It's difficult to share camera photos immediately\n\nI'm anxious to share these images with friends and family back home. It occurs to me that with my phone I can share images immediately and effortlessly by email, text, Slack, or a variety of social media. If I take the pictures on my expensive camera, I can't share them immediately because it's not connected to anything. I'll have to wait until I get back to my hotel room so I can take the flash drive and put it in my laptop, log on to the Wi-Fi, and then share my images.\n\n## 3. My camera photos aren't secure\n\nIf I lose that flash drive, all of my images are gone (unless I back them up immediately after capturing them – not likely!). While it is possible I could lose my cell phone and lose my pictures, it's less likely. My phone is an integral part of my daily workflow – an appendage even. How often do we feel naked if we forget our phone at home or even in the other room? I'm much less likely to leave my phone on the bus when I get off to explore then to leave my camera behind.\n\nSo, I choose to use my phone to capture these magnificent images. My primary objective is not taking fabulous pictures worthy of publication that I can sell or frame on my wall, but to take pictures that are good enough, that capture the special place, and that I can share with friends and family easily and effortlessly. If it's too hard to share, I may not do it, or it may take me a long time. In addition, I don't have to think ahead about how my phone will capture an image in such a way to send it to friends; the images automatically integrate with all of the other sharing mechanisms on my phone. It simply works. I am free to focus on my primary effort of capturing the images while I soak up the moments.\n\n## Now, how does this relate to cybersecurity?\n\nCompanies invest a great deal in [application security to test their software](/topics/devsecops/) for security vulnerabilities. It's a separate application that requires its own budget and maintenance. Like the specialized camera, the information it creates must be shared in order to be most useful. The security team can use it by itself, but to be truly effective, the vulnerabilities found must be shared with development so that they can be corrected. Yet developers have little interest in logging onto a security system to access the data. Would your friends and family want to physically turn on your camera to look at your pictures? Maybe, but it's very limiting as to whom you can reach.\n\nThe challenge then is how do you get the data found by the application security system into the hands of the developers? Today that is one of the greatest challenges to overcome, even in rare cases where the objectives of security and dev totally align.\n\n### What if you looked at application security the same way we look at photographing images?\n\nIs the prime objective to do the most eloquent job of finding the vulnerabilities? Or, is the prime objective to get the vulnerabilities that we do find fixed? If it is the latter then the primary issue must be integrating with the developers’ workflow.\n\nWith [GitLab application security testing](/solutions/security-compliance/), it is like the camera on your phone – maybe not superior to a dedicated tool in isolation, but good quality, and more importantly, integrated into the workflow to be the most useful. It is easily and efficiently used without added thought. With GitLab, every commit and every merge request is tested. There isn't even a separate step – it's all automated for you without additional effort.\n\n![GitLab security dashboard](https://about.gitlab.com/images/blogimages/security-dashboard.png){: .shadow.medium.center}\n\nAs with photography, the most important thing is that you capture those moments before they escape you; with application security testing, it's important that you capture those vulnerabilities so that you can act upon them. With GitLab, the vulnerabilities are shown right there in the developers' workflow. They don't have to log into a different system nor interrupt their work. The security vulnerabilities are shown right alongside any other application flaws in the pipeline results of each merge request. The developer can choose to fix them now or continue the build, but either way, the vulnerabilities are captured and logged. And now with the security dashboard, the security team can evaluate further and create an issue for remediation if needed.\n\n>The vulnerabilities are shown right there in the developers' workflow. They don't have to log into a different system nor interrupt their work\n\nThis really does turn application security on its head! It puts the insight and tools for action into the hands of the developer and then shares results with security, rather than the other way around. It makes so much more sense because the developer must do the remediation, not the security pro. Imagine the efficiency gains if most of the effort was placed on eliminating the vulnerabilities up front, rather than on finding and tracking them later in the SDLC! Sound familiar? This has been imagined before and cost savings even estimated. It's the \"shift left\" mantra. While everyone embraces it, few actually achieve it. Why? Because they lack the tools to enable such a seismic shift where the only gate is the merge request.\n\nAlbert Einstein said that the definition of insanity was doing the same thing and expecting a different result. So how can we expect traditional application security methods to meet the needs of modern, cloud-first DevOps environments? We can't. With GitLab, our single application helps users efficiently develop and deploy secure code by leveraging the power of integration across the entire SDLC. [No more stitching together complex DevOps tool chains](/). Microsoft did something similar years ago. Remember Word Perfect? It succumbed to Word because content could be copied/pasted and integrated across the Microsoft suite of documents, spreadsheets and slides. GitLab is on track to do the same thing for software development – including application security testing.\n\n_What do you think? Is this a new era of app security?_\n\nPhoto by [Clyde Thoma](https://unsplash.com/photos/8plz1xK_Wmk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyTexts) on [Unsplash](https://unsplash.com/search/photos/cape-town?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[894,806,1791],{"slug":3647,"featured":6,"template":681},"what-south-africa-taught-me-about-cybersecurity","content:en-us:blog:what-south-africa-taught-me-about-cybersecurity.yml","What South Africa Taught Me About Cybersecurity","en-us/blog/what-south-africa-taught-me-about-cybersecurity.yml","en-us/blog/what-south-africa-taught-me-about-cybersecurity",{"_path":3653,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3654,"content":3660,"config":3665,"_id":3667,"_type":17,"title":3668,"_source":18,"_file":3669,"_stem":3670,"_extension":21},"/en-us/blog/how-telesphora-is-tackling-the-opioid-crisis-machine-learning-human-centered-design",{"title":3655,"description":3656,"ogTitle":3655,"ogDescription":3656,"noIndex":6,"ogImage":3657,"ogUrl":3658,"ogSiteName":667,"ogType":668,"canonicalUrls":3658,"schema":3659},"How Telesphora is tackling the opioid epidemic with machine learning and human-centered design","GitLab users Jack Cackler and Frank Lee explain how they use predictive analytics to empower community stakeholders, like first responders and policy makers, to save lives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671593/Blog/Hero%20Images/telesphora-team.jpg","https://about.gitlab.com/blog/how-telesphora-is-tackling-the-opioid-crisis-machine-learning-human-centered-design","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Telesphora is tackling the opioid epidemic with machine learning and human-centered design\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2018-09-05\",\n      }",{"title":3655,"description":3656,"authors":3661,"heroImage":3657,"date":3662,"body":3663,"category":14,"tags":3664},[3451],"2018-09-05","\n\nOn average, [115 Americans die every day](https://www.cdc.gov/drugoverdose/epidemic/index.html) from an opioid overdose. The team at [Telesphora](https://telesphora.com/) is on a mission to help health care professionals and local communities change that.\n\nIn 2017, the United States Department of Health and Human Services (HHS) declared the current opioid crisis a public health emergency as the number of [deaths involving opioids](https://www.drugabuse.gov/related-topics/trends-statistics/overdose-death-rates) in the United States skyrocketed from approximately 10,000 in 2002 to an estimated 49,000 in 2017.\nIn response to the crisis, the HHS released a [five-point strategy](https://www.hhs.gov/opioids/about-the-epidemic/hhs-response/index.html) for fighting the opioid epidemic. Among the key priorities you’d expect to see from a health crisis report (e.g. better prevention, treatment, and recovery services; better pain management) is **better data**, and they’ve turned to computer and data scientists for help.\n\n![US map of opioid epidemic](https://about.gitlab.com/images/blogimages/telesphora/us-map-crisis.jpg){: .medium.center}\n*\u003Csmall>In 2016, the number of overdose deaths involving opioids was 5 times higher than in 1999.\u003C/small>*\n\n## Designing for people\n\nJack Cackler is a machine learning specialist. Frank Lee is a pain management specialist. Under typical circumstances, these two may have never met. But when the HHS decided to hold an unprecedented [national opioid crisis code-a-thon](https://www.hhs.gov/challenges/code-a-thon/index.html), they didn’t just enlist developers – they brought in stakeholders from every side of the issue to develop data-driven solutions to combat the opioid epidemic across three tracks: treatment, usage, and prevention.\n\n[Origami Innovations](https://origamiinnovations.com/), a design, innovation, and solution lab powered by a Yale University students, was invited to the code-a-thon, bringing Cackler, Lee, and co-founders Matthew Erlendson, fourth-year medical student at Yale University and founder of Origami Innovations, and Dara Rouholiman, a digital health, data, and machine learning consultant together for the time. After winning the Treatment Track and receiving a $10,000 prize, they formed Telesphora, a human-centered data science platform.\n\n“One of the things that we were involved with was coming up with the core themes for the hackathon,” said Frank Lee, co-founder of Telesphora. “One of the ways that we do that is by human-centered design thinking.”\n\nHuman-centered design is an approach to design that considers the human perspective in every step of the problem-solving process. As Jack Cackler, co-founder at Telesphora, explains, “Sometimes, especially for those with a technical background, there’s a tendency to just focus on a technical solution. We really tried to get the story behind how this [opioid crisis] really impacted people.”\n\n> \"There’s a tendency to just focus on a technical solution. We really tried to get the story behind how this [opioid crisis] really impacted people.”\n\nCackler and team knew they wanted to design a human-centered solution. Discovering that the stigma of chronic opioid use was preventing treatment, they started asking questions:\n\n- *How might we treat this like a disease to reduce stigma, taking an empathetic approach similar to outbreaks of the flu or STDs?*\n- *How might we better predict community outbreaks?*\n- *How might we contain high mortality outbreaks, such as bad batches of drugs, to save lives in real time?*\n\n“We involved all the stakeholders in the crisis, which includes not only the providers, the scientists, and the administrators of the local and the state regions, but also the patients and families of patients who are affected by the overdose,” said Lee. “After doing a lot of brainstorming with these participants, we knew there needed to be better communication between first responders. We aimed our solution toward first responders and how they can help each other better allocate resources to help with the overdoses.”\n\n## Empathy over stigma\n\nOn June 23, 2016 in New Haven, Connecticut, where many on Cackler and Lee’s code-a-thon team called home, 12 patients, found within a one-block radius, were taken to Yale New Haven Hospital for opioid overdose. Three lost their lives due to a shortage of the drug Narcan (naloxone), a drug that can treat an opioid overdose to prevent death; the shelf life is short and the cost is high.\n\nPart of the problem, according to Lee and Cackler, is that there’s a common assumption that there’s a uniform distribution of overdoses, therefore, you can accommodate the demand. However, data analysis and conversations with first responders show that overdoses happen in spikes, like the event in New Haven.\n\n“There will be a new distribution channel of some opioid in some city. And then all of a sudden, you'll have a dozen, two dozen overdoses in a weekend, and there's just no way that the ambulances in the city can service that demand,” said Cackler. If the outbreak in New Haven could have been predicted, health agencies could have prepared and saved lives.\n\n![telesphora interface](https://about.gitlab.com/images/blogimages/telesphora/hhs1.png){: .medium.center}\n*\u003Csmall>Telesphora is a platform that uses real-time, open-access data and machine learning to predict where and when increases in opioid overdose and mortality will occur.\u003C/small>*\n\nThe solution Cackler, Lee, and the team came up with, now Telesphora, aimed to do just that. Using real-time data and future-trend data, they built a platform that empowers communities to predict outbreaks, increases access to treatment and resources, and reduces the stigma of opioid use.\n\n## Predictive analytics and user-friendly tools save lives\n\nKnowing that if an overdose outbreak is predicted before it happens, life-saving medicine can be allocated to the soon-to-be affected area to save lives, the Telesphora team used predictive analytics and user-friendly design to build a projection model and visualize the data.\n\n> \"If the outbreak in New Haven could have been predicted, health agencies could have prepared and saved lives.\"\n\nStarting with historical overdose data and network analysis of supply movements and overdoses, they created a spatiotemporal Poisson process to project future opioid overdose trends at any given space and time. The Poisson process takes real-time data and uses the geographic information, temporal information, and type of drug to predict the movement of opioids, alerting local responders and authorities of a potential overdose outbreak before it happens, bringing response time and mortality rate down.\n\n“The first alerts in this model come from neighboring cities in a flurry of mortality rate. Our tool with a geospatial analysis can predict the movement of spikes. When you see a spike in fentanyl in New Haven, CT, 4.8 days later you’ll see a spike happen in Fairfield,” Cackler explains.\n\n![machine learning explanation](https://about.gitlab.com/images/blogimages/telesphora/machine-learning.jpg){: .medium.center}\n*\u003Csmall>The machine learning model predicts the movement of outbreaks based on surrounding counties.\u003C/small>*\n\nWhen an outbreak is detected, it appears as a spike on the graph and the model can correlate that spike to different regions, alerting communities to how many days until that outbreak affects their area. The data visualization makes it easy for end users, like first responders, to digest the numbers and trends, showing the actual and predicted data across different regions, and the ability to filter by different drugs.\n\n“If we had this model a year before, events like what happened in New Haven could have been predicted. I think that’s really impactful and you can see in a tangible way how this is actionable,” said Cackler.\n\n*Are you using machine learning or human-centered design to build actionable solutions for the future? We want to hear from you! Email content@gitlab.com.*\n\nAll images courtesy of Telesphora\n{: .note}\n",[1791,808],{"slug":3666,"featured":6,"template":681},"how-telesphora-is-tackling-the-opioid-crisis-machine-learning-human-centered-design","content:en-us:blog:how-telesphora-is-tackling-the-opioid-crisis-machine-learning-human-centered-design.yml","How Telesphora Is Tackling The Opioid Crisis Machine Learning Human Centered Design","en-us/blog/how-telesphora-is-tackling-the-opioid-crisis-machine-learning-human-centered-design.yml","en-us/blog/how-telesphora-is-tackling-the-opioid-crisis-machine-learning-human-centered-design",{"_path":3672,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3673,"content":3678,"config":3682,"_id":3684,"_type":17,"title":3685,"_source":18,"_file":3686,"_stem":3687,"_extension":21},"/en-us/blog/how-gitlab-ci-compares-with-the-three-variants-of-jenkins",{"title":3674,"description":3675,"ogTitle":3674,"ogDescription":3675,"noIndex":6,"ogImage":947,"ogUrl":3676,"ogSiteName":667,"ogType":668,"canonicalUrls":3676,"schema":3677},"How GitLab CI compares with the three variants of Jenkins","In this article, we compare GitLab CI with the three Jenkins variants and ask if there are things we can learn.","https://about.gitlab.com/blog/how-gitlab-ci-compares-with-the-three-variants-of-jenkins","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab CI compares with the three variants of Jenkins\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2018-09-03\",\n      }",{"title":3674,"description":3675,"authors":3679,"heroImage":947,"date":3680,"body":3681,"category":14},[911],"2018-09-03","\n\nThe creator of Jenkins just [announced two new versions of Jenkins](https://jenkins.io/blog/shifting-gears/).\nAccording to the author, the current legacy version of Jenkins is \"trapped in a local optimum,\" and he proposes to make [Cloud Native Jenkins](https://jenkins.io/sigs/cloud-native/) and [Jenkins Evergreen](https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc) to get to a global optimum.\n\nAccording to Forrester, [GitLab CI and Jenkins/Cloudbees are two of the four leading products for CI](/blog/gitlab-leader-continuous-integration-forrester-wave/).\nIn this article, we compare GitLab CI with the three Jenkins variants. Here's what we learned.\n\nThe structure of this article is based on the items mentioned in the Jenkins announcement.\n\n## Extensible\n\nThe governance, culture, and distribution mechanism of Jenkins and GitLab are comparable; both of them open core projects with a dominant company.\nBy the way, the proprietary version CloudBees Jenkins Enterprise is now known as CloudBees Core; for most open core projects the core is the open source part.\n\n## General purpose\n\nBoth Jenkins and GitLab CI can be used for many tasks and can build on many operating systems.\n\n## Community\n\nJenkins has 519 contributors to its source code, but many people contribute via plugins that are not in core.\nGitLab has 2,000+ contributors overall, but only part of them contribute to CI.\n\n## Service instability\n\nAccording to the author, the current legacy version of Jenkins sometimes needs to be restarted once a day by an administrator.\nGitLab CI is part of GitLab, and in case it runs out of memory, the application processes are automatically restarted one by one without disruption to the users or builds.\nThe article doesn't mention how Cloud Native Jenkins or Jenkins Evergreen addresses the problem.\n\n## Brittle configuration\n\nLegacy Jenkins can easily break if you install or upgrade a plugin.\nGitLab CI has all functionality as part of its main code base, ensuring everything is tested before it is shipped to customers.\nJenkins Evergreen will come with essential plugins as part of the [distribution](https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#automatically-updated-distribution).\nThe article doesn't mention how Cloud Native Jenkins addresses the problem; maybe it doesn't allow plugins.\n\n## Assembly required\n\nLegacy Jenkins doesn't work out of the box because too many choices are confusing users.\nGitLab CI and GitLab are [based on convention over configuration](/handbook/product/product-principles/#convention-over-configuration), where we prefer choices that are well thought out and based on current best practices and avoid unnecessary configuration.\nCloud Native Jenkins redesigns Jenkins from the ground up on simpler primitives.\nJenkins Evergreen still uses the same plugins so it would be harder to simplify, but maybe by selecting a set of blessed essential plugins, you can make them work better together because they can assume the other plugin is installed.\n\n## Reduced development velocity\n\nLegacy Jenkins [releases once a week](https://jenkins.io/changelog/) but the changes seem relatively minor.\nGitLab [releases every month with multiple major features](https://about.gitlab.com/releases/) although most are not for CI.\nCloud Native Jenkins is under heavy development, but I was not able to locate the source code.\nJenkins Evergreen has an [automatically updated distribution](https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#auto-update) that has three improvements for project developers:\n\n1. Greatly reduced time between core and \"foundational\" plugin changes landing.\n1. Greatly reduced version matrix for testing core/plugin changes against one another.\n1. Small-batch changes can automatically report success/error telemetry which provides rapid feedback for changes.\n\n## Kubernetes as the runtime\n\nThis is part of Cloud Native Jenkins only, not of Legacy Jenkins or Jenkins Evergreen.\n\n1. Serverless / function-as-a-service build execution (à la Jenkinsfile runner) that are isolated. => [GitLab CI Runner](https://docs.gitlab.com/runner/) already allows for isolated build execution. We're discussing [introducing a Lambda-based serverless runner](https://gitlab.com/gitlab-org/gitlab-runner/issues/3128).\n1. Various pieces of functionalities deployed as separate microservices. => GitLab is mostly a Rails monolith with [parts that require high performance as separate Go microservices](https://docs.gitlab.com/ee/development/architecture.html#components).\n1. Services interacting through [Kubernetes CRDs](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) in order to promote better reuse and composability. => This is something currently not in GitLab, but we're keeping a close eye on this. We're open to suggestions on how to best do this. GitLab does have extensive [Kubernetes integrations](/solutions/kubernetes/).\n\n## New extensibility mechanism\n\nThis means using something like [Knative builder](https://github.com/knative/build).\nThis is proposed to be part of Cloud Native Jenkins only, not of Legacy Jenkins or Jenkins Evergreen.\nAt GitLab, we're following the Knative news, for example [scale to zero is something we want to use for our review apps](https://gitlab.com/gitlab-org/gitlab-ee/issues/3585#note_90052063), and if Knative build becomes popular, we'll certainly consider supporting it.\n\n## Data on cloud-managed data services\n\nThis is part of Cloud Native Jenkins only, not of Legacy Jenkins or Jenkins Evergreen.\nGitLab CI already supports storing everything in object storage and a database, not using file storage at all.\nGitLab itself still needs file storage for the Git repositories, since some Git commands require block access.\n\n## Configuration as code\n\nThis is to be able to copy the configuration of one Jenkins master to another.\nWith GitLab, all the CI configuration is part of the repo in the [.gitlab-ci.yml file](https://docs.gitlab.com/ee/ci/yaml/) on a per project basis, so you don't need to copy master configuration between GitLab instances.\nWith Jenkins you can have some project configuration as part of a [Jenkinsfile](https://jenkins.io/doc/book/pipeline/jenkinsfile/) but you have to [configure plugins on the master level](https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md#plugin-management).\n\n## Secure by default design\n\nThe [Jenkins Remoting Layer](https://github.com/jenkinsci/remoting#jenkins-remoting-layer) that handles communication between the orchestrator and the agent is \"inherently prone to security vulnerabilities because of their design.\"\nWith GitLab CI, we run every build on a remote agent from the start of the project, having this as the default and only way helps keep the design elegant.\nWe do find that CI has been responsible for an above-average share of our security patches.\nSo far, everyone has [responsibly disclosed](/security/disclosure/) these, for which we are immensely grateful.\n\n## Conclusion\n\nThe many plugin combinations for Jenkins has made Legacy Jenkins hard to configure and brittle when updating.\nCloudbees is introducing two new versions of Jenkins to remedy the problem: Cloud Native Jenkins will start from scratch, while Jenkins Evergreen will focus on a set of essential plugins.\nGitLab CI adds new functionality in the main code base, avoiding the need for needless configuration and ensuring everything still works when updating.\n",{"slug":3683,"featured":6,"template":681},"how-gitlab-ci-compares-with-the-three-variants-of-jenkins","content:en-us:blog:how-gitlab-ci-compares-with-the-three-variants-of-jenkins.yml","How Gitlab Ci Compares With The Three Variants Of Jenkins","en-us/blog/how-gitlab-ci-compares-with-the-three-variants-of-jenkins.yml","en-us/blog/how-gitlab-ci-compares-with-the-three-variants-of-jenkins",{"_path":3689,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3690,"content":3696,"config":3701,"_id":3703,"_type":17,"title":3704,"_source":18,"_file":3705,"_stem":3706,"_extension":21},"/en-us/blog/designing-for-developers",{"title":3691,"description":3692,"ogTitle":3691,"ogDescription":3692,"noIndex":6,"ogImage":3693,"ogUrl":3694,"ogSiteName":667,"ogType":668,"canonicalUrls":3694,"schema":3695},"How to design for (and with) developers","UX Manager Sarrah Vesselov shares her thoughts on how to design for a developer audience.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679763/Blog/Hero%20Images/discovering_gitlabs_personas.jpg","https://about.gitlab.com/blog/designing-for-developers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to design for (and with) developers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-08-17\",\n      }",{"title":3691,"description":3692,"authors":3697,"heroImage":3693,"date":3698,"body":3699,"category":14,"tags":3700},[1635],"2018-08-17","\n\nDesigners have a challenging task: Solve problems to empower users to do their\nbest work. To understand how designers balance the demands of their roles as\nproblem solvers with the evolving needs of an audience, I chatted with UX Manager\n[Sarrah Vesselov](/company/team/#SVesselov) about the considerations that go into designing for developers.\n\n#### How has designing for developers evolved over time?\n\n>“It has become more complex since developers are using tools to do multiple\nthings rather than a single thing.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jbbH58ICs5o\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### How do you view developer feedback?\n\n>“Developers are as close to designers as you get. We’re all problem solvers.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/EJlOJurVjFI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### How has Hacker News feedback changed GitLab’s design?\n\n>“Having a direct line to people who are using our product every day allows us to quickly iterate and make changes.\nWhen I’m talking to people on Hacker News, I link them to issues, and I really value their feedback.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/nfHB8HBEwxs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### What do you consider when trying to create positive UX experiences for developers?\n\n>“It’s important to understand developers’ goals and motivations and what they’re trying to accomplish.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/I3lfB2yfslw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### What’s the greatest challenge in designing for developers?\n\n>“Things keep getting more and more complex. Trying to make life easier for someone is a challenge.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/l7yXDXtg_hU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### What advice do you have for other designers who have developers in mind?\n\n>“Make allies out of the developers you work with to better understand the developers you’re designing for.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oUrnGuSnNik\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Interested in joining the UX team?\nOur incredible [UX team](/handbook/product/ux/) is rapidly growing, and we'd love to be your teammate! If\nyou'd like to design for a developer audience, please apply for one of our open\n[positions](/jobs/).\n",[701,677],{"slug":3702,"featured":6,"template":681},"designing-for-developers","content:en-us:blog:designing-for-developers.yml","Designing For Developers","en-us/blog/designing-for-developers.yml","en-us/blog/designing-for-developers",{"_path":3708,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3709,"content":3715,"config":3720,"_id":3722,"_type":17,"title":3723,"_source":18,"_file":3724,"_stem":3725,"_extension":21},"/en-us/blog/top-five-cloud-trends",{"title":3710,"description":3711,"ogTitle":3710,"ogDescription":3711,"noIndex":6,"ogImage":3712,"ogUrl":3713,"ogSiteName":667,"ogType":668,"canonicalUrls":3713,"schema":3714},"Top 5 cloud trends of 2018: What has happened and what’s next","Cloud computing is officially where it's at. Find out who's in the lead and how to plan for the future.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678732/Blog/Hero%20Images/clouds.jpg","https://about.gitlab.com/blog/top-five-cloud-trends","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top 5 cloud trends of 2018: What has happened and what’s next\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2018-08-02\",\n      }",{"title":3710,"description":3711,"authors":3716,"heroImage":3712,"date":3717,"body":3718,"category":14,"tags":3719},[3266],"2018-08-02","\nThe cloud has undoubtedly infiltrated the enterprise space – and it is here to stay. Gartner Research predicts that by 2025, 80 percent of companies will have [opted to shutter](https://www.zdnet.com/article/the-data-center-is-dead-heres-what-comes-next/) their traditional data centers. Cloud spend is on the rise, so much so that the International Data Corporation (IDC) recently upped its 2018 prediction for cloud IT infrastructure spending to $57.2 billion, reflecting a 21.3 percent increase over the previous year. With the apparent exponential growth of cloud computing, we decided to root out the top five cloud trends of 2018 and take a look at what might be next:\n\n#### Public cloud use is on the rise.\nMulti-cloud solutions are the primary strategy for large companies, with public cloud use gaining steam. Thirty-eight percent of enterprises represented in the seventh annual [RightScale State of the Cloud\nsurvey](https://www.rightscale.com/learn/cloud-strategy/cloud-computing-trends) have made the public cloud a priority for 2018, up from 29 percent the previous year.\n\nThe industries expected to spend the most on public cloud services in 2018 are discrete manufacturing, professional services, and banking, according to IDC. The telecommunications, banking, and professional services industries are expected to see the most growth in cloud spending over the next five years, with IDC expecting each sector to see increases of almost 25 percent by 2021.\n\n#### Kubernetes is now king.\nThe container orchestration battle is over and Kubernetes has emerged as the undisputed winner. Industry insiders, like Forrester, have [predicted](https://blogs-images.forbes.com/louiscolumbus/files/2017/11/Forr-Cloud-Predictions-2018-2.png) Kubernetes as the winner and now the data proves this out. According to the State of the Cloud survey, Kubernetes shows 27 percent current use while Docker Swarm shows only 12 percent adoption. Use of Mesosphere clocks in at only 6 percent, but the report doesn't distinguish between Marathon or Kubernetes and [Mesosphere supports both](https://mesosphere.com/blog/kubernetes-dcos/). The data could further be skewed by showing container orchestration offerings from AWS, Azure, and Google Cloud as separate segments when in fact they all run Kubernetes. While there's some muddiness in how people are consuming Kubernetes, what's clear is that the market has spoken and Kubernetes is the de facto way to do container orchestration.\n\n#### Azure is hacking away at AWS’s lead in cloud infrastructure services.\nAmazon Web Services has the lion’s share of the infrastructure-as-a-service (IaaS) market, but Microsoft’s Azure is closing the gap with growth that is outpacing its top competitor.\n\nAzure adoption grew by 89 percent in the second quarter, ending Q2 with an 18 percent share of the market, according to a [report by Canalys](https://www.canalys.com/newsroom/cloud-infrastructure-spend-reaches-us%2420-billion-in-q2-2018-with-hybrid-it-approach-dominant), an independent analyst firm. While still in the lead with a 31 percent share of the market, AWS’s second quarter growth was substantially less at 48 percent. Google Cloud rounded out the top three performers of Q2, growing a massive 108 percent during the quarter. Google ended the quarter with an eight percent share of the cloud infrastructure services market. Azure, AWS, and Google Cloud account for 57 percent of the IaaS market, Canalys reports.\n\n#### Enterprise cloud spending is on the rise.\nCompanies are making heavy investments in the cloud, as seen by IDC’s decision to increase their 2018 spending prediction at the half-year mark. The market intelligence agency now expects to see a more than 21 percent increase in cloud infrastructure spending this year, which aligns with reports from enterprise survey respondents.\n\nTwenty percent of enterprises say they plan to more than double their public cloud spend in 2018, according to the State of the Cloud survey and 71 percent of the poll’s 997 respondents expect to increase their public cloud spend by more than 20 percent this year.\n\n#### Security remains a top cloud challenge.\nSecurity regularly ranks as the number one concern among cloud adopters. Seventy-seven percent of State of the Cloud respondents reported security as a challenge, with 29 percent finding it to be a significant hurdle, particularly for beginners. Sixty-six percent of those surveyed in LogicMonitor’s [Cloud Vision 2020: The Future of the Cloud Study](https://www.logicmonitor.com/resource/the-future-of-the-cloud-a-cloud-influencers-survey/) reported security as the biggest challenge for organizations operating in the public cloud.\n\nWith security being a top priority for enterprises working in the cloud, Forrester anticipates that security will become [“integrated with — and integral to — cloud platforms”](/security/) in 2018.\n\nCover photo by [Andrew Ruiz](https://unsplash.com/photos/P45gtJKufJo) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[1076,745,894],{"slug":3721,"featured":6,"template":681},"top-five-cloud-trends","content:en-us:blog:top-five-cloud-trends.yml","Top Five Cloud Trends","en-us/blog/top-five-cloud-trends.yml","en-us/blog/top-five-cloud-trends",{"_path":3727,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3728,"content":3734,"config":3739,"_id":3741,"_type":17,"title":3742,"_source":18,"_file":3743,"_stem":3744,"_extension":21},"/en-us/blog/leah-petersen-user-spotlight",{"title":3729,"description":3730,"ogTitle":3729,"ogDescription":3730,"noIndex":6,"ogImage":3731,"ogUrl":3732,"ogSiteName":667,"ogType":668,"canonicalUrls":3732,"schema":3733},"Motorcycle stunter turned DevOps engineer says GitLab helped her learn to \"love\" 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":3729,"description":3730,"authors":3735,"heroImage":3731,"date":3736,"body":3737,"category":14,"tags":3738},[3266],"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",[831,1076,723,852,974,268,806,1791],{"slug":3740,"featured":6,"template":681},"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":3746,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3747,"content":3753,"config":3758,"_id":3760,"_type":17,"title":3761,"_source":18,"_file":3762,"_stem":3763,"_extension":21},"/en-us/blog/gary-gruver-interview-post",{"title":3748,"description":3749,"ogTitle":3748,"ogDescription":3749,"noIndex":6,"ogImage":3750,"ogUrl":3751,"ogSiteName":667,"ogType":668,"canonicalUrls":3751,"schema":3752},"IT executives! Take the lead in DevOps transformations","Gary Gruver, author of \"Starting and Scaling DevOps in the Enterprise,\" shares his thoughts on the role of executives in a DevOps transformation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680072/Blog/Hero%20Images/gary-gruver-cover.jpg","https://about.gitlab.com/blog/gary-gruver-interview-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"IT executives! Take the lead in DevOps transformations\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-06-14\",\n      }",{"title":3748,"description":3749,"authors":3754,"heroImage":3750,"date":3755,"body":3756,"category":14,"tags":3757},[1635],"2018-06-14","\n\nThe changes in both workflow and culture during a DevOps transformation highlight the need for IT executives to guide development and operations teams. [Gary Gruver](http://www.garygruver.com), the renowned DevOps consultant, discovered that executives are essential in setting up teams to adopt a DevOps model successfully. Ahead of his June 19 webcast, Gary Gruver sat down with GitLab to share his thoughts on the greatest challenges that executives encounter and to provide tactical steps to help executives support their teams.\n\n## The role of an executive in the DevOps transformation is leading it.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://drive.google.com/file/d/1a9sGyFz9fW9zeXOa7MJGib8fUN4ZrIsA/preview\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n## One of the biggest challenges is getting everybody on the same page.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://drive.google.com/file/d/1d5w4GRRbHA2poHJocUT-4cBfW2KBEsw2/preview\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## One of the biggest things executives need to do to prepare their teams is giving a common view of the inefficiencies for the entire deployment pipeline.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://drive.google.com/file/d/1iseA7ifwF9qIkXDNQun9j0ps-b4_QfuK/preview\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## In terms of culture, executives can help teams adjust to the changes that are coming. Their role is to be that of an investigative reporter.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://drive.google.com/file/d/1788pyYj0QGx8z29YaP6PoseS-OJI_u_d/preview\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## When I work with executives, I always start with, \"What are the objectives about your software development processes?\"\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://drive.google.com/file/d/1ainmogqtovRD0QKq_gJW9XT3_Lii2Hbm/preview\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nJoin Gary Gruver for a webcast on June 19 to discover ways to analyze your current deployment pipeline to target your first improvements on the largest inefficiencies in software development and deployment, and [download your free copy](/resources/scaling-enterprise-devops/) of \"Starting and Scaling DevOps in the Enterprise.\"\n",[806],{"slug":3759,"featured":6,"template":681},"gary-gruver-interview-post","content:en-us:blog:gary-gruver-interview-post.yml","Gary Gruver Interview Post","en-us/blog/gary-gruver-interview-post.yml","en-us/blog/gary-gruver-interview-post",{"_path":3765,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3766,"content":3772,"config":3776,"_id":3778,"_type":17,"title":3779,"_source":18,"_file":3780,"_stem":3781,"_extension":21},"/en-us/blog/how-ux-research-impacts-product-decisions",{"title":3767,"description":3768,"ogTitle":3767,"ogDescription":3768,"noIndex":6,"ogImage":3769,"ogUrl":3770,"ogSiteName":667,"ogType":668,"canonicalUrls":3770,"schema":3771},"How UX research impacts product decisions","How GitLab UX researchers figure out how to turn your feedback into reality.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684792/Blog/Hero%20Images/ux-research-product-decisions.jpg","https://about.gitlab.com/blog/how-ux-research-impacts-product-decisions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How UX research impacts product decisions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Katherine Okpara\"}],\n        \"datePublished\": \"2018-06-12\",\n      }",{"title":3767,"description":3768,"authors":3773,"heroImage":3769,"date":3774,"body":3775,"category":14},[3000],"2018-06-12","\nAt GitLab, we’re always working to improve our product – whether we're tackling feature requests, fixing bugs, or gathering feedback on usability issues. To stay on top of this effort, our UX team uses a [workflow](/handbook/product/ux/#general-ux-workflow) that prioritizes open issues, tracks progress, and schedules research to support design improvements.\n\nOur UX team works to meet the needs and requests of our users while continuing to move our product in the right [direction](/direction/). While users can easily see and interact with improvements to GitLab’s UI design, the research and discussion that led to many of these decisions are often not visible. Let’s take a look at how UX research is conducted at GitLab!\n\n### What is User Experience (UX) research?\n\nThe goal of UX research is to understand the needs and concerns of users, often by observing how they interact with a product. A UX researcher serves as a bridge between users, developers, designers, and product managers alike.\n\n### Devising a plan of action\n\nIf someone is interested in exploring a research question, we encourage them to create a new issue using the “Research Proposal” template in our [UX Research project](https://gitlab.com/gitlab-org/ux-research). This template prompts the contributor to describe their questions and identify any assumptions or theories they may have. Providing a template is a useful way to encourage contributors to flesh out their research requests, search for prior research or related issues, and pinpoint the exact problems that need to be addressed.\n\nMany contributors also add the [“UX Research” label](https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=UX+research) to issues that need some research before a decision can be made. GitLab UX researchers review a backlog of issues that are open in the [UX Research](https://gitlab.com/gitlab-org/ux-research), [CE](https://gitlab.com/gitlab-org/gitlab-ce), and [EE](https://gitlab.com/gitlab-org/gitlab-ee) projects each month, to check if related studies already exist or if new studies should be scheduled.\n\nThis process is important for understanding the goals of a research request, scoping the work, and conducting research efficiently.\n\n![Research Proposals](https://about.gitlab.com/images/blogimages/how-ux-research-impacts-product-decisions/research-proposals.png){: .shadow.medium.center}\n\n### Conducting research studies\n\nAfter reviewing proposals and prioritizing the issues to tackle in a particular milestone, we figure out the types of research studies to conduct. Some of our most common [remote UX research methods](/blog/conducting-remote-ux-research/) include survey research, usability testing, first-click testing, and card-sorting. A great way to choose a research method is to ask yourself what you'd like to learn, who you need to reach, and how you want to communicate your questions to the participants (e.g. visually or verbally).\n\nRecently we conducted a research study in support of our [product vision for Concurrent DevOps](/direction/). Since GitLab was initially more developer focused, the purpose of this study was to reach out directly to people who work in operations and understand the needs and challenges they face in their roles. To ensure that we reached a broader audience, we conducted a survey followed by user interviews. We learned a lot about the needs of professionals in operations, including their responsibilities, the tools they use, and the versatility of their roles.\n\n### Interpreting data and summarizing results\n\nIn order to get the word out about our research, we documented the findings in a [report](https://drive.google.com/file/d/1sgPETOKc53QBLvd438gPljRRjeBOm8jr) and [shared it on GitLab.com](https://gitlab.com/gitlab-org/ux-research/issues/56).\n\nThe top challenges faced by participants were lack of automation, redundant tools, insufficient resources, and difficulty adopting the culture of DevOps.\n\n#### Lack of automation\nAlmost half of all respondents stated that at least 40 percent or more of their work was manual and that a lack of automation has caused technical debt. They recognize that creating a scalable, repeatable and automated process for all projects to follow could save them a lot of time.\n\n#### Redundant tools\nOver half of respondents (55 percent) working in a large DevOps team (5+ people) felt that there were many overlapping tools being used for DevOps across their organization. Due to the difficulty of understanding and maintaining these toolchains, unifying all tools into a single, cohesive platform could benefit many mid-to-large organizations.\n\n#### Insufficient resources\nSoftware engineers at small organizations (fewer than 100 employees) were often responsible for taking on operations-related duties in addition to development. In contrast, mid-to-large organizations were more likely to have DevOps Engineers, System Administrators, and Site Reliability Engineers handling DevOps tasks. However, even at larger organizations, many participants still felt that they did not have enough resources on their team. 65 percent of respondents said that there weren't enough people in their team to accomplish all DevOps tasks.\n\n#### Difficulty adopting the culture of DevOps\nMany participants also found it hard to get “buy-in” from stakeholders and communicate the value of DevOps workflows to their organizations. Some even stated that their colleagues were “stuck in their ways,” used “old and bad habits,” or had a reluctance to change. Responses also indicated that some senior leaders and managers don't completely understand the time and resources it takes to implement new DevOps workflows.\n\nOverall, our findings indicated that a better understanding of DevOps as a philosophy, culture, and workflow benefits both team efficiency and morale.\n\n![DevOps](https://about.gitlab.com/images/blogimages/how-ux-research-impacts-product-decisions/devops-loop.png){: .medium.center}\n\n### Creating a plan of action\n\nThe operations research initiative was particularly helpful because it not only showed us limitations in our product, but also led to follow-up discussions and ideas for improvement. Equipping our UX, Product, and Development teams with this insight gave everyone a better sense of the audience we’re designing for and what users hope to accomplish with GitLab.\n\nFor example, we learned that users typically monitor 1-100 performance/system health metrics across 1-5 dashboards and that the most common metrics being tracked on their primary dashboard include CPU, memory, system availability, request rates, and response time/status. Considering the issues that arise from a lack of resources, complex tools, and the amount of metrics users are monitoring, it's apparent that many users are in need of solutions for streamlining their workflow. As we continue to design the [Operations dashboard](https://gitlab.com/gitlab-org/gitlab-ee/issues/1788), we will use these findings to create a flexible solution for both monitoring and management.\n\nCheck out our [product vision page](https://about.gitlab.com/direction/) to see all of the key DevOps areas that we are working on in 2018.\n\n### The broader impact of UX\n\nUX research and design are not only important for delivering positive user experiences. The impact of UX can be found in many aspects of business and technology, such as promoting brand loyalty, delivering higher quality products, creating insightful pitch decks, product roadmapping, and much more. Everyone in a company can play a role in contributing to better user experiences by maintaining open dialogue and encouraging collaborative workflows.\n\nPhoto by [Green Chameleon](https://unsplash.com/photos/s9CC2SKySJM?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/research?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",{"slug":3777,"featured":6,"template":681},"how-ux-research-impacts-product-decisions","content:en-us:blog:how-ux-research-impacts-product-decisions.yml","How Ux Research Impacts Product Decisions","en-us/blog/how-ux-research-impacts-product-decisions.yml","en-us/blog/how-ux-research-impacts-product-decisions",{"_path":3783,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3784,"content":3790,"config":3795,"_id":3797,"_type":17,"title":3798,"_source":18,"_file":3799,"_stem":3800,"_extension":21},"/en-us/blog/top-five-takeaways-from-the-developer-survey",{"title":3785,"description":3786,"ogTitle":3785,"ogDescription":3786,"noIndex":6,"ogImage":3787,"ogUrl":3788,"ogSiteName":667,"ogType":668,"canonicalUrls":3788,"schema":3789},"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":3785,"description":3786,"authors":3791,"heroImage":3787,"date":3792,"body":3793,"category":14,"tags":3794},[3266],"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",[806,722,2254,1255,974],{"slug":3796,"featured":6,"template":681},"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":3802,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3803,"content":3808,"config":3814,"_id":3816,"_type":17,"title":3817,"_source":18,"_file":3818,"_stem":3819,"_extension":21},"/en-us/blog/test-automation-devops",{"title":3804,"description":3805,"ogTitle":3804,"ogDescription":3805,"noIndex":6,"ogImage":926,"ogUrl":3806,"ogSiteName":667,"ogType":668,"canonicalUrls":3806,"schema":3807},"Trust, but verify: The importance of software test automation","Guest author Steve Ropa explains what a Cold War era motto has to do with test automation (seriously) and bringing development and operations closer together.","https://about.gitlab.com/blog/test-automation-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Trust, but verify: The importance of software test automation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steve Ropa\"}],\n        \"datePublished\": \"2018-04-23\",\n      }",{"title":3804,"description":3805,"authors":3809,"heroImage":926,"date":3811,"body":3812,"category":14,"tags":3813},[3810],"Steve Ropa","2018-04-23","\nThis article is about software [test automation and DevOps](/topics/devops/), but bear with me a moment before we go there. Back during the Cold War, there were many discussions about how to improve relations and reduce the number of nuclear missiles countries were pointing at each other. During these talks, one of the biggest sticking points was how much the two countries could trust each other, and if they couldn’t, how they maintained their sovereignty while under some form of arms control agreement. They eventually agreed upon a regime of agreeing to perform certain actions, with periodic inspections on each side to confirm that said actions would happen, based on the Russian proverb, “trust, but verify.”\n\n## Trust but verify: DevOps requires trust\n\n“Trust, but verify” is commonly used with reference to security, but needs to be the motto for a good DevOps automation pipeline as well. First, for all the developers who ask, “Why should I care about DevOps?” I just want to mention that the key to success in *any* type of development is a short feedback loop and truly safe code. DevOps is a fantastic mechanism for helping us achieve that, by taking the valuable technical practices we’ve learned and applying them frequently and smoothly. DevOps as a cultural phenomenon relies heavily on Lean principles and on the concept of “trust-based management” where we put our trust in the teams to be professional craftsmen. This is important and can’t be overstated. We hire professional developers to do professional development, and we must trust them to get the job done.\n\n## Trust but verify: Today’s world requires verification\n\nAnd yet, there is a challenge. In most cases, software is not being created in a vacuum. We must make sure we are integrating well with the rest of the system. Sometimes, we have legal requirements like [Sarbanes-Oxley compliance](https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act). In the past, we would schedule a large block of time to do all the integration and compliance testing. Now, we are saying, “Trust us, we will do the right thing” and deploying to production as quickly as is practicable. This is where automated testing comes into play.\n\n## Three categories of verification\n\nLet’s break this into three categories: Unit, System, and Compliance. This may not be the breakdown we usually think of, but bear with me. Unit testing is the most commonly discussed level of testing among modern developers. We write small, concise tests that exercise the code under development, ensuring it does what we intend it to do. Preferably we are doing test-driven development, and writing the tests prior to the code, but that is a blog for another time. Under the heading of “trust, but verify,” rather than slow down our development cycle with code review gates and, dare I say it, maybe even merge requests, we allow teams to check code in whenever they feel the need. Then we verify that we haven’t done anything untoward by running the automated unit tests on the build environment. This level of verification isn’t enough to ensure a truly high-quality system, but the lack of this level of verification is a definite step on the road to perdition.\n\n## System-level verification\n\nI like to use System testing to describe the various next level tests. This would be any system-wide tests, such as Acceptance, Integration, and possibly Performance testing. Unfortunately, many development teams stop at automated unit tests. They give lip service to automating other tests “when we have time.” And we know when that is. So, it gets skipped. Or is treated as a luxury. Since we often don’t have enough time to do all this testing manually either, we end up with defects and low-quality user experiences, which erodes trust in our teams’ ability to create and innovate. This downward spiral usually ends with organizations building giant processes and Change Advisory Boards to slow down the pace of change, all in the name of safety.\n\nSo instead, we trust our team to create innovative software, working closely with their customer or other representatives of said customer. To verify the teams are creating the right software, we represent the needs of the customer in terms of tests. These tests are automated to begin with, again preferably before creating the actual product. Then, we include the automated System tests into the DevOps pipeline, running with each check in. Now we can feel safe that the system is stable and represent the customers’ needs to the best of our ability to understand them.\n\n## Safety\n\nLastly, we need to verify that our teams are creating safe software. There are some excellent tools for automated security and safe programming scans. Include these as well into your pipeline. If they take too long, you can consider an alternate pipeline that runs less frequently, but start by running with each check in, until you feel that it just is getting too bogged down.\n\nIn the end, we are back to the basic statement, “trust but verify.” We won’t put massive processes and boards of review in place, slowing down the pace of development. We won’t create giant overarching architectures and just allow our developers to “fill in the blanks.” We will present them with the needs of the system and trust them to develop great software. Meanwhile, we will support them by verifying, many times a day, that they are still on track. Hey, if it worked for nuclear weapons, surely it can work for software.\n\n## About the guest author\n\nSteve Ropa is a Co-founder and Master Craftsman at the [Rocky Mountain Programmers Guild](https://www.rmprogrammers.com/) in Denver, Colorado, where he brings his long career of successful software delivery to elevate developers and teams to new levels of performance and Craftsmanship.\n\n[Photo](https://unsplash.com/photos/GNyy-D-SNN8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by Guillaume Lebelt on [Unsplash](https://unsplash.com/search/photos/patterns?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[806,935],{"slug":3815,"featured":6,"template":681},"test-automation-devops","content:en-us:blog:test-automation-devops.yml","Test Automation Devops","en-us/blog/test-automation-devops.yml","en-us/blog/test-automation-devops",{"_path":3821,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3822,"content":3828,"config":3833,"_id":3835,"_type":17,"title":3836,"_source":18,"_file":3837,"_stem":3838,"_extension":21},"/en-us/blog/remote-work-facilitates-devops",{"title":3823,"description":3824,"ogTitle":3823,"ogDescription":3824,"noIndex":6,"ogImage":3825,"ogUrl":3826,"ogSiteName":667,"ogType":668,"canonicalUrls":3826,"schema":3827},"People agree that remote work in DevOps creates a stronger DevOps culture","What makes remote work more conducive to DevOps adoption? Here's a look at one of the findings of our 2018 Global Developer Report.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680149/Blog/Hero%20Images/devopsremotework.jpg","https://about.gitlab.com/blog/remote-work-facilitates-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"People agree that remote work in DevOps creates a stronger DevOps culture\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-04-17\",\n      }",{"title":3823,"description":3824,"authors":3829,"heroImage":3825,"date":3830,"body":3831,"category":14,"tags":3832},[1635],"2018-04-17","\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nAccording to our [2018 Global Developer Report](/developer-survey/previous/2018/), remote teams tend to trend higher in visibility and DevOps satisfaction compared to in-office teams, suggesting that a remote workplace culture is more conducive to DevOps adoption.\n\n![The differences between remote and in-office teams](https://about.gitlab.com/images/blogimages/devopsremotestats.png){: .shadow.medium.center}\n\nAs a [remote-only](/company/culture/all-remote/) company, this finding naturally piqued our interest. We started thinking about the traits of a remote team and how these characteristics set up operations and development teams for success.\n\n## The challenges of DevOps adoption\n\nOne of the greatest difficulties an organization faces when adopting a DevOps model is a [resistance to culture change](https://www.cio.com/article/3235726/application-development/5-hurdles-to-adopting-devops.html). Because DevOps requires teams to collaborate and communicate in new ways (and at an increasing frequency), historically siloed teams may have trouble adjusting. This type of radical shift in culture can be too difficult for a team to handle and may result in an increase in friction and frustration.\n\nHow can teams that have traditionally worked alongside each other – [but not together](https://www.wired.com/insights/2015/03/culture-war-struggle-adopt-devops/) – suddenly adopt a model that encourages them to contribute to a single conversation across every stage?\n\n## Remote work paves the way to a smoother transition\n\nIn our survey we learned that [20 percent of respondents](/developer-survey/previous/2018/) say most or all of their development team works remotely. Every remote worker knows the importance of [communicating effectively](/blog/remote-communication/) and frequently to ensure that others are aware of decisions and progress. Without the convenience of physical proximity, working remotely requires a commitment to open discussion and an understanding that team members must be able to easily view projects and receive updates. Furthermore, remote teams use tools to work concurrently, decreasing the challenges of siloed workflows.\n\nAn effective remote culture embraces:\n\n- efficiency\n- collaboration\n- visibility\n\nWhen operations and development teams already have a culture founded on trust and transparency, they can more easily adopt a model that fosters cross-functional communication and workflows.\n\nRemote teams are already accustomed to transparency, collaboration, and visibility, making a DevOps adoption a seamless transition. Because teams must document discussion conclusions, an inherent benefit of working remotely is complete real-time visibility of all projects and activities, an advantage of the DevOps model.\n\n## How can in-office teams ease DevOps adoption?\n\nWhile a remote workplace culture appears to create a solid foundation upon which a DevOps model can thrive, we concede that remote teams can still encounter challenges to adoption. Poor communication, internal conflict, and a lack of defined processes can hinder any team. However, there are insights that in-office teams can gain from these findings. Because culture is the underpinning of successful DevOps adoption, in-office teams can ease challenges by encouraging teams to work concurrently and by transparently documenting conversations and decisions. Furthermore, a shift towards empathy can help teams gain respect for the work that others accomplish, a change that can increase collaboration and decrease friction.\n\nBy creating a collaborative culture, an organization can facilitate a smoother [transition to a DevOps model](/blog/a-snapshot-of-modern-devops-practices-today/).\n\nDoes your development team work remotely? Let’s chat about DevOps and remote working! Tweet us [@gitlab](https://twitter.com/gitlab).\n\n[Cover image](https://www.pexels.com/photo/high-angle-view-of-workplace-306533/) licensed\nunder [CC X](https://www.pexels.com/photo-license/)\n{: .note}\n",[785,806,722],{"slug":3834,"featured":6,"template":681},"remote-work-facilitates-devops","content:en-us:blog:remote-work-facilitates-devops.yml","Remote Work Facilitates Devops","en-us/blog/remote-work-facilitates-devops.yml","en-us/blog/remote-work-facilitates-devops",{"_path":3840,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3841,"content":3847,"config":3852,"_id":3854,"_type":17,"title":3855,"_source":18,"_file":3856,"_stem":3857,"_extension":21},"/en-us/blog/avoiding-devops-tax-webcast",{"title":3842,"description":3843,"ogTitle":3842,"ogDescription":3843,"noIndex":6,"ogImage":3844,"ogUrl":3845,"ogSiteName":667,"ogType":668,"canonicalUrls":3845,"schema":3846},"How to avoid the DevOps tax","Realize a faster DevOps lifecycle with these best practices for integration and automation – watch our recent webcast with guest speaker Forrester Senior Analyst Christoper Condo and GitLab Head of Product Mark Pundsack.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670214/Blog/Hero%20Images/devops-nova-scotia-cover.jpg","https://about.gitlab.com/blog/avoiding-devops-tax-webcast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to avoid the DevOps tax\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2018-03-21\",\n      }",{"title":3842,"description":3843,"authors":3848,"heroImage":3844,"date":3849,"body":3850,"category":14,"tags":3851},[3265],"2018-03-21","\n\nWith the influx of DevOps-related products and services on the market, today’s application delivery toolchain has become complex and fragmented, resulting in more time spent on integrating tools instead of software innovation. Mark Pundsack, Head of Product at GitLab, and guest speaker Christopher Condo, Senior Analyst at Forrester, recently met to discuss the current state of [DevOps automation](/topics/devops/) and how IT leaders can unlock themselves from today’s toolchain to avoid the “DevOps tax.”\n\n\u003C!-- more -->\n\n- [What is the DevOps tax?](#what-is-the-devops-tax)\n- [What's in the webcast?](#whats-in-the-webcast)\n- [Watch the recording](#watch-the-recording)\n- [Key takeaways](#key-takeaways)\n\n## What is the DevOps tax?\n\nIn a typical DevOps toolchain, lots of different tools are tied together to deliver DevOps. You have different tools for planning, code creation, CI and security testing, packaging, release and deploy, configuration management, and monitoring.\n\nBut administrating all these products and connecting them together is complex. For example, your CI needs to talk to your version control, your code review, your security testing, your container registry, and your configuration management. The permutations are staggering, and it’s not just a one-time configuration – each new project needs to reconnect all these pieces together.\n\nThat's the DevOps tax: time spent on integrating and maintaining complicated toolchains, limiting your efficiency.\n\n## What's in the webcast\n\nBefore we dive into the DevOps tax and how to avoid it, we start by looking at digital transformation and current trends in DevOps, leading up to the DevOps tax, and then offering some best practices for reducing friction.\n\n## Watch the recording\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/iIElDMEC3U0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Key takeaways\n\n### The digital transformation imperative\n\n\u003Cdiv class=\"panel panel-default twitter-block\"> \u003Ca class=\"twitter-block-link panel-body\" href=\"http://twitter.com/share?text=%22When we think about digital transformation, we think about and talk about delivering value to your customer quickly, repeatedly, and with high quality%22 – guest @forrester via @GitLab webinar; url=/2018/03/21/avoiding-devops-tax-webcast/;hashtags=\" rel=\"nofollow\" target=\"_blank\" title=\"Tweet!\"> \u003Cspan class=\"twitter-text pull-left\"> \"When we think about digital transformation, we think about and talk about delivering value to your customer quickly, repeatedly, and with high quality\" – guest @forrester via @GitLab webinar\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#### Customer experience is key\n\n>The people with the bad customer experience, their stock is lagging those companies that have an excellent customer experience. That's showing you that customer experience really matters - Christopher Condo\n\n#### Expect disruption\n\n>The common thread is placing the customer first. If there's a place where the customer's not being placed first, and some company can come along with an innovative way to do it, it seems like the government is open to it and customers are certainly open to it as well - Christopher Condo\n\n### Trends in DevOps\n\n#### Better integration of tools\n\n\u003Cdiv class=\"panel panel-default twitter-block\"> \u003Ca class=\"twitter-block-link panel-body\" href=\"http://twitter.com/share?text=%22You don't want people handcrafting all their tool chains all the time. You don't want a situation where every time an engineer changes teams he has to learn a whole new set of tools%22 – guest @forrester via @GitLab webinar;url=/2018/03/21/avoiding-devops-tax-webcast/;hashtags=\" rel=\"nofollow\" target=\"_blank\" title=\"Tweet!\"> \u003Cspan class=\"twitter-text pull-left\"> \"You don't want people handcrafting all their tool chains all the time. You don't want a situation where every time an engineer changes teams he has to learn a whole new set of tools\" – guest @forrester via @GitLab webinar \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>I just ran a Wave on continuous integration tools and customers told us loud and clear that they are looking for a complete, integrated toolchain because they're tired of integrating their own toolchain. It's great to have the integrated tool chain but it comes at a cost - Christopher Condo\n\n#### Better integration of teams\n\n>They want to be able to check in with the security expert and say, \"Here's our design, here's our architecture, here's how we're handling these problems. What are we missing? What do we need to be doing next?\" All of those teams sort of act as shared resources, they don't act as blockers on a particular project - Christopher Condo\n\n#### Containers are critical\n\n\u003Cdiv class=\"panel panel-default twitter-block\"> \u003Ca class=\"twitter-block-link panel-body\" href=\"http://twitter.com/share?text=%22Containers allow folks to worry about what they're best at rather than trying to have everybody know everything – guest @forrester via @GitLab webinar; url=/2018/03/21/avoiding-devops-tax-webcast/; hashtags=\" rel=\"nofollow\" target=\"_blank\" title=\"Tweet!\"> \u003Cspan class=\"twitter-text pull-left\"> \"Containers allow folks to worry about what they're best at rather than trying to have everybody know everything\" – guest @forrester via @GitLab webinar \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### What is the DevOps tax?\n\n>When it's a pain to integrate security, how many teams just don't bother? Or when it's a pain to share information between teams, how many organizations overcome that burden and find a way to work together? How much impact does this tax have on collaboration? With separate tools and separate processes, we're naturally encouraging separate silos where functional teams work in isolation - Mark Pundsack\n\n### Concurrent DevOps\n\n\u003Cdiv class=\"panel panel-default twitter-block\"> \u003Ca class=\"twitter-block-link panel-body\" href=\"http://twitter.com/share?text=%22When the entire DevOps lifecycle is seamless, magic starts to happen. Teams can work concurrently, not sequentially – @MarkPundsack via @GitLab;url=/2018/03/21/avoiding-devops-tax-webcast/;hashtags=\" rel=\"nofollow\" target=\"_blank\" title=\"Tweet!\"> \u003Cspan class=\"twitter-text pull-left\"> \"When the entire DevOps lifecycle is seamless, magic starts to happen. Teams can work concurrently, not sequentially\" – @MarkPundsack 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### DevOps best practices\n\n- To maximize your digital transformation, you need to optimize your CI/CD pipeline, create integrated product teams, and modernize your application architecture with microservices and a cloud native approach.\n- Avoid the DevOps tax by reducing the number of integration points in your toolchain, integrate as deeply as you can, and strive for a single conversation across development, operations, security and business.\n- If you’re just getting started, start with continuous integration. Automating tests and building confidence in your code will pay dividends many times over.\n- If you already got CI, then move on to continuous delivery. Automate deployments and make them less scary. If you already started the DevOps transformation, then embrace the culture. You can only go so far when there’s a wall between dev and ops.\n\u003Cbr>\u003Cbr>\n",[806,2254],{"slug":3853,"featured":6,"template":681},"avoiding-devops-tax-webcast","content:en-us:blog:avoiding-devops-tax-webcast.yml","Avoiding Devops Tax Webcast","en-us/blog/avoiding-devops-tax-webcast.yml","en-us/blog/avoiding-devops-tax-webcast",{"_path":3859,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3860,"content":3865,"config":3870,"_id":3872,"_type":17,"title":3873,"_source":18,"_file":3874,"_stem":3875,"_extension":21},"/en-us/blog/managers-more-optimistic-than-developers",{"title":3861,"description":3862,"ogTitle":3861,"ogDescription":3862,"noIndex":6,"ogImage":1047,"ogUrl":3863,"ogSiteName":667,"ogType":668,"canonicalUrls":3863,"schema":3864},"How do developers and managers feel about their jobs?","How do you assess job satisfaction? Here's a look inside the findings and methods of our Global Developer Report.","https://about.gitlab.com/blog/managers-more-optimistic-than-developers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How do developers and managers feel about their jobs?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2018-03-20\",\n      }",{"title":3861,"description":3862,"authors":3866,"heroImage":1047,"date":3867,"body":3868,"category":14,"tags":3869},[1868],"2018-03-20","\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nOne of the goals of our [2018 developer survey](/developer-survey/previous/2018/) was to establish a benchmark for how satisfied software professionals generally are in their jobs. Using the detailed demographic information we captured at the beginning, we were able to sort and compare the opinions of different groups within our sample of over 5,000 respondents. One of our key findings was that, for all their differences, developers and managers agree with each other on a lot of things, but managers tend to have a slightly rosier outlook when their views diverge.\n\n\u003C!-- more -->\n\n### How we determined overall satisfaction\n\nSurveys are tricky, and humans are trickier, so we had to brainstorm a bit on what exactly we were interested in learning, and [how](http://www.pewresearch.org/methodology/u-s-survey-research/questionnaire-design/) we could coax out this information without introducing our own biases. We used a series of [likert scales](https://www.surveymonkey.com/mp/likert-scale/) to get at these groups’ perceptions of their autonomy, team dynamics, support, and other fuzzy things that we think can really drive happiness in a role (we also asked about details on tooling and workflow [later on](/developer-survey/previous/2018/) in the survey). We’ve [published before](https://medium.com/@gitlab/invite-your-engineers-to-talk-business-heres-why-485ce02c4d18) on what happens when your business and engineering teams are out of sync, and we wanted to ask about other symptoms of that same problem. Here are some of the questions, along with the raw data that we used to compare satisfaction between developers and management.\n\n\u003Cstyle type=\"text/css\">\n.tg  {border-collapse:collapse;border-spacing:0;}\n.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}\n.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}\n.tg .tg-9hbo{font-weight:bold;vertical-align:top}\n.tg .tg-yw4l{vertical-align:top}\n\u003C/style>\n\u003Ctable class=\"tg\">\n  \u003Ctr>\n    \u003Cth class=\"tg-9hbo\">Managers\u003C/th>\n    \u003Cth class=\"tg-9hbo\">%\u003C/th>\n    \u003Cth class=\"tg-9hbo\">Developers\u003C/th>\n    \u003Cth class=\"tg-9hbo\">%\u003C/th>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team is set up to succeed\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">84\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">I feel set up to succeed\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">75\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team is given realistic deadlines\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">68\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">I’m given realistic deadlines\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">65\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">Project expectations are set up front\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">60\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">Project expectations are set up front\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">50\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team rarely needs to sacrifice quality to meet a deadline\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">53\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">I rarely need to sacrifice quality to meet a deadline\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">50\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team is able to make decisions about their work\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">91\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">It’s important to me to be able to make decisions about my work\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">96\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team has the authority to make decisions\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">88\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">I have the authority to make decisions about my work\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">83\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team's ideas and opinions are valued\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">93\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">My ideas and opinions are valued\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">84\u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n    \u003Ctd class=\"tg-yw4l\">My team has access to the best development tools\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">81\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">I have access to the best development tools\u003C/td>\n    \u003Ctd class=\"tg-yw4l\">74\u003C/td>\n  \u003C/tr>\n\u003C/table>\n\n\n### Tying individual attitudes to culture\n\nWhat are some other things that might contribute to a frustrating or dysfunctional culture? To try to hint at big, sometimes implicit things like psychological safety, bureaucracy, and whether their team is more democratic or autocratic, we had to come up with a list of concrete indicators, which you can see below:\n\n\u003Ccenter>\u003Cimg src=\"/images/blogimages/biggest-challenges-chart.png\" alt=\"biggest challenges to adopting new tools and practices\" class= \"shadow\" style=\"width: 700px;\"/>\u003C/center>\n\nWhen we asked about the biggest challenges teams face when adopting new processes or tools, the top three responses were replacing ingrained practices, resistance to change, and cross-team communication. Developers and managers are in agreement here almost exactly, although developers are slightly more likely to name resistance to chance (51 percent) than managers (46 percent).\n\nWe saw this echoed in other ways, with the greatest number of developers (42 percent) naming unclear direction as their top challenge to getting work done. Relatedly, just 57 percent of developers say they have visibility into what their team members in operations, security, and product are working on. Managers feel slightly better off in this regard, with 69 percent reporting that they have visibility (we also found some differences in how remote versus in-office teams view the issue, which you can read more about [here](/developer-survey/previous/2018/)).\n\n### What we want to learn next\n\nCommunication, and structures or habits that might enable or impede it, is a theme that we’re interested in learning more about. It’s a predictable problem with no easy fix, so we ran a Twitter poll to get some input on how teams have wrestled with communication issues in the past.\n\nOne suggestion for how to overcome the cultural barriers to adopting DevOps is to embed team members to improve cross-team collaboration, but that doesn’t always seem doable because it’s an organizational change, requiring buy-in from many more people than just the developers involved. It wasn’t surprising, then, that this option was chosen the least. Regular social activities and working sessions seem like much cheaper options, but were barely more popular. The greatest number of people simply chose our equivalent of ¯\\\\\\_(ツ)_/¯.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">We heard from developers that miscommunication is a major challenge to getting work done \u003Ca href=\"https://t.co/Cvqwnf5tVH\">https://t.co/Cvqwnf5tVH\u003C/a>. \u003Cbr>\u003Cbr>What's the best way to improve communication issues between teams in your engineering organization?\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/973648916536205312?ref_src=twsrc%5Etfw\">March 13, 2018\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWe heard from a few devs about solutions that didn’t make our short list, and they’re rarely about just talking to each other more. Tellingly, the responses we got were much more likely tying communication to big, pervasive cultural things, like compensation incentives and respect for others’ work.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-conversation=\"none\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Mutual respect and interest in the work of others. Especially between different but collaborating professions like design and development but also within a group of the same type.\u003C/p>— ᴄɪᴛɪᴢᴇɴ ᴅʀᴀɪɴ (@Citizen_Drain) \u003Ca href=\"https://twitter.com/Citizen_Drain/status/973671170808696832?ref_src=twsrc%5Etfw\">March 13, 2018\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-conversation=\"none\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Writing documentation, and planning. Old skool and works.\u003C/p>— Peter Bowyer (@peterbowyer) \u003Ca href=\"https://twitter.com/peterbowyer/status/973650507930664966?ref_src=twsrc%5Etfw\">March 13, 2018\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWhen we [asked](https://twitter.com/gitlab/status/974023284953006080) Netflix engineer Randall Koutnik for more details on his tweet (below) he [wrote a post](https://rkoutnik.com/2018/03/17/incentivize-teams-not-people.html) with examples of how dev teams can be undermined by policies tying financial incentives and promotion criteria to individual performance goals, rather than company performance.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-conversation=\"none\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Too many companies financially incentivize against teamwork. If my bonus is determined by me hitting my objectives, then it's counterproductive to help others instead of focusing in on my own work.\u003C/p>— Randall Koutnik (@rkoutnik) \u003Ca href=\"https://twitter.com/rkoutnik/status/973689841870229507?ref_src=twsrc%5Etfw\">March 13, 2018\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWhy is this predictable problem so stubborn? What has your team tried? Tweet us [@gitlab](https://twitter.com/gitlab).\n\nPhoto by [Dylan Gillis](https://unsplash.com/photos/KdeqA3aTnBY) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[722,831,806],{"slug":3871,"featured":6,"template":681},"managers-more-optimistic-than-developers","content:en-us:blog:managers-more-optimistic-than-developers.yml","Managers More Optimistic Than Developers","en-us/blog/managers-more-optimistic-than-developers.yml","en-us/blog/managers-more-optimistic-than-developers",{"_path":3877,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3878,"content":3883,"config":3888,"_id":3890,"_type":17,"title":3891,"_source":18,"_file":3892,"_stem":3893,"_extension":21},"/en-us/blog/2018-global-developer-report",{"title":3879,"description":3880,"ogTitle":3879,"ogDescription":3880,"noIndex":6,"ogImage":986,"ogUrl":3881,"ogSiteName":667,"ogType":668,"canonicalUrls":3881,"schema":3882},"Global Developer Report confirms 2018 is the year for open source and DevOps","We surveyed over 5,000 software professionals to examine current attitudes and perception of the state of culture, workflow, and tooling within IT organizations.","https://about.gitlab.com/blog/2018-global-developer-report","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Global Developer Report confirms 2018 is the year for open source and DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2018-03-07\",\n      }",{"title":3879,"description":3880,"authors":3884,"heroImage":986,"date":3885,"body":3886,"category":14,"tags":3887},[3451],"2018-03-07","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nFrom the junior developer with just a handful of years’ experience to the software professional who’s been in the game for decades, we set out to see how the people behind the software are dealing with a rapidly changing technology landscape. This year’s survey reveals that unclear direction is a developer’s greatest challenge, IT managers are investing the most in continuous integration and delivery, and nearly all agree that the importance of open source cannot be overstated.\n\n\u003C!--more -->\n\nThe focus of [GitLab’s 2018 Global Developer survey](/developer-survey/previous/2018/) was to understand developers’ attitudes toward their workplace, uncover disparities between developers and their management, and benchmark the state of culture, workflow, and tooling within IT organizations. We asked a broad set of questions covering everything from developers’ opinions on their teams’ ability to collaborate and succeed at work to their preferences on workflow methodology and tooling.\n\n\u003Cdiv style=\"text-align: center\"> 🎙\u003Cstrong>\u003Ca href=\"https://webinars.devops.com/top-5-takeaways-from-the-2018-global-developer-survey\"> Join us March 29 for a live discussion with Alan Shimel of DevOps.com on the top 5 takeaways from the report\u003C/a> \u003C/strong> 🎙 ️\u003C/div>\n\n## Developer satisfaction\n\nWe found that the majority of developers are satisfied with the conditions of their workplace, and managers should focus on improving the planning and testing phases of the development lifecycle. We also found that IT management is more optimistic in their perception of overall workplace satisfaction with roughly 10 percent more respondents agreeing their team is set up to succeed, and that project requirements and deadlines are set up front.\n\n\u003Cimg src=\"/images/blogimages/2018-developer-report-stats_2x.jpg\" alt=\"2018 Developer Report\" style=\"width: 900px;\"/>\n\nDelays during the planning phase emerged as a top challenge for all respondents and unclear direction remains the greatest challenge to getting work done for developers.\n\n## DevOps\n\nCommitment to and demand for DevOps is growing, despite challenges posed by outmoded tooling and cultural resistance to change. Adoption is still in early stages, with 23 percent identifying DevOps as their development methodology, but this is sure to increase with IT management naming it as one of their top three areas for technology investment in 2018. The tide of developer opinion is following suit: we found that the majority of developers agree that a DevOps workflow saves valuable time during the development process. Teams currently practicing DevOps confirm the productivity gains – high performers, who told us they deploy their code on demand, and who estimated that they spend 50 percent or more of their time on new work, report having a clear DevOps culture at rates more than double that of lower-performing teams.\n\n## Open source\n\nOpen source projects like [Kubernetes](/blog/containers-kubernetes-basics/) and [CoreOS](/blog/coreos-acquisition/) have gained a lot of recent attention and this year’s survey underscores the value of creating software in the open. 92 percent of total respondents agree that open source tools are important to software innovation and nearly 50 percent report that most of their tools are open source.\n\n## About the 2018 survey\n\nGitLab surveyed 5,296 software professionals of varying backgrounds and industries around the world. The margin of error is two percent, assuming a population size of 21 million software professionals and 99 percent confidence level.\n\n## Methodology\n\nWe launched this Global Developer Survey on November 17, 2017, collecting responses\nuntil December 18, 2017. During that time, we promoted the survey primarily on GitLab’s\nsocial media channels and newsletter. In order to correct for the gender imbalance\ndeveloping in our survey sample, we made an extra push via Twitter on December 5 to encourage\nwomen involved in the software development lifecycle to take the survey. By the end of the open\nperiod, we achieved approximately 25 percent female respondents, the same percentage of women who currently\nhold computing roles, according to [NCWIT](https://www.ncwit.org/sites/default/files/resources/womenintech_facts_fullreport_05132016.pdf).\n\n| Frequently asked questions |\n| -------- | -------- |\n| **How can I access the report?**   | You can view the complete report [here](/developer-survey/).   |\n| **Are the raw results publicly available?**  | Yes, you can view the raw data [here](https://www.surveymonkey.com/results/SM-G3S6S63P8/).   |\n| **Did only GitLab users take the survey?** | No, it was open to all who work in software production. You can view the survey demographics [here](/developer-survey/).  |\n| **How can I ask questions or give feedback about the survey and results?** | You can direct questions or comments about the survey to [surveys@gitlab.com](mailto:surveys@gitlab.com). |\n| **I’d like to participate in the next survey. Can I sign up for alerts?** | The best way to receive news about the Global Developer Survey is to sign up for our bi-weekly newsletter – you can do that below or visit our [Subscription Center](https://page.gitlab.com/SubscriptionCenter.html). |\n",[722,852,806,1255],{"slug":3889,"featured":6,"template":681},"2018-global-developer-report","content:en-us:blog:2018-global-developer-report.yml","2018 Global Developer Report","en-us/blog/2018-global-developer-report.yml","en-us/blog/2018-global-developer-report",{"_path":3895,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3896,"content":3902,"config":3907,"_id":3909,"_type":17,"title":3910,"_source":18,"_file":3911,"_stem":3912,"_extension":21},"/en-us/blog/coreos-acquisition",{"title":3897,"description":3898,"ogTitle":3897,"ogDescription":3898,"noIndex":6,"ogImage":3899,"ogUrl":3900,"ogSiteName":667,"ogType":668,"canonicalUrls":3900,"schema":3901},"Red Hat follows GitLab's lead in hybrid cloud technology","Red Hat’s recent acquisition of CoreOS proves that GitLab’s hybrid cloud strategy is worth the investment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680202/Blog/Hero%20Images/coreos.jpg","https://about.gitlab.com/blog/coreos-acquisition","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Red Hat follows GitLab's lead in hybrid cloud technology\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2018-02-27\",\n      }",{"title":3897,"description":3898,"authors":3903,"heroImage":3899,"date":3904,"body":3905,"category":14,"tags":3906},[911],"2018-02-27","\n\nRed Hat's acquisition of CoreOS illustrates the growing importance of adopting a hybrid cloud strategy.\n\n\u003C!-- more -->\n\nIn a market-validating move, [Red Hat acquired CoreOS](https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership), a player in the container technology space, for $250 million. The acquisition comes at a pivotal time in the hybrid cloud market as containers are increasingly becoming a necessity in enabling application portability across multiple clouds. The portability of containers has heightened demand for container management solutions, with organizations actively seeking to find solutions to help them transition their existing applications to the hybrid cloud.\n\nThe acquisition has broad implications on the market and adds validation to [our mission](/company/strategy/) to develop the leading end-to-end software development and operations tool for [cloud native development](/topics/cloud-native/).\n\n## A future-focused strategy\n\nHybrid cloud is the future of technology, and every organization should make its adoption a business imperative. Hybrid cloud gives organizations the flexibility to begin with in-house data centers, scale up with external cloud resources, and adopt or revert to solutions based on changing needs. Hybrid cloud is a customizable strategy that won’t restrict your development and operations and gives you the freedom to leverage existing, low-cost cloud solutions when you need them.\n\nWith the trajectory of software innovation and a customer-driven demand for a simplified solution, cloud native development is the next step in digital transformation. Hybrid cloud technology uses a combination of both physical and multiple cloud platforms, such as Amazon and Azure, increasing the need for a single way to enable faster development velocity while maintaining operational stability.\n\nBecause a hybrid cloud strategy allows developers to quickly adjust development and operations based on need, developers can focus on code improvements and new features, rather than turning their attention to brainstorming ways to scale.\n\n## On cloud nine\n\nContainer technology enables you to simplify deployment of runners, review apps, and your own applications on multiple clouds, including AWS, Azure, and Google, providing you with multiple advantages in development. The ability to switch easily between different clouds gives you the freedom to select options based on price and to make adjustments as costs change over a development lifecycle. If you decide to run an in-house data center and suddenly need to scale beyond your existing hardware, you can quickly leverage the public cloud using the same technology.\n\nContainer schedulers, such as [Kubernetes](/solutions/kubernetes/), provide a common platform from which to automate your management of application containers, from deploying and scaling to operating, so getting started with a hybrid cloud strategy can be a breeze if you have the right solution.\n\n## GitLab has you covered\n\nGitLab is the leader in cloud native development and has pioneered everything you need for end-to-end software development and operations. We have developed a compelling product that covers the entire DevOps lifecycle with a [single application](/direction/#single-application) based on [convention over configuration](/handbook/product/product-principles/#convention-over-configuration). With a [built-in container registry](https://docs.gitlab.com/ee/user/packages/container_registry/index.html), Kubernetes integration, and [CI/CD](/features/continuous-integration/), GitLab is a complete, easy-to-implement solution for your cloud strategy. GitLab is the first end-to-end application to meet the needs of developers at all stages of the development and operations lifecycle.\n\nAs a new generation of software emerges, GitLab has set the standard in providing you with the tools to build, test, deploy, and run your app at scale. A hybrid cloud strategy is no longer a unique way to gain a competitive advantage. It’s the only way to ensure visibility, security, and stability across multiple environments.\n\n[Cover image](https://pixabay.com/en/business-cargo-containers-crate-1845350/) licensed\nunder [CC X](https://pixabay.com/en/service/terms/#usage)\n{: .note}\n",[745,676],{"slug":3908,"featured":6,"template":681},"coreos-acquisition","content:en-us:blog:coreos-acquisition.yml","Coreos Acquisition","en-us/blog/coreos-acquisition.yml","en-us/blog/coreos-acquisition",{"_path":3914,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3915,"content":3921,"config":3927,"_id":3929,"_type":17,"title":3930,"_source":18,"_file":3931,"_stem":3932,"_extension":21},"/en-us/blog/whats-wrong-with-devops",{"title":3916,"description":3917,"ogTitle":3916,"ogDescription":3917,"noIndex":6,"ogImage":3918,"ogUrl":3919,"ogSiteName":667,"ogType":668,"canonicalUrls":3919,"schema":3920},"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":3916,"description":3917,"authors":3922,"heroImage":3918,"date":3924,"body":3925,"category":14,"tags":3926},[3923],"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",[806,1255,974],{"slug":3928,"featured":6,"template":681},"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":3934,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3935,"content":3941,"config":3946,"_id":3948,"_type":17,"title":3949,"_source":18,"_file":3950,"_stem":3951,"_extension":21},"/en-us/blog/craftsman-looks-at-continuous-integration",{"title":3936,"description":3937,"ogTitle":3936,"ogDescription":3937,"noIndex":6,"ogImage":3938,"ogUrl":3939,"ogSiteName":667,"ogType":668,"canonicalUrls":3939,"schema":3940},"A Craftsman looks at continuous integration","Guest author Steve Ropa shares his ideal continuous integration processes for catching errors early and shipping the best software possible.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663786/Blog/Hero%20Images/craftsman-looks-at-continuous-integration.jpg","https://about.gitlab.com/blog/craftsman-looks-at-continuous-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A Craftsman looks at continuous integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steve Ropa\"}],\n        \"datePublished\": \"2018-01-17\",\n      }",{"title":3936,"description":3937,"authors":3942,"heroImage":3938,"date":3943,"body":3944,"category":14,"tags":3945},[3810],"2018-01-17","\nIf your version of continuous integration is just daily builds, ignoring failed tests, or not testing at all, you're doing it wrong.\n\n\u003C!-- more -->\n\n(I’d like to start with a thank you to Jimmy Buffett, as I listen to “A pirate looks at forty” while I write this post…)\n\nI visit a lot of different development teams, and at some point the subject of continuous integration comes up. Shortly after that comes the conversation around [continuous integration tools](/solutions/continuous-integration/). That usually gets kind of religious, but it is absolutely worth talking about. The conversation tends to follow a similar track. Usually it is something to the effect of “Well, we have a [CI server](https://about.gitlab.com/topics/ci-cd/continuous-integration-server/), and we use it for our daily builds, but that’s about it. Then when I ask what else they want to get from their CI tools, I usually get either a blank stare or a long story about what would be awesome if they:\n\n- Had more time.\n- Had someone whose entire job was to manage the continuous integration environment.\n- Were at a different company.\n\nSo this got me thinking, as a [Craftsman](http://manifesto.softwarecraftsmanship.org/), how do I feel about this, and how do I feel about continuous integration in the first place? I came up with a few thoughts.\n\n## Daily builds are NOT continuous integration\n\nIt is often said in Extreme Programming circles that Daily Builds are for Wimps. I don’t know if I’d go that far, but I will say that daily builds are nowhere near frequent enough. One of the primary values we gain from CI is the ability to have very short feedback loops. If I only find out once a day whether or not the work I did fits with the rest of the code base, then I am adding at least eight hours of latency to my system. In most cases, more than that, since “daily builds” are actually nightly builds, leaving us open to walking in each morning to an ugly mess. And don’t even get me started on weekends!\n\nIt’s much easier to find and fix a small changeset, say a few lines and a couple tests, than to have to go back through an entire day’s work to find the error or errors. And this problem is compounded if you have a larger team, or worse, a couple of teams using the same code base.  Now you have many levers to pull and dials to turn before you can find what really broke.\n\nOr yet worse, you will have committed a day’s worth of work and then found out the next day that someone else committed something that completely nullified your work.\n\n## A continuous integration process is more than just the build\n\nI actually am surprised that in this day and age there are teams that believe their job is done if the code compiles, without running any tests. Every continuous integration tool out there provides for automated unit testing at a minimum, usually far more than just that. A good CI process includes continuous Unit Test, and ideally continuous Acceptance Test as well.\n\nI know, you are thinking “Here we go again, another push for test-driven development and automated acceptance tests.” You’re right. Any true Craftsman uses all the tools and modern techniques available to them. That means unit tests that run every time you check in. And automated acceptance tests that run after that. A good CI process includes all of the appropriate elements.\n\nIt’s not enough to just push to your GitLab repo and have the server run a build. The days of “If it compiles it ships” are long gone. And that’s a good thing. We have a responsibility to be better than that, and modern tools and techniques make that possible. I would much prefer a CI process that includes:\n\n- Kickoff on every check-in. This is especially easy with modern repos like GitLab that provide hooks and integrations with all of the major Continuous Integration tools.\n- Build *all* of the code and libraries.\n- Run *all* of the unit and acceptance tests.\n- Report on any errors, preferably failing the build if they occur.\n\nWe can talk about going further into continuous delivery and deployment later, but those can be managed in the same way.\n\n## Listen to your continuous integration server\n\nThe proper response to a notification from your CI environment that the build or one of the tests failed is not to find the offending test and #ignore it. A failed build notification means “Everybody stop! The build is failing so our environment is technologically unsafe until this gets fixed!” Take that message seriously. Everybody stop. Find out what went wrong, and fix it. And only then do you continue with business as usual.\n\nIf we as Craftsmen see our job as to create the best software possible for our customers, we need to take these things seriously. We can either have a “CI Server” that does daily or even less frequent builds, and check the box, or we can be serious about what we do. We have a lot of tools available, and if we choose the best tools we need to use them to their fullest extent.  That is how we become truly great at our Craft.\n\n## About the guest author\n\nSteve Ropa is a Co-founder and Master Craftsman at the Rocky Mountain Programmers Guild in Denver Colorado, where he brings his long career of successful software delivery to bring developers and teams to new levels of performance and Craftsmanship.\n\nCover image by [chuttersnap](https://unsplash.com/photos/tUSN3PNeX1U?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/coil?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1193],{"slug":3947,"featured":6,"template":681},"craftsman-looks-at-continuous-integration","content:en-us:blog:craftsman-looks-at-continuous-integration.yml","Craftsman Looks At Continuous Integration","en-us/blog/craftsman-looks-at-continuous-integration.yml","en-us/blog/craftsman-looks-at-continuous-integration",{"_path":3953,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3954,"content":3960,"config":3965,"_id":3967,"_type":17,"title":3968,"_source":18,"_file":3969,"_stem":3970,"_extension":21},"/en-us/blog/automate-to-accelerate-webcast-recap",{"title":3955,"description":3956,"ogTitle":3955,"ogDescription":3956,"noIndex":6,"ogImage":3957,"ogUrl":3958,"ogSiteName":667,"ogType":668,"canonicalUrls":3958,"schema":3959},"Automate to accelerate: What you need to know about test and release automation","If you’re not using automated testing, your competitors almost certainly are – catch up on our recent webcast to get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671288/Blog/Hero%20Images/gitlab-live-event.png","https://about.gitlab.com/blog/automate-to-accelerate-webcast-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automate to accelerate: What you need to know about test and release automation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-12-08\",\n      }",{"title":3955,"description":3956,"authors":3961,"heroImage":3957,"date":3962,"body":3963,"category":14,"tags":3964},[3265],"2017-12-08","\n\nBuild better software, faster, with test and release automation. Check out our recent webcast to discover why it's critical to your software development process.\n\n\u003C!-- more -->\n\nIt's been six years since Marc Andreessen's landmark \"[software is eating the world](https://www.wsj.com/articles/SB10001424053111903480904576512250915629460)\" claim, and we know now that he was on the money. Whether or not you consider yourself to be in the business of software, you are. Virtually all products and services today contain digital elements, and some component of your user experience will absolutely be online.\n\nWe've moved beyond software for manufacturing, to where 61 percent of financial services jobs are expected to be replaced by software in the 2030s. Every sort of job has the potential to be consumed by software — robo-advisors, truck drivers, grocery stockers, cashiers, and the list goes on.\n\nConsider [this statement made earlier this year by the Nvidia CEO](https://www.technologyreview.com/s/607831/nvidia-ceo-software-is-eating-the-world-but-ai-is-going-to-eat-software/): “Software is eating the world, but AI is eating software” – this puts a new software development issue in play just to stay competitive. The power of AI, when harnessed correctly, will change the landscape entirely yet again. Your key to effective AI may just well be adaptive Continuous Integration functionality.\n\nTo keep up, your release cycle needs to be efficient – we’re talking about when and how you distribute updates to your product. Enter release management.\n\nIn this webcast GitLab Senior Solutions Architect [Joel Krooswyk](/company/team/#JoelKroos) talks about:\n\n- Release management and how it's changing\n- Why automation is critical to test and release processes\n- Challenges of adopting test and release automation and how to overcome them\n- Unified continuous integration and continuous delivery\n\nAnd he demonstrates how to get started with test automation in no time at all with [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/).\n\n## Watch the recording\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/dvayJWwzfPY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Grab the slides\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://docs.google.com/presentation/d/e/2PACX-1vTIAQe2m4mheFhuanNFJzqlY4TdVY3f2wR1wg7L1jVdYF5tL3D1ewo0a5DzUotdAZp5X16ypME200Ev/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",[806,935,1193,2254],{"slug":3966,"featured":6,"template":681},"automate-to-accelerate-webcast-recap","content:en-us:blog:automate-to-accelerate-webcast-recap.yml","Automate To Accelerate Webcast Recap","en-us/blog/automate-to-accelerate-webcast-recap.yml","en-us/blog/automate-to-accelerate-webcast-recap",{"_path":3972,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3973,"content":3979,"config":3984,"_id":3986,"_type":17,"title":3987,"_source":18,"_file":3988,"_stem":3989,"_extension":21},"/en-us/blog/2018-global-developer-survey",{"title":3974,"description":3975,"ogTitle":3974,"ogDescription":3975,"noIndex":6,"ogImage":3976,"ogUrl":3977,"ogSiteName":667,"ogType":668,"canonicalUrls":3977,"schema":3978},"2018 Global Developer Survey aims to uncover developer needs and preferences at work","Take the 2018 Global Developer Survey and be entered to win a Nintendo Switch and GitLab swag.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668107/Blog/Hero%20Images/global-developer-survey.png","https://about.gitlab.com/blog/2018-global-developer-survey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2018 Global Developer Survey aims to uncover developer needs and preferences at work\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2017-11-17\",\n      }",{"title":3974,"description":3975,"authors":3980,"heroImage":3976,"date":3981,"body":3982,"category":14,"tags":3983},[3451],"2017-11-17","\n\nWhat do you need to do your best work? From\noverall developer satisfaction at work and with management, to the use of open\nsource tools and preferred workflow and collaboration methods, we want to\nuncover the needs and preferences of the modern developer.\n\n\u003C!-- more -->\n\nAs an [open core company](/blog/gitlab-is-open-core-github-is-closed-source/), we\nvalue the input, contributions, and needs of our community. Our intention in\nrunning this survey and openly sharing the results is to improve the daily work\nlives of the global development community. We want to empower developers and\ntheir managers with the information they need to work better, together. It's\nour hope that the results of this survey can act as an advocate for the needs of developers,\nreduce the perception gap between management and developers, and shed light on\nwhat high-functioning organizations are doing differently.\n\n## How the survey works\n\nIt takes about 15 minutes to complete and includes approximately 25\nrequired questions and a handful of optional, short answer questions for elaboration.\nThe survey is anonymous, and data and results will be reviewed in aggregate. Topics\nrange from overall developer satisfaction, open source technology, workflows and\ncollaboration, adoption of CI/CD practices, to developer tooling preferences.\n\nWe're committed to putting out a quality and insightful report that is useful\nto the developer community at large. To ensure this, we tested the survey with\nour internal GitLab engineering team to gather feedback and suggestions to make it better.\n\nIt’s open to anyone involved in the software development lifecycle – from\ndevelopers and engineers to DevOps managers and IT executives, we want to hear from you!\n\n## Swag and Nintendo Switch giveaway\n\nAs thanks for participating, we’re giving away five exclusive GitLab robes and one Nintendo Switch! We'll give away a robe per week until they're all gone, using the email addresses from respondents that week. Completing the survey and sharing on social can enter you to win one Nintendo Switch during the final week! Just send a link to your post to [giveaways@gitlab.com](mailto:giveaways@gitlab.com). We can't wait to share the results!\n\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fab fa-gitlab\" style=\"font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \n[Take the survey](https://goo.gl/UsfASr)\n  \u003Ci class=\"fab fa-gitlab\" style=\"font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\n*You must complete the survey and provide an email address to be eligible to\nwin. Your privacy is important to us; email addresses will only be used for the\ndraw and will not be saved.* [Read official sweepstake rules here.](/community/sweepstakes/)\n{: .note}\n",[722],{"slug":3985,"featured":6,"template":681},"2018-global-developer-survey","content:en-us:blog:2018-global-developer-survey.yml","2018 Global Developer Survey","en-us/blog/2018-global-developer-survey.yml","en-us/blog/2018-global-developer-survey",{"_path":3991,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3992,"content":3997,"config":4004,"_id":4006,"_type":17,"title":4007,"_source":18,"_file":4008,"_stem":4009,"_extension":21},"/en-us/blog/devops-at-nova-scotia-province",{"title":3993,"description":3994,"ogTitle":3993,"ogDescription":3994,"noIndex":6,"ogImage":3844,"ogUrl":3995,"ogSiteName":667,"ogType":668,"canonicalUrls":3995,"schema":3996},"How we introduced DevOps at the province of Nova Scotia","The Linux Ops team and one of the Development teams at the Government of Nova Scotia introduced DevOps practices to their workflow – find out how they did it and what benefits they're now enjoying.","https://about.gitlab.com/blog/devops-at-nova-scotia-province","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we introduced DevOps at the province of Nova Scotia\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steven Zinck\"},{\"@type\":\"Person\",\"name\":\"Paul Badcock\"}],\n        \"datePublished\": \"2017-08-14\",\n      }",{"title":3993,"description":3994,"authors":3998,"heroImage":3844,"date":4001,"body":4002,"category":14,"tags":4003},[3999,4000],"Steven Zinck","Paul Badcock","2017-08-14","\n\nDevOps is the practice of breaking down silos between Development and Operations teams. DevOps promotes a culture and practices where Dev and Ops teams have open communication and collaboration. This article explains how the Linux Ops team and one of the Development teams at the Government of Nova Scotia were able to implement DevOps practices and realize its benefits.\n\n\u003C!-- more -->\n\n## The beginning\n\nThe Linux Ops team was asked to host a Ruby application built circa 2006. We’re a Red Hat Enterprise Linux shop, provisioning the newest release of RHEL 7 and the Ruby app required gems that are only compatible with RHEL 6 and older. So, we had two options - provision a new RHEL 6 VM - something we haven’t done in over a year, or take this opportunity to containerize the application and use it as a proof of concept. Although we’ve been using containers for over two years in our [Puppet CI](https://medium.com/@szinck/how-we-use-gitlab-at-the-province-of-nova-scotia-708b514cc47f) environment, and have containerized some of our own management apps, this was our first client application to containerize.\n\nYou can also learn more about our DevOps transformation by watching our recent interview:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/SHdeqznJXbc\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Ops digs into the application\n\nSince the Ruby code for the application was already in our GitLab, we had easy access to it so we could begin to understand its functionality. How does authentication work? How does SSL work? Where are assets stored? Exactly which gems are required? Does the system send email, and if so, how?\nAs we started to peek into the application, we found the answers to all of these things and a lot more. We were able to make a couple improvements to the application, for example, we were able to remove hard-coded values and switch to variables. In particular, we were able to expose database connection strings which can be leveraged by Docker Swarm.\n\n## The Docker image\n\nNow that we had a better understanding of how the application works, we started working on the container to host the application. We started with a base image of RHEL 6.9 and began layering on the dependencies and the application itself. Since the Development team is naturally very knowledgeable about their application, we collaborated closely with them on this process.\n\n## Automatically building and deploying\n\nOnce we had an image we were happy with, it was time to configure [Docker Swarm](https://docs.docker.com/engine/swarm/) and configure GitLab CI to push the image to our Docker registry.\n\nI’ve included the relevant piece of our CI configuration below. As you can see, we’re tagging the Docker image with the last commit # and pushing it to our internal registry.\n\n```build_image:\n  image: docker:1.12\n  stage: build\n  script:\n    - docker build -t\n    ${DOCKER_REGISTRY}/${NAMESPACE}/${CI_PROJECT_NAME}:${CI_COMMIT_SHA}\n    - docker push  \n    ${DOCKER_REGISTRY}/${NAMESPACE}/${CI_PROJECT_NAME}:${CI_COMMIT_SHA}\n```\n\nNow that the image is up on our registry, we can tell Docker Swarm that a new image is available. Swarm will automatically pull down the new image and reload the application with less than five seconds of downtime.\n\n```\nDOCKER_HOST=\"${DOCKER_DEV_HOST}\" docker service update --image  \n${DOCKER_REGISTRY}/${NAMESPACE}/${CI_PROJECT_NAME}:${CI_COMMIT_SHA}  \n${CI_PROJECT_NAME}_app_1\n```\n\n## Automating security scanning (DevSecOps!)\n\nIn addition to building the image, we also run a battery of security tests against the application code, the operating system, and application in its running state.\n\n![pipeline](https://about.gitlab.com/images/blogimages/devops-nova-scotia-screengrab.png){: .shadow}\u003Cbr>\n\nAs you can see from the pipeline, after the image is built, we run a static code analysis using [Brakeman](http://brakemanscanner.org/). Brakeman tests the code for security issues, and since it’s a code analysis tool, the application doesn’t need to be running. After the code scan, we run [Red Hat’s atomic scanner](https://developers.redhat.com/blog/introducing-atomic-scan-container-vulnerability-detection/) against the image. This tool will notify us of any known security issues in the operating system. Finally, we can deploy the application and then run [Arachni](http://www.arachni-scanner.com/) to test the application in its running state.\n\n## Benefits of DevOps\n\nWe’ve discovered several benefits from this approach:\n\n- The Ops and Dev teams worked closely together, each learning about the other's domain expertise. As Ops discovered issues with the application, we were able to make code changes that were peer-reviewed by the Dev team using the [Git Flow](https://datasift.github.io/gitflow/IntroducingGitFlow.html) development model.\n- The time to delivery for the application has improved drastically, and a framework has been established that existing, new and third-party staff can all leverage.\n- Lower failure ratec - if a new vulnerability is introduced into the stack, we’ll know.\n- Fixes can be applied on demand by Dev without Ops involvement.\n- Recovery of the application is now as simple as two clicks.\n- Dev and Ops both understand how the application functions and have a blueprint of its architecture in the Docker configuration.\n\n## Next steps\n\nWe’re actively collaborating with other Development teams across government to implement DevOps-style practices. From a technology perspective, we’re aggressively working towards improving our technology stack so that we can improve business value for our customers.\n\nThis post originally appeared on [*Medium*](https://medium.com/@szinck/devops-at-the-province-of-nova-scotia-42688759a25d).\n\n### About the Guest Authors\n\n[Steve Zinck](https://www.linkedin.com/in/stevezinck/) spent most of his career working in the Public Service as a Unix and Infrastructure administrator. Over the past few years, he's started to transition away from traditional systems administration and begun to focus on software delivery and automation. As part of that transition, his team has implemented GitLab at the core of our automation and software delivery stack. His current focus is working with software and application teams to assist in streamlining their deployment and delivery process.\n\n[Paul Badcock](https://www.linkedin.com/in/pbadcock/?ppe=1) started working in the IT sector in 1998 with positions in small startups, to large Fortune 500 companies, to currently on a public-sector team. His career was focused as a traditional IT Linux administrator until in the mid-2000s he started focusing on adopting development tooling, practices and methodologies for operational teams. This work culminated in implementing an early 2010s DevOps workplace framework with the help of @stewbawka and subsequently working with like-minded teams since. As a part of adopting developer tools he has previously worked with and managed CVS, SVN installations and various vendor products before reading a “Show HN” posting on Hacker News about GitLab.\n",[806,1255],{"slug":4005,"featured":6,"template":681},"devops-at-nova-scotia-province","content:en-us:blog:devops-at-nova-scotia-province.yml","Devops At Nova Scotia Province","en-us/blog/devops-at-nova-scotia-province.yml","en-us/blog/devops-at-nova-scotia-province",{"_path":4011,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4012,"content":4018,"config":4023,"_id":4025,"_type":17,"title":4026,"_source":18,"_file":4027,"_stem":4028,"_extension":21},"/en-us/blog/whats-next-for-gitlab-ci",{"title":4013,"description":4014,"ogTitle":4013,"ogDescription":4014,"noIndex":6,"ogImage":4015,"ogUrl":4016,"ogSiteName":667,"ogType":668,"canonicalUrls":4016,"schema":4017},"From 2/3 of the self-managed Git market, to the next-generation CI system, to Auto DevOps","GitLab first became the standard for self hosting git with two-thirds of the market, then became the next generation CI system, and the next step is creating Auto DevOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679783/Blog/Hero%20Images/whats-next-for-gitlab-ci.jpg","https://about.gitlab.com/blog/whats-next-for-gitlab-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"From 2/3 of the self-managed Git market, to the next-generation CI system, to Auto DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2017-06-29\",\n      }",{"title":4013,"description":4014,"authors":4019,"heroImage":4015,"date":4020,"body":4021,"category":14,"tags":4022},[911],"2017-06-29","\n\nGitLab has transformed from offering just version control to becoming the first integrated product for DevOps. With GitLab you can go all the way from chatting about an idea to measuring it in production without spending time on configuring a bunch of tools. The version control part of GitLab is now used by 2/3 of the market that self host Git. The continuous integration (CI) part of GitLab is now the most popular next generation CI system. Today we introduce the future direction of GitLab: Auto DevOps.\n\n\u003C!-- more -->\n\nWhen we [announced our master plan in September of 2016](/blog/gitlab-master-plan/), we gave our vision for a tool that changes the way developers create software. Before the end of 2016 we [completed the master plan](/releases/2016/12/22/gitlab-8-15-released/) and introduced Auto Deploy. Auto Deploy evolved and sparked a vision for a more integrated DevOps experience. Today we have a video to present that vision of Auto DevOps.\n\n## GitLab has 2/3 market share in the self-managed Git market\n\nWith more than 100,000 organizations self-hosting GitLab, we have the largest share of companies who choose to host their own code. We’re estimated to have two-thirds of the single tenant market. When [Bitrise surveyed](http://blog.bitrise.io/2017/01/27/state-of-app-development-in-2016.html#self-hosted) ten thousand developers who build apps regularly on their platform, they found that 67 percent of self-managed apps prefer GitLab’s on-premise solution.\n\n![Image via Bitrise blog](https://about.gitlab.com/images/blogimages/bitrise-self-hosted-chart.png){: .shadow}\u003Cbr>\n\nSimilarly, in their survey of roughly one thousand development teams, [BuddyBuild found](https://www.buddybuild.com/blog/source-code-hosting#selfhosted) that 79% of mobile developers who host their own code have chosen GitLab:\n\n![Image via buddybuild blog](https://about.gitlab.com/images/blogimages/buddybuild-self-hosted-chart.png){: .shadow}\u003Cbr>\n\nIn their articles, both Bitrise and BuddyBuild note that few organizations use self-managed instances. We think there is a selection effect since both of them are SaaS-only offerings. Based on our experience, in large organizations (over 750 people), it is still more common to self host your Git server (frequently on a cloud service like AWS or GCP) than to use a SaaS service.\n\n## GitLab CI is the most popular next-generation CI system\n\nOur commitment to seamless integration extends to CI. Integrated [CI/CD](/topics/ci-cd/) is both more time and resource efficient than a set of distinct tools, and allows developers greater control over their build pipeline, so they can spot issues early and address them at a relatively low cost. Tighter integration between different stages of the development process makes it easier to cross-reference code, tests, and deployments while discussing them, allowing you to see the full context and iterate much more rapidly. We've heard from customers like [Ticketmaster](/blog/continuous-integration-ticketmaster/) that adopting GitLab CI can transform the entire software development lifecycle (SDLC), in their case helping the Ticketmaster mobile development team deliver on the longstanding goal of weekly releases. As more and more companies look to embrace CI as part of their development methodology, having CI fully integrated into their overall SDLC solution will ensure these companies are able to realize the full potential of CI. You can read more about the benefits of integrated CI in our white paper, [Scaling Continuous Integration](http://get.gitlab.com/scaled-ci-cd/).\n\nIn his post on [building Heroku CI](https://blog.heroku.com/building-tools-for-developers-heroku-ci), Heroku’s Ike DeLorenzo noted that GitLab CI is “clearly the biggest mover in activity on Stack Overflow,” with more popularity than both Travis CI and CircleCI:\n\n![Image via Heroku blog](https://about.gitlab.com/images/blogimages/heroku-questions-chart.png){: .shadow}\u003Cbr>\n\nWhile the use of Jenkins for CI is still higher than any other solution, we see more and more organizations moving from Jenkins, because upgrading their Jenkins server is a brittle process. The last two big things that GitLab CI lacked were scheduled builds (contributed to [GitLab 9.2](/releases/2017/05/22/gitlab-9-2-released/)) and cross-project builds (released in [GitLab 9.3 on June 22](/releases/2017/06/22/gitlab-9-3-released/)).\n\n## Auto DevOps is next\n\nWe want to [deliver more of idea to production](https://gitlab.com/gitlab-org/gitlab-ce/issues/32639) and continue to make the flow even better. [Our direction](/direction/#ci--cd) is to fully automate DevOps with the concept of [Auto DevOps](https://gitlab.com/gitlab-org/gitlab-ee/issues/2517). In a cloud-native world, developers have many projects, and it doesn't make sense to have to set up their tools for every one of them. With help from the wider community we'll ensure that everything works out of the box, from code quality metrics to Review Apps, and from metrics to autoscaling.\n\nWatch our Head of Product Mark Pundsack demonstrate our Auto DevOps vision, including Auto Create, Auto Build, Auto CI, Auto Deploy, Auto Code Quality, and Auto Review Apps:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/KGrJguM361c?rel=0\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\nWe couldn't have built GitLab into the tool and company it is today without the contributions of the wider community, and the feedback from our customers. We're excited to see what you build with GitLab.\n\nHave thoughts about Auto DevOps? Comment on this blog post or on [the issue for Auto DevOps](https://gitlab.com/gitlab-org/gitlab-ee/issues/2517). Interested in what your team can do with GitLab Enterprise Edition? [Sign up for a free trial](/free-trial/) and let us know what you think.\n",[973,806,745,110],{"slug":4024,"featured":6,"template":681},"whats-next-for-gitlab-ci","content:en-us:blog:whats-next-for-gitlab-ci.yml","Whats Next For Gitlab Ci","en-us/blog/whats-next-for-gitlab-ci.yml","en-us/blog/whats-next-for-gitlab-ci",{"_path":4030,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4031,"content":4037,"config":4042,"_id":4044,"_type":17,"title":4045,"_source":18,"_file":4046,"_stem":4047,"_extension":21},"/en-us/blog/biggest-obstacles-to-getting-work-done",{"title":4032,"description":4033,"ogTitle":4032,"ogDescription":4033,"noIndex":6,"ogImage":4034,"ogUrl":4035,"ogSiteName":667,"ogType":668,"canonicalUrls":4035,"schema":4036},"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":4032,"description":4033,"authors":4038,"heroImage":4034,"date":4039,"body":4040,"category":14,"tags":4041},[3265],"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",[2254,1255,974],{"slug":4043,"featured":6,"template":681},"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":4049,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4050,"content":4056,"config":4062,"_id":4064,"_type":17,"title":4065,"_source":18,"_file":4066,"_stem":4067,"_extension":21},"/en-us/blog/pick-your-brain-interview-brandon-foo",{"title":4051,"description":4052,"ogTitle":4051,"ogDescription":4052,"noIndex":6,"ogImage":4053,"ogUrl":4054,"ogSiteName":667,"ogType":668,"canonicalUrls":4054,"schema":4055},"Pick Your Brain interview with CEO Sid Sijbrandij","Brandon Foo, co-founder and CEO of Polymail (YC S16), recently sat down with GitLab CEO Sid Sijbrandij.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680453/Blog/Hero%20Images/pick-your-brain-interview.jpg","https://about.gitlab.com/blog/pick-your-brain-interview-brandon-foo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pick Your Brain interview with CEO Sid Sijbrandij\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brandon Foo\"}],\n        \"datePublished\": \"2017-06-02\",\n      }",{"title":4051,"description":4052,"authors":4057,"heroImage":4053,"date":4059,"body":4060,"category":14,"tags":4061},[4058],"Brandon Foo","2017-06-02","\n\nI sat down for a “[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)” meeting with GitLab’s CEO and Co-founder, [Sid Sijbrandij](/company/team/#sytses), to learn about his approach towards different aspects of building a successful startup. Here are some highlights of the conversation.\n\n\u003C!-- more -->\n\n**Brandon: When you were an earlier company around your seed stage, what were your most effective growth strategies?**\n\n**Sid:** GitLab got started as a [Show HN of GitLab.com](https://news.ycombinator.com/item?id=4428278). We’ve always tried to see where our users were and talk with them there.\n\nWhen you find people who have a need for your product, you start by trying to bring it to their attention. Then you enter a phase where they care about your product, and they start asking you for more — that’s easy, that’s the honeymoon phase. Now we’re getting to the phase where people think of GitLab as a given, and that it should be perfect, so they tell you the things that could be better.\n\n**Brandon: How do you think about product strategy with respect to building new features versus improving or increasing adoption of existing features?**\n\n**Sid:** It’s kind of a pendulum that swings back and forth. We focused a lot on new features for a while to accomplish our [idea to production vision](https://www.youtube.com/watch?v=PoBaY_rqeKA), and now this quarter [we’re focusing](/direction/) on increasing adoption of existing features. Mostly this is necessary for newer features, but that’s not the same as increasing the features’ scope, it’s more a question of how we can increase adoption for the features we already have, and seeing which functions are missing. When we release features and have the suspicion few people are using them, we evaluate to make sure those features are things that people can really use. Most recently in [9.2](/releases/2017/05/22/gitlab-9-2-released/) we added the framework to translate GitLab into any language, and allowed users to specify multiple assignees to better track shared ownership of an issue. [In 2017](/direction/#2017-goals), we’ll continue to ship features tailored for enterprise development teams, and make it easier to build, deploy, and monitor applications within GitLab.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/WBf_DA0FF9k\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n**Brandon: How do you balance building visionary features that people aren’t necessarily asking for vs. building in direct response to customer requests?**\n\n**Sid:** We do both. We started off doing just version control and code review, and now GitLab delivers the entire DevOps pipeline, everything from chatting about an idea and planning it, to getting it out in production and monitoring. We envision enabling everyone to collaborate on digital content, so they can work together and achieve better results. No one asked for that — it’s something we did, it’s the future of the company now. We’d have been in a bad spot if we hadn’t done that.\n\nAt the same time, don’t lose track of what your customers are asking for. Balancing that is the hard part. The natural result is too little visionary stuff; if you build the right company, then everyone will be listening to your customers and screaming, “Let’s build the things customers want!” So the leadership’s task is focusing on what we need to do in order to be a better company in five years.\n\n**Brandon: Since you bootstrapped for some time, how did you decide when it was the right time to raise institutional funding?**\n\n**Sid:** One big reason is the talent we wanted to attract. While we were in YC, we tried to hire a good sales leader, but everyone we approached wanted stock in the company. We hadn’t raised any outside money so stock was all mine and my co-founder [Dmitriy’s](/company/team/#dzaporozhets) — he started GitLab and I started GitLab.com.\n\nThis made clear that if we were unable to give out stock, we were not going to hire the best people; if we’re not getting the best people, we’re going to lose in the marketplace. If you give people stock while not taking outside money, you’ll still grow but very slowly, which is not the kind of deal these executives were expecting. They expect that after 6-7 years the stock is worth something and they can get liquid. The only way to get there is to attract external capital.\n\n**Brandon: Is there anything that you would change in retrospect that you think might improve the outcome of where GitLab is today?**\n\n**Sid:** In hindsight, I’d rather have started GitLab.com a bit later. We’ve grown so fast since then that we’ve been behind in making a great experience for our users.\n\nI would focus on people running GitLab self-managed, and start GitLab.com when we were ready for it. I’d rather have people not use our product than using the product and not being absolutely happy about it. It’s not about users, it’s about happy users.\n\nIf not 100% of the users are happy, we’re not doing a good enough job.\n\n## About the Guest Author\n\nBrandon Foo is the Co-founder and CEO of [Polymail](https://polymail.io/), an email productivity platform designed for modern teams and companies.\n",[723,2926,676],{"slug":4063,"featured":6,"template":681},"pick-your-brain-interview-brandon-foo","content:en-us:blog:pick-your-brain-interview-brandon-foo.yml","Pick Your Brain Interview Brandon Foo","en-us/blog/pick-your-brain-interview-brandon-foo.yml","en-us/blog/pick-your-brain-interview-brandon-foo",{"_path":4069,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4070,"content":4076,"config":4080,"_id":4082,"_type":17,"title":4083,"_source":18,"_file":4084,"_stem":4085,"_extension":21},"/en-us/blog/learning-curve-is-the-biggest-challenge-developers-face-with-git",{"title":4071,"description":4072,"ogTitle":4071,"ogDescription":4072,"noIndex":6,"ogImage":4073,"ogUrl":4074,"ogSiteName":667,"ogType":668,"canonicalUrls":4074,"schema":4075},"Why Git is worth the learning curve","Although the learning curve can pose a challenge, teams have a real incentive to transition to Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684078/Blog/Hero%20Images/why-git-is-worth-the-learning-curve.jpg","https://about.gitlab.com/blog/learning-curve-is-the-biggest-challenge-developers-face-with-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why Git is worth the learning curve\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-05-17\",\n      }",{"title":4071,"description":4072,"authors":4077,"heroImage":4073,"date":4078,"body":4079,"category":14},[1868],"2017-05-17","\nOver the last decade, distributed version control systems, like Git, have gained popularity and are [regarded as the most important development tools](https://page.gitlab.com/rs/194-VVC-221/images/gitlab-enterprise-survey-2016-report.pdf) by\ndevelopers. Although the learning curve can pose a challenge, developers told us that Git enhances their ability to work together and ship faster, suggesting that managers have a real incentive to help their teams over the initial hill imposed by the transition to Git.\n\n\u003C!-- more -->\n\nWith the full history of the repository stored on each developer’s machine, using Git makes commits, merges and other commands much faster, even enabling developers to work offline. Upgrading your source code management solution to a distributed version control system is the first step toward building a flexible working environment that can support modern development teams, but moving away from legacy systems and tools can be a daunting prospect.\n\n### The challenge\n\nIn our [Global Developer Survey](https://page.gitlab.com/rs/194-VVC-221/images/gitlab-enterprise-survey-2016-report.pdf), the biggest concern respondents cite about using Git is the associated learning curve, with 40 percent saying they consider it an issue:\n\n![learning curve is the biggest challenge devs face with Git](https://about.gitlab.com/images/blogimages/why-git-is-worth-the-learning-curve.png){: .shadow}\u003Cbr>\n\nThere are several reasons why this could be the case. Broadly, Git has a different underlying model than other VCS, one that makes it more intuitive for [computer scientists and mathematicians](http://eagain.net/articles/git-for-computer-scientists/), but potentially less so for those with other backgrounds. Unlike with some programming languages where knowledge of one eases the adoption of another, Git commands are different from those in other version control systems, making familiarity with another system only a minor advantage. Finally, the number of Git commands and arguments that make it a particularly powerful tool also complicate the beginner’s task of learning the ropes. For teams transitioning to Git, this not only means migrating repositories, but relearning ingrained habits and workflows, and it may sting a bit.\n\n### The rewards\n\n#### Greater collaboration and code quality\n\nNearly 80 percent of respondents [confirmed](https://page.gitlab.com/rs/194-VVC-221/images/gitlab-enterprise-survey-2016-report.pdf) that they see increased collaboration with teammates as a major benefit of the Git workflow, which nudges teams to update each other early and often, enabling them to collect feedback regularly and integrate suggestions throughout the process. The accessibility of Git repositories makes it easier for contributors and specialists across your organization to collaborate, making it more likely that errors are spotted, resulting in better and more stable code. Feature branches, or branches containing one feature or bug fix, allow teams to discuss and perfect their code at the merge request stage, before changes are accepted into master. Before merging, a developer can commit their code locally to ensure it works, preserving the quality of the master code base.\n\n#### “Cheaper” branching\n\nThe branching capabilities within Git are largely responsible for its popularity. Developers can create a new branch and isolated environment to work on new features, bug fixes, customer requests, or experiment on something new with minimal cost. Branching with Git is “cheap” in that it's easy to do and doesn’t take up a lot of space. Creating a new branch requires but a single command and no network connection, unlike Subversion and other centralized version control systems, where branching is a slow and repetitive process resulting in a complete copy of all code.\n\n#### Easier merging\n\nWhen coupled with a source code management tool like GitLab, you can enhance merging capabilities with a user interface that allows you to review and comment on changes on branches before merging. At GitLab, we call this a merge request and run [continuous integration](/features/continuous-integration/) on every branch as an additional quality gate to ensure everything that goes into the master code base works. With GitLab branching and merging, you can even protect branches to prevent merges that aren’t ready, and apply merge request approvals for an added layer of security.\n\nMore good news: just a few commands are required to get started, and the open source community around the world ensures there’s always someone awake to answer your question.\n\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Read our   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>Global Developer Survey Report\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Ca style=\"color: rgb(107,79,187);\" href=\"https://page.gitlab.com/rs/194-VVC-221/images/gitlab-enterprise-survey-2016-report.pdf\">Check it out it here\u003C/a>!\u003C/p>\n",{"slug":4081,"featured":6,"template":681},"learning-curve-is-the-biggest-challenge-developers-face-with-git","content:en-us:blog:learning-curve-is-the-biggest-challenge-developers-face-with-git.yml","Learning Curve Is The Biggest Challenge Developers Face With Git","en-us/blog/learning-curve-is-the-biggest-challenge-developers-face-with-git.yml","en-us/blog/learning-curve-is-the-biggest-challenge-developers-face-with-git",{"_path":4087,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4088,"content":4094,"config":4098,"_id":4100,"_type":17,"title":4101,"_source":18,"_file":4102,"_stem":4103,"_extension":21},"/en-us/blog/what-to-look-for-in-ci-cd-solution",{"title":4089,"description":4090,"ogTitle":4089,"ogDescription":4090,"noIndex":6,"ogImage":4091,"ogUrl":4092,"ogSiteName":667,"ogType":668,"canonicalUrls":4092,"schema":4093},"What to look for in a continuous integration tool","With so many options out there, here's what you need to weigh up when deciding on a CI/CD tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671489/Blog/Hero%20Images/what-to-look-for-ci-cd.jpg","https://about.gitlab.com/blog/what-to-look-for-in-ci-cd-solution","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What to look for in a continuous integration tool\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-05-08\",\n      }",{"title":4089,"description":4090,"authors":4095,"heroImage":4091,"date":4096,"body":4097,"category":14},[3265],"2017-05-08","\n\nThe advantages of continuous integration and delivery for catching errors while they're still easy to fix and speeding up your time to market are [well documented](/blog/ways-ci-cd-helps/), but even if you're sold on CI/CD, it can be tricky to take the next step. How do you choose the solution that's right for your team?\n\n\u003C!-- more -->\n\nThe factors to consider when choosing a [CI/CD tool](/topics/ci-cd/) are similar to those of [choosing a Git management solution](/blog/choosing-git-management-solution/): hosted vs. on-premise, open source vs. commercial, and integrations. You'll also want to look at how easily the tool allows your team to visualize the release process and nip potential issues in the bud.\n\n## Hosting\n\nWhether you prefer SaaS or to host yourself, you have options. Integrations with third-party services are sometimes easier with a cloud-based service, but some organizations prefer the peace of mind that comes with everything being housed within their walls. Ultimately you need to weigh up what resources you have at your disposal for hosting, and how you want to use them.\n\n## Open source vs. commercial\n\nUsing an open source solution has its advantages: it's free, and you can look under the hood and make alterations if needed. Make sure you do your research before committing though: do you need priority access to support? How will you manage if the vendor decides to abandon the product? Are there any features specific to a product that would make things easier for your team? Ask these questions first.\n\n## Support for integrations\n\nIt's fairly common for an organization's software development lifecycle to rely on several integrated tools (such as [issue boards](/stages-devops-lifecycle/issueboard/) and other discussion features). Find out what your teams are already using and if the CI/CD solution you're considering is supported. There's been growing interest in built-in CI/CD, which means developers can spend less time stringing together their tooling and more on new features and improvements. Bringing all your tools under one product with one interface and datastore is also useful for things like [cycle analytics](/product/cycle-analytics/), which can help to reduce the time between coming up with an idea and deploying it.\n\n## Visualizing the release process\n\nOne of the advantages of leveraging CI/CD is being able to see changes and new additions from the moment they're created. Does your chosen solution offer [Review Apps](/stages-devops-lifecycle/review-apps/), so you can automatically check out a live preview of new code? You might also benefit from [Deploy Boards](/releases/2017/03/22/gitlab-9-0-released/#deploy-boards-eep), where you can watch a deploy roll out across pods and monitor the health and deployment status of each environment, all in one place. This makes it easier to spot problems and stop or roll back with one click.  These are just a couple of features that can make a significant difference to your team's efficiency.\n\n## So how does GitLab CI/CD stack up?\n\nWe offer **self-managed** options for both\n[GitLab Enterprise Edition and Community Edition](/stages-devops-lifecycle/)\nand a **hosted** option for GitLab Enterprise Edition Premium on [GitLab.com](/).\n\nWe have a **free and open source** offering, GitLab Community Edition, and two **enterprise** offerings,\nEnterprise Edition Starter and Enterprise Edition Premium, with advanced features such as [GitLab Geo](/solutions/geo/), High Availability via our [Reference Architectures)](https://docs.gitlab.com/ee/administration/reference_architectures/) and [Disaster Recovery](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/), [File Locking](https://docs.gitlab.com/ee/user/project/file_lock.html) and [Service Desk](https://docs.gitlab.com/ee/user/project/service_desk.html).\n\nYou can **visualize your release process** in all versions of GitLab with GitLab [CI/CD Pipelines](https://docs.gitlab.com/ee/ci/pipelines/index.html), [Review Apps](/stages-devops-lifecycle/review-apps/) and [Prometheus monitoring](https://docs.gitlab.com/ee/administration/monitoring/prometheus/).\nGitLab Enterprise Premium comes with [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html) and\n[Canary Deployments](/releases/2017/04/22/gitlab-9-1-released/#canary-deployments-eep) for even more advanced control over deployments.\n\nVisit our [Product page](/stages-devops-lifecycle/) and [DevOps tools page](/competition/) to see how GitLab measures against other tools.\n\nTo learn more about CI/CD and how it can help you release earlier and more often, watch our webcast, \"[From Continuous Integration to Continuous Everything](https://page.gitlab.com/20170301_continuouseverything.html)\" on demand.\n{: .alert .alert-gitlab-orange}  \n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/PavW0JeY_Qc\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\n\n“spiral” by Vadim Timoshkin is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)\n{: .note}\n",{"slug":4099,"featured":6,"template":681},"what-to-look-for-in-ci-cd-solution","content:en-us:blog:what-to-look-for-in-ci-cd-solution.yml","What To Look For In Ci Cd Solution","en-us/blog/what-to-look-for-in-ci-cd-solution.yml","en-us/blog/what-to-look-for-in-ci-cd-solution",{"_path":4105,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4106,"content":4112,"config":4116,"_id":4118,"_type":17,"title":4119,"_source":18,"_file":4120,"_stem":4121,"_extension":21},"/en-us/blog/why-code-is-released-too-early",{"title":4107,"description":4108,"ogTitle":4107,"ogDescription":4108,"noIndex":6,"ogImage":4109,"ogUrl":4110,"ogSiteName":667,"ogType":668,"canonicalUrls":4110,"schema":4111},"Why code gets released too early (and how to fix it)","More than half of developers say they release code prematurely. What can you do about it?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671476/Blog/Hero%20Images/code-released-too-early.jpg","https://about.gitlab.com/blog/why-code-is-released-too-early","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why code gets released too early (and how to fix it)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-04-27\",\n      }",{"title":4107,"description":4108,"authors":4113,"heroImage":4109,"date":4114,"body":4115,"category":14},[3265],"2017-04-27","\n\nCode released before it’s ready might be good for meeting deadlines, but that’s about all it’s good for. Most software products today are in a continual state of development, testing and release, so making sure you’re only shipping code that’s truly ready is both challenging and critical.\n\n\u003C!-- more -->\n\nOur 2016  [Global Developer Survey](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) asked respondents about how they work, what they work with and what makes their jobs easier (or harder!). They told us resoundingly that between deadline pressure and unrealistic expectations from management, they end up releasing broken or non-functional code all too often.\n\n## Over half of developers admit to releasing code before it’s ready\n\nThe frequency of shipping incomplete code varies, but an overwhelming 81 percent of developers admitted to releasing code before it’s ready, with an alarming 15.75 percent saying it happens more than half of the time.\n\nThis isn’t the same as releasing early and often, although the two are easily confused. It’s common practice to release features that are not necessarily polished, with the aim of gathering feedback and improving with the next iteration. However, releasing code that isn’t ready refers to code that is incomplete, not yet fully functional, or hasn’t been tested across all environments. The pitfalls here are obvious: shipping code that’s not finished can break things and result in frustrated customers.\n\n## Why does this happen?\n\nIt seems obvious that releasing too early should be avoided, yet it happens all too often. Why? Pressure from senior management and deadlines that must be hit were the top two answers from our respondents, with 38.34 and 58.9 percent each, suggesting a breakdown in communication and mismanaged expectations between senior management and development teams.\n\n## How to prevent premature releases\n\nHaving a robust release management strategy is essential for planning and controlling your software delivery schedule. Leveraging [Continuous Integration and Continuous Delivery](/blog/ways-ci-cd-helps/) to ensure your code is always tested and ready to be deployed at a moment’s notice helps to prevent the release of broken code. [Adopting DevOps practices to improve communication and collaboration](/blog/introduce-continuous-workflows/) between teams and encourage shared responsibility for each release is another way to ensure that deadlines are realistic and can be met.\n\nAlso, it might sound counterintuitive, but releasing more often can actually help to prevent premature releases: if you’re shipping once a month instead of twice a year, there’s no reason to rush code that isn’t ready into your upcoming release just to meet a deadline.\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",{"slug":4117,"featured":6,"template":681},"why-code-is-released-too-early","content:en-us:blog:why-code-is-released-too-early.yml","Why Code Is Released Too Early","en-us/blog/why-code-is-released-too-early.yml","en-us/blog/why-code-is-released-too-early",{"_path":4123,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4124,"content":4130,"config":4134,"_id":4136,"_type":17,"title":4137,"_source":18,"_file":4138,"_stem":4139,"_extension":21},"/en-us/blog/choosing-git-management-solution",{"title":4125,"description":4126,"ogTitle":4125,"ogDescription":4126,"noIndex":6,"ogImage":4127,"ogUrl":4128,"ogSiteName":667,"ogType":668,"canonicalUrls":4128,"schema":4129},"What to look for in a Git management solution","You've decided to make the move to Git. Now what?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671466/Blog/Hero%20Images/how-to-choose-a-git-management-system.jpg","https://about.gitlab.com/blog/choosing-git-management-solution","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What to look for in a Git management solution\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-04-20\",\n      }",{"title":4125,"description":4126,"authors":4131,"heroImage":4127,"date":4132,"body":4133,"category":14},[3265],"2017-04-20","\n\nThere's good reason why Git is the most popular distributed version control system today. If you're still not sure it's the right choice for your business, [listen to our recent panel discussion about the pros and cons of Git ](https://www.youtube.com/watch?v=iVUqKJpHc5s&feature=youtu.be) to get the lowdown. If we've convinced you already, that's great news! The next step is choosing a Git management solution that's right for your team.\n\n\u003C!-- more -->\n\n## Why you need a Git management solution\n\nGit by itself does not have a graphical user interface – it's entirely based on the command line. This might be a familiar and comfortable environment for developers, but can be a barrier to entry for other team members. Fortunately, thanks to the open source community, there are a number of Git management solutions built on top of Git that can improve the user experience, by offering a user interface.\n\nThis not only helps team members to visualize, manage, and browse projects and repositories easily, but also makes reviewing code changes simpler. Managing access and permissions is also easier and more secure.\n\nA Git management solution can also offer [enterprise-ready features](/pricing/) that are designed to simplify and secure the software development lifecycle for larger organizations, such as time tracking, file locking, and merge or pull request approvals. Another advantage is the ability to integrate with modern technology and processes to make the most of other tools and container schedulers such as Kubernetes.\n\n## What to consider when choosing a Git management solution\n\n### Hosted vs on-premise\n\nOn-premise – installing and customizing software on your own machines in your own data center – gives you the advantage of full control over company systems and the security of knowing everything is housed within the walls of your own business. Not relying on a hosted service means you aren't affected by their downtime. However, this places the burden of managing and maintaining in-house servers on your organization, and you'll need a dedicated IT team that's up to the job. Decide which [hosting solution](/stages-devops-lifecycle/) is best for your organization before settling on a Git management solution.\n\n### Integration with other tools\n\nSource code management is just one element of the software development lifecycle. Your teams will most likely want other features such as [issue tracking](/stages-devops-lifecycle/issueboard/), [CI/CD](/features/continuous-integration/), [code review](https://www.youtube.com/watch?v=XluG9mAQdSo&feature=youtu.be) and [collaboration tools](/blog/why-collaboration-tools-matter/). When choosing a Git management solution it's important to know what other tools or features your teams require, and whether the solution you're considering includes or supports those.\n\n### Cost\n\nWhat is your budget and how do you want to spend it? Opting for an open source solution rather than a commercial one can seem like a shortcut to savings, and many organizations [choose open source](/blog/why-choose-open-source/) for this very reason. It's also critical though to consider whether the features that are included and support offered are sufficient for your needs, and will scale as your organization grows. When you've taken all of this into account you'll be in a good position to make the right choice.\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Listen to our   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>Why You Should Move to Git\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n  panel discussion \u003Ca style=\"color: rgb(107,79,187);\" href=\"https://www.youtube.com/watch?v=iVUqKJpHc5s&feature=youtu.be\"> here\u003C/a>!\u003C/p>\n{: .alert .alert-gitlab-orange}\n\n[Photo](https://unsplash.com/photos/IZGNcO_8CDg) by [Letizia Bordoni](https://unsplash.com/@letyi) on Unsplash\n{: .note}\n",{"slug":4135,"featured":6,"template":681},"choosing-git-management-solution","content:en-us:blog:choosing-git-management-solution.yml","Choosing Git Management Solution","en-us/blog/choosing-git-management-solution.yml","en-us/blog/choosing-git-management-solution",{"_path":4141,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4142,"content":4148,"config":4152,"_id":4154,"_type":17,"title":4155,"_source":18,"_file":4156,"_stem":4157,"_extension":21},"/en-us/blog/how-innersourcing-can-help-your-security-team",{"title":4143,"description":4144,"ogTitle":4143,"ogDescription":4144,"noIndex":6,"ogImage":4145,"ogUrl":4146,"ogSiteName":667,"ogType":668,"canonicalUrls":4146,"schema":4147},"How innersourcing can help your security team","Security is a major concern during the development process — innersourcing can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676117/Blog/Hero%20Images/data.png","https://about.gitlab.com/blog/how-innersourcing-can-help-your-security-team","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How innersourcing can help your security team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-04-19\",\n      }",{"title":4143,"description":4144,"authors":4149,"heroImage":4145,"date":4150,"body":4151,"category":14},[1868],"2017-04-19","\nIn today’s world of developer-defined tooling and accelerated delivery pace, security and compliance are becoming more difficult. With increased threats from advanced hackers, and security breaches rapidly turning into PR storms, your security team is under more pressure than ever before.\n\n\u003C!-- more -->\n\nIn our [2016 Global Developer Survey](http://get.gitlab.com/global-developer-survey/), 86 percent of respondents told us security is important or extremely important to them when developing code — code cannot be good without being deployed within a solid security architecture. In this context, innersourcing, or [the use of open source development techniques](https://web.archive.org/web/20201001042918/http://www.inner-sourcing.com/open-source-and-opengl-a-response-from-tim-oreilly/) within the corporation, is a useful way for some enterprise teams to reap the benefits of open source principles while keeping their code private to non-employees.\n\nEnterprise teams have a lot to gain from open source methods. Some of the most [important of these](/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/) include making all software projects visible by default to all employees, and allowing anyone who can see the code to fork it and make changes freely. New ideas can also arise by allowing people outside the project to suggest changes with pull and merge requests, and having a line-by-line conversation about the code. Using unit and integration tests lets developers make changes without fear of breaking things. Similarly, incorporating continuous integration ensures that every change is automatically tested. These principles can help the entire team collaborate, but they have some specific applications for the security team.\n\n### Break down silos\n\nWhile in the past a developer might have [relied on word of mouth](/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/) to learn about other projects in their organization, and had to track someone down to give them access if they wanted to contribute, innersourcing removes the barrier to entry. By reusing code from their colleagues on the security team, developers can be more efficient while also ensuring greater consistency in their code.\n\nBy allowing developers to work on projects outside of their department without having to ask for permission, innersourcing ensures that a security specialist can be easily looped into a project for review and feedback. This can also help improve the relationship between security and development teams. Together with security automation, security team members provide an additional feedback loop during the application development process, rather than refining security at the end.\n\n### Spot (and fix) security issues\n\nInnersourcing pairs the benefits of open source workflows, like greater collaboration and improved code quality, with greater assurance that code is secure: 39 percent of our survey respondents said innersourcing has helped them uncover security issues they hadn't seen before.\n\nFor example, using our own code review workflow, we [discovered a vulnerability in 9.0](/releases/2017/03/29/gitlab-9-dot-0-dot-2-released/) that could allow a user to rename upload directories for projects that they did not own, effectively breaking all links to those uploads. After its discovery, this was fixed in a subsequent security release, which we release as soon as we find vulnerabilities.\n\n### Enable knowledge sharing and innovation\n\nBy making software projects visible within the company, and including thorough documentation, security team members can share the constraints and common problems they run into when reviewing developers' code. At GitLab, for both internal and external knowledge sharing, we publish blog posts for every security release, explaining the fixes included in each release, and giving credit to the person who reported the vulnerabilities. In addition, once a security issue is discovered in one project, a developer can quickly search all projects for similar bugs.\n\nHelping development teams understand recurring security issues makes it more likely that they'll not only avoid making the same mistakes in the future, but that their combined skills might allow them to innovate around the security constraints.\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Read our   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>Global Developer Survey Report\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Ca style=\"color: rgb(107,79,187);\" href=\"http://get.gitlab.com/global-developer-survey/\">Download it here\u003C/a>!\u003C/p>\n",{"slug":4153,"featured":6,"template":681},"how-innersourcing-can-help-your-security-team","content:en-us:blog:how-innersourcing-can-help-your-security-team.yml","How Innersourcing Can Help Your Security Team","en-us/blog/how-innersourcing-can-help-your-security-team.yml","en-us/blog/how-innersourcing-can-help-your-security-team",{"_path":4159,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4160,"content":4166,"config":4170,"_id":4172,"_type":17,"title":4173,"_source":18,"_file":4174,"_stem":4175,"_extension":21},"/en-us/blog/ways-ci-cd-helps",{"title":4161,"description":4162,"ogTitle":4161,"ogDescription":4162,"noIndex":6,"ogImage":4163,"ogUrl":4164,"ogSiteName":667,"ogType":668,"canonicalUrls":4164,"schema":4165},"3 Ways CI/CD helps your team","CI/CD frees up your team to spend their time on developing features customers want.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671461/Blog/Hero%20Images/ways-ci-cd-helps.jpg","https://about.gitlab.com/blog/ways-ci-cd-helps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 Ways CI/CD helps your team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-04-12\",\n      }",{"title":4161,"description":4162,"authors":4167,"heroImage":4163,"date":4168,"body":4169,"category":14},[3265],"2017-04-12","\n\n[Continuous integration](/features/continuous-integration/) and delivery are at the core of modern software development, enabling businesses to ship new, working features earlier and more often. CI is also becoming an [integral part of everyday work](/blog/ci-integral-to-everyday-work/) for developers, saving them time and reducing frustrations.\n\n\u003C!-- more -->\n\n## CI/CD saves time\n\nOne of the [major advantages of CI](/topics/ci-cd/benefits-continuous-integration/) is that it automates manual processes that are often a tedious and time-consuming part of a developer’s job. There’s less manual debugging to contend with, and they no longer have to worry about building their changes with a variety of different operating systems or other environments. The CI system can take care of all that, and leverage its ability to integrate with tools like Docker and Kubernetes to take full advantage of the power of the cloud without having to run on a development machine. Best of all, as this work is automated, it frees up team members to move onto other tasks while the build and tests complete.\n\n## CI/CD saves money\n\nWith a CI tool, you can also take advantage of the fact that it has significantly more flexibility and power available. For example, it can run tests across multiple operating systems, multiple browsers, and in general do more work than is practical on a developer’s machine. This allows the team to find issues more quickly and earlier in the cycle, where it is cheap, instead of backtracking later. If you have to wait until late in the development to find out a change fails on a specific operating system or browser, that can become expensive and could jeopardize the release. By leveraging CI you become proactive rather than reactive, ultimately saving money.\n\n## CI/CD minimizes downtime\n\nBy integrating changes frequently and ensuring new code is ready to be shipped at any time, significant downtime while you deploy updates becomes a thing of the past. This is not only less stressful for developers and managers, but results in less frustration for your users due to downtime while deployment completes.\n\nTo learn more about CI/CD and how it can help you release earlier and more often, watch our webcast, \"[From Continuous Integration to Continuous Everything](https://page.gitlab.com/20170301_continuouseverything.html)\" on demand.\n{: .alert .alert-gitlab-orange}\n\n“[Spiral](https://www.flickr.com/photos/xmex/32568053662/)” by [XoMEox](https://www.flickr.com/photos/xmex/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)\n{: .note}\n",{"slug":4171,"featured":6,"template":681},"ways-ci-cd-helps","content:en-us:blog:ways-ci-cd-helps.yml","Ways Ci Cd Helps","en-us/blog/ways-ci-cd-helps.yml","en-us/blog/ways-ci-cd-helps",{"_path":4177,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4178,"content":4184,"config":4188,"_id":4190,"_type":17,"title":4191,"_source":18,"_file":4192,"_stem":4193,"_extension":21},"/en-us/blog/why-collaboration-tools-matter",{"title":4179,"description":4180,"ogTitle":4179,"ogDescription":4180,"noIndex":6,"ogImage":4181,"ogUrl":4182,"ogSiteName":667,"ogType":668,"canonicalUrls":4182,"schema":4183},"Why collaboration tools matter more than ever","Nearly two-thirds of developers say that chat and collaboration tools are integral to their everyday work. Here’s why.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671447/Blog/Hero%20Images/collaboration-tools-matter.jpg","https://about.gitlab.com/blog/why-collaboration-tools-matter","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why collaboration tools matter more than ever\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-04-04\",\n      }",{"title":4179,"description":4180,"authors":4185,"heroImage":4181,"date":4186,"body":4187,"category":14},[3265],"2017-04-04","\n\nTools that foster collaboration and information sharing throughout the software development process are becoming ever more important as enterprises move towards a DevOps culture. With a majority of developers considering chat and collaboration tools to be essential to their jobs, teams that rely on meetings in person may get left behind.\n\n\u003C!-- more -->\n\nOur [Global Developer Report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) explores how developers’ methods are changing, and how businesses can adapt to get the best out of their development teams. More than half of our respondents identified as developer or engineer, giving us insight into what matters to developers, how they work and what tools they choose. To see what our research revealed, you can [download the full report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) to learn more about what today’s developers want.\n\n## Why collaboration matters\n\nMore and more enterprises are adopting DevOps to streamline their software development lifecycle. DevOps practices emphasise integration and collaboration between teams and sharing responsibility for the outcome, which means working together and keeping each other in the loop throughout the entire software development lifecycle. This change in approach necessitates a change in communication style as well.\n\nBy updating each other early and often, you can collect feedback regularly and integrate suggestions throughout the process. Including your non-technical team members in the conversation means they can get to work on promoting your next release or gathering feedback from customers, supporting your software development teams.\n\n![How important collaboration tools are](https://about.gitlab.com/images/blogimages/collaboration-tools-matter-graph.png){: .shadow}\u003Cbr>\n\n## Why collaboration tools are important\n\nAs the build/ship/learn cycle speeds up, the team will naturally be working together throughout more of the cycle because they can and need to stay involved… and this benefits everyone. Enterprise teams need tools that can mirror their new cross-functional way of working, acknowledging that while the new enterprise team is distributed, they are more collaborative than ever before.\n\nTo keep everyone in the loop, especially with distributed, asynchronous teams, tools and features that enable closer collaboration within and across teams are essential. With 66 percent of developers preferring to be contacted via email or IM instead of in person, chat and other integrated collaboration tools help to keep the lines of communication open and ensure everyone has a clear view of where a project is at. The outcome is a more streamlined software development process, and a faster time to market with a better product.\n\nDownload our [Global Developer Report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) to learn more about which tools are favored by developers today.\n{: .alert .alert-gitlab-orange}\n\nImage: “[Message board](https://www.flickr.com/photos/mujitra/10511181393/)” by [MIKI Yoshihito](https://www.flickr.com/photos/mujitra/) is licensed under [CC BY  2.0](https://creativecommons.org/licenses/by/2.0/)\n{: .note}\n",{"slug":4189,"featured":6,"template":681},"why-collaboration-tools-matter","content:en-us:blog:why-collaboration-tools-matter.yml","Why Collaboration Tools Matter","en-us/blog/why-collaboration-tools-matter.yml","en-us/blog/why-collaboration-tools-matter",{"_path":4195,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4196,"content":4202,"config":4206,"_id":4208,"_type":17,"title":4209,"_source":18,"_file":4210,"_stem":4211,"_extension":21},"/en-us/blog/review-apps-continuous-case-study",{"title":4197,"description":4198,"ogTitle":4197,"ogDescription":4198,"noIndex":6,"ogImage":4199,"ogUrl":4200,"ogSiteName":667,"ogType":668,"canonicalUrls":4200,"schema":4201},"Complete, but never finished/:/ Review Apps","Find out how we used a continuous approach to release Review Apps early and improve on it in small iterations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671443/Blog/Hero%20Images/review_apps_cover.png","https://about.gitlab.com/blog/review-apps-continuous-case-study","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Complete, but never finished/:/ Review Apps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-03-21\",\n      }",{"title":4197,"description":4198,"authors":4203,"heroImage":4199,"date":4204,"body":4205,"category":14},[3265],"2017-03-21","\n\nContinuous methods go beyond integration, delivery and deployment. Releasing early and often, and keeping all team members in the loop throughout the development lifecycle, helps everyone in an organization to work more efficiently and deliver customer value consistently. Here at GitLab, we strive to make being continuous part of our lives. One example of this is our Review Apps feature.\n\n\u003C!-- more -->\n\n## What are Review Apps?\n\n[Review Apps](/stages-devops-lifecycle/review-apps/) are ephemeral app environments that are created dynamically every time you push a new branch up to GitLab, and they're automatically deleted when the branch is deleted. What this means in practice is that rather than having a single dev environment for a project, or even separate dev apps for each developer, you get a new app for every topic branch, automatically. This lets you test and demo new features easily: product managers can check out exactly what a merge request is going to look like without having to download and run a topic branch, while QA and other users can take a look without having a development environment installed on their laptop at all.\n\n## How we released Review Apps\n\nWe really wanted to add the Review Apps feature, because having a live environment for every feature a team is working on is just so transformative. We spent months debating the best way to go about doing this, until we arrived at what we thought was the best method. Now, we had all of these great ideas to magically make it work, automatically detect your environment, and more. But if we tried to do all those things, it would be months before we shipped for people to use and get feedback (even ourselves!).\n\nWe knew we had to cut the scope until we could develop and ship the essence of this feature in a single release. Ultimately we came up with a way to add two simple options to our CI platform: to set the Name and URL of an environment. We shipped just that small set of changes in [8.12](/releases/2016/09/22/gitlab-8-12-released/), and it enabled users to start leveraging review environments right away.\n\n## Continuous improvement on Review Apps\n\nIn [the next release](/releases/2016/10/22/gitlab-8-13-released/) we added the ability to stop and delete these apps, because there wasn’t a UI-based method to stop them in the first release! In [the following release](/blog/introducing-review-apps/), we started to get back to some of that magic by being able to automatically stop and delete review environments whenever a branch was merged and removed.\n\nThis approach allowed us to collect really early feedback on the feature, and ensure we were building in the right direction.\n\nTo find out more about how to introduce a continuous mentality throughout your entire organization, [register now](https://page.gitlab.com/20170301_continuouseverything.html) to watch our webcast, **From Continuous Integration to Continuous Everything**, on demand.\n",{"slug":4207,"featured":6,"template":681},"review-apps-continuous-case-study","content:en-us:blog:review-apps-continuous-case-study.yml","Review Apps Continuous Case Study","en-us/blog/review-apps-continuous-case-study.yml","en-us/blog/review-apps-continuous-case-study",{"_path":4213,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4214,"content":4220,"config":4225,"_id":4227,"_type":17,"title":4228,"_source":18,"_file":4229,"_stem":4230,"_extension":21},"/en-us/blog/your-engineers-need-to-understand-your-business-heres-why",{"title":4215,"description":4216,"ogTitle":4215,"ogDescription":4216,"noIndex":6,"ogImage":4217,"ogUrl":4218,"ogSiteName":667,"ogType":668,"canonicalUrls":4218,"schema":4219},"Invite your engineers to talk business. Here's why.","Traditionally, engineers may have been shielded from the \"business parts\" of the organization. In today’s technology landscape, that’s no longer a viable option.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683990/Blog/Hero%20Images/invite-your-engineers-to-talk-business-heres-why.jpg","https://about.gitlab.com/blog/your-engineers-need-to-understand-your-business-heres-why","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Invite your engineers to talk business. Here's why.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n        \"datePublished\": \"2017-03-07\",\n      }",{"title":4215,"description":4216,"authors":4221,"heroImage":4217,"date":4223,"body":4224,"category":14},[4222],"Victor Wu","2017-03-07","\n\nEvery business today is a technology business. Whether it supports your business model or itself _is_ the business model, your technology stack plays a key role. What your engineering team ships, and how they ship, has direct and measurable consequences for your business, even if they traditionally prefer to think otherwise. Engineering goals are now closer than ever to business goals, and understanding that will help companies thrive in the business technology world today.\n\n\u003C!-- more -->\n\nThe idea of [software craftsmanship](https://en.wikipedia.org/wiki/Software_craftsmanship) dictates that the profession of software engineer should be analogous to that of civil engineer. Increased professionalism (in the style of [Uncle Bob](https://en.wikipedia.org/wiki/Robert_Cecil_Martin)) suggests that software engineers' work should carry the same weight, and their failures the same consequences, as physicians and civil engineers.\n\nThese are noble goals for software engineers, especially if you are building software to operate a [bascule (draw) bridge](https://en.wikipedia.org/wiki/Bascule_bridge)! Unfortunately, they are challenged daily by business managers who just want functionality, but may not care about the underlying mess supporting it; they think that engineers who constantly try to clean up that mess are wasting time chasing after esoteric technical standards. Engineers, on the other hand, want to always deliver and maintain quality work, and they are less concerned about the business and the end users. This lack of communication and alignment creates distrust and inefficiencies — it just doesn't work.\n\n## Code quality as a means to further your business\n\nA better approach that more and more organizations — including GitLab — have embraced is lending a greater business voice to your engineering organization, and of course demanding greater responsibility. Have your engineering team communicate the benefits of maintaining quality code, and why the costs of increased engineering resources (people and time, typically) are justified by tangible business outcomes. Along with a clean and adaptable codebase, quality code allows you to:\n\n* Add new features quickly\n* Remove existing features since it's relatively easy to identify which code contributes to those features, and which does not\n* Change existing features, for reasons similar to above\n* Have a more stable platform with fewer defects and security problems, again due to predictability of your code\n* Deploy code quickly, with fewer manual configuration steps, reducing the time from decision to when you go live\n\nNote that all the benefits above are _business benefits_! Your software engineers already know these are possible and goals that they themselves already aspire to achieve.\n\n## Can you ever skimp on code quality?\n\nThe short answer is: it depends on the company. For mature organizations shipping well-established products, it's likely the market cannot absorb shocks or big changes in the product. Performance, security, and privacy are very important, especially for highly regulated industries. Code quality is crucial for these companies, and luckily, they typically have more resources to easily handle the cost of maintaining that quality. Code quality should always be the rule, with very little exceptions, and engineering and business should communicate along those lines.\n\nIn either a small startup or a large organization shipping a product quickly to compete, I'd argue that you can _and should_ skimp on code quality. Engineers may not be a fan when reading this, but this draws on the concept of _technical debt_ or _tech debt_. Sometimes a startup has to strategically incur tech debt to push out a product or feature update more quickly, to get the timing just right.\n\nIf you instead choose to maintain that 100 percent quality code, you lose out on the opportunity, and don't even have a business in 2 months, totally defeating the purpose of your software development in the first place. You'd have gained a beautiful codebase, but lost a viable business. Just as any healthy business regularly pays back old debt and takes on new, you need to clean up previously incurred tech debt so that your codebase doesn't slow down your business.\n\n## Engineering goals are business goals\n\nIn the past, engineers were often removed from business discussions. Business managers established requirements, and threw those over the wall to engineering managers who would reciprocate with delivery timelines. In today's technology-driven business landscape, that's no longer a viable option for success. Both parties need to work closely together in order to survive in a competitive software world.\n\nMaintaining code quality is a great bridge in this effort, since engineers can easily articulate its practical benefits that are readily translated into positive business outcomes. You should continually analyze your business and take advantage of new tech debt as the need arises. There is a lot of technical nuance to this delicate balance, and so your engineering team should be presenting the options and offering a strong recommendation. Your engineers need to be strong _business leaders_.\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Watch our webcast   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>Code Review: A Business Imperative\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   on demand. \u003Ca style=\"color: rgb(107,79,187);\" href=\"https://www.youtube.com/watch?v=XluG9mAQdSo&feature=youtu.be\">Watch here\u003C/a>!\u003C/p>\n\n",{"slug":4226,"featured":6,"template":681},"your-engineers-need-to-understand-your-business-heres-why","content:en-us:blog:your-engineers-need-to-understand-your-business-heres-why.yml","Your Engineers Need To Understand Your Business Heres Why","en-us/blog/your-engineers-need-to-understand-your-business-heres-why.yml","en-us/blog/your-engineers-need-to-understand-your-business-heres-why",{"_path":4232,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4233,"content":4239,"config":4243,"_id":4245,"_type":17,"title":4246,"_source":18,"_file":4247,"_stem":4248,"_extension":21},"/en-us/blog/developers-crave-modern-tools",{"title":4234,"description":4235,"ogTitle":4234,"ogDescription":4235,"noIndex":6,"ogImage":4236,"ogUrl":4237,"ogSiteName":667,"ogType":668,"canonicalUrls":4237,"schema":4238},"The secret to developer happiness? Use better tools","The way developers work has changed, and they’re opting to leave behind outdated tools.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668402/Blog/Hero%20Images/code-gitlab-tanuki.png","https://about.gitlab.com/blog/developers-crave-modern-tools","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The secret to developer happiness? Use better tools\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-02-27\",\n      }",{"title":4234,"description":4235,"authors":4240,"heroImage":4236,"date":4241,"body":4242,"category":14},[1868],"2017-02-27","\n\nGreat software is built by great people—not “magic bullet” tools or technologies. However, [research reveals](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) that the tools you choose for your team may have a greater impact on developer happiness and retention that you thought. In fact, a whopping 81% of developers say that it’s critical organizations use the latest development tools and 36% go as far as to say they would reject a job if the employer didn’t use the latest tools. Why are new tools becoming non-negotiable for developers?\n\n\u003C!-- more -->\n\n## How better tools help software developer and engineer happiness\n\nDevelopers are opinionated and rigorous when it comes building their work environment,  because tools can have a massive impact on their ability to get their work done. Whether they’re losing time waiting for complicated systems to update or struggling to effectively collaborate with their team, developers are becoming more and more frustrated with tools that can’t keep up the pace their job demands.\n\nAs software development continues to trend toward distributed and open systems, process-driven methodologies are dying out in exchange for more asynchronous, collaborative workflows. One result of this setup is the empowerment of individual contributors as influencers in organizations that depend on them to beat their competition to market. Last year, we launched our [Global Developer Survey](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) to examine more closely how software development is adapting from pressures within and without, and how these changes affect the way teams work. Chief among these trends is developers' insistence on using tools that make them the most effective in their jobs; below you will find some of our key findings on how developers are bringing modern tools into the workplace.\n\n## Our respondents are in-the-know\n\nOur sample is developer-heavy, with 53 percent of respondents identifying themselves as an engineer or developer, ensuring that their views are well-represented here.\n\n![What are respondents' roles](https://about.gitlab.com/images/blogimages/role-within-org-graph.png){: .shadow}\u003Cbr>\n\n## Devs drive adoption\n\nOur respondents told us that developers have the upper hand when selecting the tools they work with—when asked who in their organization decides which tools they use, a plurality of 44 percent said they choose their own.\n\nThe next most common response reinforces developer primacy in this area: 17 percent of respondents reported that their lead developer drives tool selection. It’s remarkable, and a clear sign of developers’ rising agency and power within their organizations, that less than 20 percent said that decision is made by their CTO/CIO, IT Director, or Head of Engineering. Tellingly, 11 percent insisted that they use whichever tools they want, even though they’re not officially in charge of the decision.  \n\n![Who decides which tools are used](https://about.gitlab.com/images/blogimages/who-in-org-decides-tools-graph.png){: .shadow}\u003Cbr>\n\n## They insist on the newest and best\n\nDevelopers’ increasing power to choose tooling is matched by the strength of their opinions. Eighty-one percent of respondents told us it’s critical for organizations to use the latest development tools. This insistence on using only the newest and best runs deep, even, in some cases, if it seems counter to their immediate self-interest: 36 percent of developers said they would reject a job if the organization did not use the latest tools. Once they’re satisfied with a tool, they also opt for consistency, with 91 percent of respondents telling us they’d prefer to use the same tools for work and personal projects.  \n\nFor more on how devs work now, download the [full report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html), and look out for the next in this series, where we’ll discuss the popularity of open source tooling.\n\n*[Learn more](/free-trial/) about how GitLab Enterprise Edition can help your team achieve software excellence, and try for yourself!*\n",{"slug":4244,"featured":6,"template":681},"developers-crave-modern-tools","content:en-us:blog:developers-crave-modern-tools.yml","Developers Crave Modern Tools","en-us/blog/developers-crave-modern-tools.yml","en-us/blog/developers-crave-modern-tools",{"_path":4250,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4251,"content":4257,"config":4261,"_id":4263,"_type":17,"title":4264,"_source":18,"_file":4265,"_stem":4266,"_extension":21},"/en-us/blog/ci-integral-to-everyday-work",{"title":4252,"description":4253,"ogTitle":4252,"ogDescription":4253,"noIndex":6,"ogImage":4254,"ogUrl":4255,"ogSiteName":667,"ogType":668,"canonicalUrls":4255,"schema":4256},"Continuous integration: A tool developers expect","77% of developers say Continuous Integration is integral to their everyday work – we break down what that means.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671420/Blog/Hero%20Images/ci-nice-to-have-post.png","https://about.gitlab.com/blog/ci-integral-to-everyday-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Continuous integration: A tool developers expect\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-02-22\",\n      }",{"title":4252,"description":4253,"authors":4258,"heroImage":4254,"date":4259,"body":4260,"category":14},[3265],"2017-02-22","\n\nWhat is continuous integration? Continuous integration is the practice that developers use to detect, locate and fix errors quickly by integrating their code frequently into a shared repository and is becoming a non-negotiable aspect of everyday work.\n\n\u003C!-- more -->\n\n[Continuous integration (CI)](/features/continuous-integration/) automates testing of new code, sparing developers the time-consuming task of checking it manually, and with increasing numbers of companies using this approach every day, CI is essential to staying competitive and to retaining your talent.\n\nOur [Global Developer Report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) was launched last year to explore the ways in which developers work is changing, and how you as a business can adapt to get the best out of your development team. With a developer-heavy sample (more than half of respondents identify as developer or engineer), the survey revealed some truths about what matters to developers, how they choose to work and what tools they choose to do it with. To see what our research revealed, you can [download the full report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) to learn more about what today’s developers want.\n\nOne of the key takeaways from the survey is that continuous integration and continuous integration tools now plays a crucial part in daily work, and is becoming more and more important to delivering great features frequently. CI frees up time that would otherwise be spent on finding and fixing errors, and it decreases the chance of shipping code that isn’t ready.\n\n![How much Continuous Integration is used](https://about.gitlab.com/images/blogimages/ci-tool-developers-expect.png){: .shadow}\u003Cbr>\n\n## CI is used by more than half of developers\n\nDevOps continuous integration is becoming more mainstream. Developers are now using it more than 75 percent of the time. More than 20 percent use it nearly 100 percent of the time, with only 4 percent not using continuous integration at all. The trend is clear: Continuous integration is becoming increasingly important.\n\n## CI makes best use of your team’s time\n\nThere are many benefits of continuous integration. Deploying untested code means time is wasted on backtracking to find and fix bugs. Nearly 54 percent of our respondents work on a developer team of fewer than 10, so any resources spent on tasks that could be automated has a huge impact. Adopting continuous integration means new code is automatically tested for errors, so your developers spend less time on dull, manual testing and can focus on the work that inspires them – like building great new features.\n\n## 77 percent of developers think CI is essential\n\nThey rated continuous integration and continuous integration tools as very or extremely important to their everyday work. If this trend is to continue, CI will soon be an essential element of your software development lifecycle, and companies that are resistant to adopting it may find their development team growing restless: 36 percent of developers said they would turn down a job if the company did not use the latest tools.\n\n## Continuous methods aren’t just for developers\nWe’ve come a long way since a release consisted of distributing CDs to retailers, and it’s not just developers who are changing their methods. The practice of working continuously – releasing in small, manageable iterations often and integrating feedback and changes frequently – is something everyone in a company can adopt, to work more efficiently and collaboratively. Watch our webcast to explore in more detail how the continuous approach can help you deliver customer value at the pace it takes to complete.\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Watch our webcast   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>From Continuous Integration to Continuous Everything\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i> \u003Ca style=\"color: rgb(107,79,187);\" href=\"https://page.gitlab.com/20170301_continuouseverything.html\">Register here\u003C/a>!\u003C/p>\n\n_Tweet us [@GitLab](https://twitter.com/gitlab), check out our [job openings](/jobs/), or add your questions and suggestions to our [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues)!_\n",{"slug":4262,"featured":6,"template":681},"ci-integral-to-everyday-work","content:en-us:blog:ci-integral-to-everyday-work.yml","Ci Integral To Everyday Work","en-us/blog/ci-integral-to-everyday-work.yml","en-us/blog/ci-integral-to-everyday-work",{"_path":4268,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4269,"content":4275,"config":4279,"_id":4281,"_type":17,"title":4282,"_source":18,"_file":4283,"_stem":4284,"_extension":21},"/en-us/blog/gitlab-joins-forces-with-gravitational",{"title":4270,"description":4271,"ogTitle":4270,"ogDescription":4271,"noIndex":6,"ogImage":4272,"ogUrl":4273,"ogSiteName":667,"ogType":668,"canonicalUrls":4273,"schema":4274},"GitLab and Gravitational discuss Kubernetes","Is Kubernetes the way forward? We chatted to Ev Kontsevoy, CEO of Gravitational and unofficial Kubernetes cheerleader, to get the lowdown","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683941/Blog/Hero%20Images/ship-steering-wheel-kubernetes.jpg","https://about.gitlab.com/blog/gitlab-joins-forces-with-gravitational","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab and Gravitational discuss Kubernetes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2016-12-12\",\n      }",{"title":4270,"description":4271,"authors":4276,"heroImage":4272,"date":4277,"body":4278,"category":14},[3265],"2016-12-12","\nYou never know where a conversation on Hacker News might take you. That's what Ev Kontsevoy learned when he left a comment on a post, sparking a conversation with another reader who turned out to be GitLab CEO, Sid Sijbrandij. Later that day, at a party in San Francisco, Ev spotted another party guest wearing a GitLab T-shirt and approached him to chat. \"Turns out it was Sid, again!\" Ev says, laughing. \"It's like he's everywhere.\"\n\n\u003C!-- more -->\n\n\"So we bumped into each other twice in the same day and when we started chatting. Sid mentioned that right now GitLab is trying to figure out the Kubernetes story: how to work with companies that rely heavily on Kubernetes, and frankly also how to use it internally.\" [Gravitational](https://gravitational.com/) is a Kubernetes company, so Ev was quick to offer their services, which is how GitLab ended up collaborating with Gravitational.\n\n## What did we work on together?\n\n\"One area that we were looking at together is how to run PostgreSQL on Kubernetes really well. It’s definitely a problem that most users will be trying to solve and it’s just one of the things that Gravitational is good at: we help our companies migrate their existing applications to Kubernetes, including databases. We've also been working on a GitLab path towards adopting Kubernetes for SaaS internally, after I bumped into some of your team members at a Kubernetes conference in Seattle.\"\n\n## Why Kubernetes?\n\nJacob Vosmaer, GitLab Senior Developer, had some questions for Ev about the partnership: \"What does a tool like Kubernetes make easier for an application like GitLab?\"\n\nEv: \"You mean, 'Why even bother with Kubernetes at all?'\"\n\nJacob: \"I was being polite!\"\n\nEv: \"Server costs are a major line item on every company’s budget. When you are a certain size it can actually become more expensive than your engineering salaries. Developing software that utilizes servers effectively is difficult. This is where Kubernetes comes in. Unlike the old technology like virtualisation, which would statically partition your servers into smaller VMs, Kubernetes allows you to do this partitioning on the fly, which means that if your application needs more or less of particular resources as it runs, Kubernetes will be dynamically growing and shrinking different components of your application across the infrastructure that’s available to you. So that's really the benefit of Kubernetes, you save a lot of money on hosting if you utilize it.\"\n\n## Will Kubernetes become the industry standard?\n\nEv: \"We're probably going to witness something similar to Windows vs Linux, where there will probably be No. 1 and No. 2, and perhaps a very small No. 3. It feels to me that No. 1 and 2 are going to be Kubernetes and DC/OS from Mesosphere, for two reasons: DC/OS is an older product, it’s fairly mature, there are now Fortune 500 companies publicly using it. This kind of success doesn’t appear overnight. Even though technically Mesosphere technology is competing with Kubernetes and with what we do, I wish them the best and I do believe they are going to be noticeable.\"\n\n>\"Kubernetes is an unstoppable force right now\"\n\n\"In my line, Kubernetes is an unstoppable force right now, simply because there are so many companies with a proven track record of popularizing open source who are behind it. Companies like IBM, Red Hat, Google themselves – with so many backers pushing Kubernetes forward, it’s hard for me to imagine it not leading the platform. Look at what happened with Linux: it’s the exact same companies who keep pushing Linux Kernel forward. They're now joining forces again to promote Kubernetes and to evolve and invest money into it.\"\n\n\"Finally, there's container pioneering company Docker, with their own technology called Docker Swarm, so Docker has enormous mind share with developers. Docker Swarm itself is kind of late out of the gate compared to Kubernetes and DC/OS, and I’m very curious to see what’s going to happen. But those are the three players that I think will be carving out this pie, I don’t really see anyone else challenging that.\"\n\nIn addition to their work with GitLab on Kubernetes, Gravitational also helped us [build a Terminal into GitLab](https://gitlab.com/gitlab-org/gitlab-ce/issues/22864), Ev explains, \"to allow developers or any GitLab users to easily jump inside the containers that are running on Kubernetes without leaving the GitLab environment\". Good news for open source! Thanks for working with us, Gravitational.\n\n\nImage: \"[Take the wheel and drive](https://www.flickr.com/photos/rachaelvoorhees/828353700/)\" by [rachaelvoorhees](https://www.flickr.com/photos/rachaelvoorhees/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)\n",{"slug":4280,"featured":6,"template":681},"gitlab-joins-forces-with-gravitational","content:en-us:blog:gitlab-joins-forces-with-gravitational.yml","Gitlab Joins Forces With Gravitational","en-us/blog/gitlab-joins-forces-with-gravitational.yml","en-us/blog/gitlab-joins-forces-with-gravitational",{"_path":4286,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4287,"content":4293,"config":4297,"_id":4299,"_type":17,"title":4300,"_source":18,"_file":4301,"_stem":4302,"_extension":21},"/en-us/blog/global-developer-survey-2016",{"title":4288,"description":4289,"ogTitle":4288,"ogDescription":4289,"noIndex":6,"ogImage":4290,"ogUrl":4291,"ogSiteName":667,"ogType":668,"canonicalUrls":4291,"schema":4292},"Global Developer Survey reveals need for more collaborative workflows","New survey examines how modern developers prefer to work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683917/Blog/Hero%20Images/ee-survey-2016-cover-3.png","https://about.gitlab.com/blog/global-developer-survey-2016","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Global Developer Survey reveals need for more collaborative workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2016-11-02\",\n      }",{"title":4288,"description":4289,"authors":4294,"heroImage":4290,"date":4295,"body":4296,"category":14},[3451],"2016-11-02","\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>  \n**TL;DR:** New survey shows 98% of developers use open source tools at work; 92% prefer Git. [Get the full report][report-lp].\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\nTechnology trends move fast. In the time it takes to build a new program or\nfeature, the very problem you're trying to solve can become obsolete. It's not\njust competitors you're worried about but the rapid pace of advancement in\ntechnology that can pit products within a single company against each other.\nKeep your head down too long on one project, and the rest of the development\nworld has not only moved onto something new, they're using a brand new\nset of tools you've never heard of to build it.\n\n\u003C!-- more -->\n\nRapid acceleration in the technology\nindustry is nothing new. Moore's law predicted this phenomenon as early as 1965\nand over the last 35 years, we've all experienced the overwhelming takeover of\ntechnology, software, and digital devices. What's surprising is there are massive development teams attempting to do revolutionary work at a\nrevolutionary pace, while still using outdated systems and methods of software development.\n\nIn an era where speed and time to market matter most, these technology companies\nare sabotaging their bottom line. In fact, a business analyst at Forrester\nwent so far as to say \"['Evolve or Crumble' is one of the most important things\nyou will read this year.][forrester-blog-odonnell]\"\n\nWhile businesses struggle to keep up with cutting edge systems, processes, and\ntechnologies, developers are demanding the latest development tools and\nmore collaborative ways of working in order to ship code faster. Managers take note:\n\n![infographic](https://about.gitlab.com/images/blogimages/enterprise-survey-2016-infographic.png){: .shadow}\n\nOur survey reveals that the vast majority of developers work with open source tools. A distributed version control system, and more specifically, Git, is the\nmost important tool used in everyday work. Developers have a strong desire to work\nwith the latest tools and methods, yet nearly half say their team doesn't have\na good handle on the latest dev best practices.\n\n## Give Developers What They Want\n\nDevelopers are feeling the pressure to move faster from idea to production.\nUnfortunately, unclear direction and outdated tools and techniques are slowing\ndown the process. Luckily for DevOps and IT managers, there is a strong correlation\nbetween what devs want and what businesses need, but leadership must be willing to\nembrace the changes required to get there.\n\nAt the core of what devs want and what businesses need is a more iterative and\ncollaborative process for software development. Eighty-one percent of developers say that\nchat and collaboration tools (such as Slack, HipChat, etc.) are very or extremely\nimportant to their everyday work. In the brave new world of software development,\nrigid processes are replaced with more natural ways of communicating, which in turn\nimprove the efficiency and speed of a team.\n\n### Conversational Development is the new Agile.\n\nSoftware development methodologies have come a long way over the last few decades:\nScrum replaced the inflexible Waterfall Method, and Agile improved the time-consuming\nmethod of Scrum. Now, as more development teams are distributed globally and the market\ndemands speed and innovation, a more flexible process is needed.\n\nIn our more networked society, communication is instantaneous and constant. With more\nconversations happening in multiple places during the software development lifecycle,\na process that puts conversation at the center is needed.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Agile development should be conversational development \u003Ca href=\"https://twitter.com/hashtag/RubyConfPT?src=hash\">#RubyConfPT\u003C/a> \u003Ca href=\"https://twitter.com/hashtag/martinfowler?src=hash\">#martinfowler\u003C/a> \u003Ca href=\"https://t.co/z7hrommlUA\">pic.twitter.com/z7hrommlUA\u003C/a>\u003C/p>— Luísa Lima (@__luisalima__) \u003Ca href=\"https://twitter.com/__luisalima__/status/791574169876045825\">October 27, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nConversational Development (ConvDev) is a natural process of accelerating the\ndevelopment lifecycle that threads a conversation through every step of the\ndevelopment process. With ConvDev, gatekeepers become a part of the conversation\nand can monitor the entire process - starting with an idea all the way to production. Cycle time\nis reduced by threading all conversations through every stage of the development lifecycle.\n\nAs developers continue to gain control over the tools they use at work, there will be an\neven greater push to choose open source and Git, and to adopt workflows that are\nnaturally collaborative. Teams that can ship quicker, smaller changes are poised\nto dominate the market.\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \n [Get the complete 2016 Enterprise Survey Report here][report-lp].\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\n\u003C!-- identifiers -->\n\n[forrester-blog-odonnell]: https://go.forrester.com/blogs/16-09-13-tech_vendors_must_evolve_or_crumble_the_report_you_must_read/\n[report-lp]: https://page.gitlab.com/2016-Developer-Survey_2016-Developer-Survey.html\n",{"slug":4298,"featured":6,"template":681},"global-developer-survey-2016","content:en-us:blog:global-developer-survey-2016.yml","Global Developer Survey 2016","en-us/blog/global-developer-survey-2016.yml","en-us/blog/global-developer-survey-2016",{"_path":4304,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4305,"content":4311,"config":4315,"_id":4317,"_type":17,"title":4318,"_source":18,"_file":4319,"_stem":4320,"_extension":21},"/en-us/blog/fundraising-tips-ceo",{"title":4306,"description":4307,"ogTitle":4306,"ogDescription":4307,"noIndex":6,"ogImage":4308,"ogUrl":4309,"ogSiteName":667,"ogType":668,"canonicalUrls":4309,"schema":4310},"30 Fundraising Tips from the CEO","30 fundraising tips from GitLab CEO Sid Sijbrandij","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683779/Blog/Hero%20Images/fundraising-tips-ceo.jpg","https://about.gitlab.com/blog/fundraising-tips-ceo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"30 Fundraising Tips from the CEO\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-10-14\",\n      }",{"title":4306,"description":4307,"authors":4312,"heroImage":4308,"date":4313,"body":4314,"category":14},[911],"2016-10-14","\n\n\nHow do you raise money for your startup in a climate where it’s increasingly hard to obtain funding? \nSecuring support from the right investors is not only a vital source of money, but is also an \nopportunity to benefit from their skills, experience, and connections.\n\nThis post outlines the strategies that have worked for us. Of course, every organization is unique, \nso these are the tips that have been most beneficial in our own quest to raise funding at GitLab.\n\n\u003C!-- more --> \n\n## When Is the Best Time to Raise Money?\n\n1. **Eight quarters of run rate is the best time to raise money for your organization.** This gives you sufficient time to spend as long as you need to plan the deck and meet investors without feeling like time is running out. It means that if you are offered a deal you don’t like, you don’t have to accept it. You have the time to step back from fundraising, get back to stockflow neutral, and not be forced to lay off any employees.\n\n1. **Make sure that you have a lot of runway.** This is indicative of how conservative you are financially, so investors will be looking closely at this. You can achieve this by fundraising early. Another strategy is to make sure that your net worth compared to your revenue is low. Don’t make your burn equal to half of your revenue, make it equal to 20% or even 10%.\n\n## Organize Your Time Efficiently\n\n1. **Surround yourself with a great team.** Fundraising requires hours of work from everyone in the group. Make sure you can work effectively with everyone on the team and that you will enjoy spending significant amounts of time together!\n\n1. **Set aside around three or four months for the fundraising process.** When we went through our first round of fundraising at GitLab, we spent one month on the design phase, one month on the road, two weeks wrapping up with the people that had term sheets, and then one month closing. But, this is extremely fast—most organizations take longer to raise funding. The time consuming element for most organizations is meeting with investors. [Some companies can raise funding in just a few weeks, for others it takes months][fundraising-article]. It’s always best to be prepared for the process to take longer than you expect.\n\n1. **As a CEO, you should be prepared to focus solely on fundraising.** There will not be enough time to run the company as well as raise funding. Hire an assistant to prioritize emails and direct your attention towards urgent messages.\n\n1. **Try to minimize the amount of time you spend traveling to investors.** This stage can easily last anywhere between three to six months. At GitLab, we decided to spend only four weeks as we wanted to focus on progressing the company, rather than fundraising. This approach to travel is much better for the team’s quality of life because fundraising is very intense. There are a lot of ups and downs, where you can be ecstatic one day because you are connecting with one investor, and frustrated the next day because you have been turned down by another investor. Confining the traveling stage to a relatively short period of time worked best for us.\n\n## Put Together the Perfect Slidedeck \n\n1. **Make the deck the sole focus of one team member.** Although content is vital, good design is equally important. Spend some time with designers, whether they work for your company, or whether they are employed by an organization like SketchDeck. The right design will help to clarify and strengthen your message.\n\n1. **Spend time working on the pricing chart.** Your pricing chart should be sufficiently detailed and include the relevant information, but the investors have to be able to understand it!\n\n1. **Over the course of fundraising, your deck will evolve.** Although you have spent weeks perfecting it and believe it to be a finished product by the time you go out onto the road, you will find that there’s more to add. As you speak to investors, issues are raised that you may not have addressed in sufficient detail, or questions are asked that you might not have considered. It will be necessary to add more slides as you learn more about investors’ interests, expectations, and concerns.\n\n1. **If you have an unusual business model, discuss it in your slidedeck.** Investors will ask lots of questions about it, so you want to give them as much information as possible, and ensure they see the advantages of your choice. When we were fundraising, some investors were concerned about our decision to be a remote-only company. Mid-way through fundraising, we wrote a presentation to provide them with information on why being a remote-only organization works so well for us.\n\n1. **Don’t include too many slides in the deck.** There is no hard and fast rule, but [between 10 and 20 slides][slide-tips] will enable you to strike a balance between informing the investors and sharing an overwhelming level of detail. The pitch is your chance to tell investors everything they need to know about your organization, your product and customers, financials, and projections. It’s an opportunity to get them excited and allay any fears they may have.\n\n1. **If you get useful feedback, use it.** It doesn’t matter how late in the process you receive it, take the time to incorporate feedback into your fundraising strategy if you feel that it could make a real difference to the funding you secure.\n\n1. **Be prepared for the deck to change from series A to series B.** In series B, there will need to be a lot of data relating to sales figures, as the investors will be very interested in this. You will need to share details of the funnel, and where the sales team is meeting its targets. In general there should be less strategy, as you should have consolidated your place in the market by the time you reach this stage.\n\n## Preparing for Meetings and Follow Ups\n\n1. **Turn on the TV!** If you really want to know what life is like when you’re in the fundraising bubble, watch Silicon Valley! (But when it comes to the show’s portrayal of investors, just remember that it is a TV show and certain aspects may be amplified!)\n\n1. **Check the time.** When you are preparing for meetings and follow-ups, make sure you are always on time.\n\n1. **Dress code is not important.** What matters is what you say during the meetings and follow-ups.\n\n1. **Don’t go hungry!** Eat something before going into a meeting, especially if you know you don’t perform well when you’re hungry!\n\n1. **Have some backup slides for your deck.** We found it useful to create a slide that listed questions we did not yet have an answer for; after the meeting we could find the answer, then follow-up with the investor and add it to the slidedeck for future presentations if we felt it would be helpful. When you’re preparing your slidedeck, there will always be content that you’re not certain will be required, but could still be informative for the investor; these slides should go in the backup set. If and when you need the information, you can switch to that slide easily.\n\n1. **It can be hard to keep the meeting on track.** The investors will start asking questions based on the content in your slidedeck. It is possible to skip ahead to the relevant slide, then go back to resume the presentation, but this can get confusing and you will lose the flow of the presentation. It is best to acknowledge the investor’s question and let them know that this will be dealt with later in the slidedeck.\n\n1. **There should be someone on your team who is not presenting.** Their role is to write down the questions, so you can follow up after the meeting. If possible or relevant, add this information to your presentation.\n\n1. **Keep a list of when you last spoke to each investor.** If they are silent for a few days, then it’s important to follow up to find out why. If they don’t respond to your first message, ask if they are still interested in potentially investing in your organization. There are generally three reasons behind this: \n  - They are not interested \n  - They may have been too busy to reply, but are still interested \n  - They are keeping their options open. Whatever the reason, you need to find out so you know who you should focus your attention on.\n1. **Ask permission from the venture capitalists to record one of your pitches.** There is a lot of mystery surrounding what goes on in a pitch—this is your chance to help others.\n\n## Familiarize Yourself with Financial Terminology\n\n1. **Prorata rights.** Prorata rights can be one of the most contentious aspects of investment, so make sure you understand it. Any lead investor will want a certain percentage of your company. For the A round it’s usually around 20%, for B round it’s 15%, and for C round it’s 10%. They need that much of the company to make it worth their time and effort investing. \n\n   Prorata investment rights allow investors the right to keep their percentage of their share of the company the same when you start the next fundraising round. During the second (or third) fundraising round, all existing shareholders get diluted; these investors can invest more money so they maintain the same percentage. This is what it means when you hear about investors ‘doing their prorata’. Super prorata is what happens if the investors want to increase their ownership percentage in the next round. If you would like to learn more on prorata, [this post][prorata-rights] is helpful.\n\n1. **Super prorata rights are not founder-friendly.** Firstly, what do we mean by ‘founder-friendly’? These are terms that do not give too much leverage to the investors. Instead, the CEO will be given the freedom to make decisions. If an investor asks to use super prorata rights, they want to increase their percentage ownership in the next funding round. This is not founder-friendly because it might make it difficult for you to secure funding from new investors, as there isn’t a significant percentage of the company left for them to invest in.\n\n## How to Find the Right Investor and / or Boardmember\n\n1. **Ask yourself whether a potential investor is the right fit for your board of directors.** If someone is prepared to invest in your organization, that is extremely flattering, but it important to consider whether they believe in your vision and whether they can help you meet the challenges ahead.\n\n1. **It isn’t easy to raise money in an economic climate where less investors are keen to invest.** But, whatever the climate, you will be valued on more than 10 or 20 eighths of your sales - this is to your advantage, as it means that you can give clearly demonstrate your company’s success and potential. Market forces (such as what similar deals are being priced at, the competitors in your sector and how your company is different) will affect the valuation of your company. You can’t change this, but you can control how you present your own organization to investors.\n\n1. **Show investors that you have disrupted the market.** Being the market leader is good, and certainly what you must aspire to be, but as a startup it is not always possible. You want to demonstrate to investors that you are innovative, you have the drive to make your organization the best, that you have a better strategy, and, ultimately, the best product.\n\n1. **The right investor is more important for your company than the valuation.** That’s not to say the valuation of your organization isn’t important, but it’s important that you don’t miss out on the best possible investor who has great connections and a wealth of knowledge, for a relatively small sum of money.\n\n1. **Know what you’re looking for in a board member.** As well as acquiring some funding for your company, another reason for fundraising is to find a great board member. You have to be able to work well with your board member because you will be working together for many years to come. They have to be intelligent, ethical, hardworking, and well connected in the industry. Many times, a board member will be used to close somebody who is considering joining the company. Their strategic outlook and understanding of your industry will give you confidence in their abilities to be a real asset to your organization.\n\n1. **Know the difference between what round A and round B investors are looking for.** Round A investors will be looking at your prototype, traction, and management team. Their terms will be more founder-friendly, as they know that subsequent terms will be increasingly investor-friendly. In the B round of fundraising, investors will be scrutinizing your metrics, sales, and conversion rate will be scrutinized. \n\nA good series B investor will reach out to the existing board members. They will also want to know whether the A round investors will take advantage of their prorata. The terms of investment for the B round will not only have to be acceptable to the company, but also the investors, so make sure your current investors are happy with these.\n\nIf you have any insights on fundraising, share them with the GitLab community. Start the discussion below.\n\n\u003C!-- identifiers --> \n\n[fundraising-article]: http://a16z.com/2015/02/27/16-common-questions-about-fundraising/\n[slide-tips]: http://slidebean.com/blog/startups/pitch-deck-presentation-complete-guide/\n[prorate-rights]: https://bothsidesofthetable.com/what-all-entrepreneurs-need-to-know-about-prorata-rights-e5883fd21f80#.r5eot3b5l\n[prorata-rights]: https://bothsidesofthetable.com/what-all-entrepreneurs-need-to-know-about-prorata-rights-e5883fd21f80#.66fpdinl3\n",{"slug":4316,"featured":6,"template":681},"fundraising-tips-ceo","content:en-us:blog:fundraising-tips-ceo.yml","Fundraising Tips Ceo","en-us/blog/fundraising-tips-ceo.yml","en-us/blog/fundraising-tips-ceo",{"_path":4322,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4323,"content":4329,"config":4334,"_id":4336,"_type":17,"title":4337,"_source":18,"_file":4338,"_stem":4339,"_extension":21},"/en-us/blog/what-founders-ask-founders-about-getting-into-yc",{"title":4324,"description":4325,"ogTitle":4324,"ogDescription":4325,"noIndex":6,"ogImage":4326,"ogUrl":4327,"ogSiteName":667,"ogType":668,"canonicalUrls":4327,"schema":4328},"What Founders Ask Founders About Getting Into Y Combinator","5 questions a founder asked our founder about applying to YC!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683902/Blog/Hero%20Images/what-fouders-ask-founders-about-getting-into-yc-cover.png","https://about.gitlab.com/blog/what-founders-ask-founders-about-getting-into-yc","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What Founders Ask Founders About Getting Into Y Combinator\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kirsten Abma\"}],\n        \"datePublished\": \"2016-09-30\",\n      }",{"title":4324,"description":4325,"authors":4330,"heroImage":4326,"date":4332,"body":4333,"category":14},[4331],"Kirsten Abma","2016-09-30","\n\nUpdate: There is a followup post about the [YC application office hours](/blog/yc-application-office-hours/) as a response to this post.\n\nYou’ve got a great idea and feel you can make a great company and product out of it. You’ve worked on a basic version and feel like you’re ready to enter the big leagues.\n\nMaybe the accelerator program of Y Combinator is a good idea? But you’ve got so many questions.\nWhen are you ready for the next step? How can Y Combinator help you? What are some tips or tricks to get in and what should you highlight in the application process?\n\nThe deadline to [**apply**](https://www.ycombinator.com/apply/) for the Y Combinator program is **Tuesday October 4th 2016 by 8pm PT**.\n{: .alert .alert-webcast}\n\n\u003C!-- more -->\n\nIn combination with the blog post we released [the application of GitLab to YC](/blog/gitlabs-application-for-y-combinator-winter-2015/) as an example.\nBelow some questions that Reinder Visser from [Placker](https://www.placker.com) asked Sid about applying at Y Combinator a few days ago.\n\n#### Reinder: Why should I apply?\n{:.gitlab-orange}\n\n**Sid:** The reason we applied for Y Combinator with GitLab was that we had lost our first customer mid 2014. The customer explained that while they liked GitLab they were standardizing on an alternative solution.\nDmitriy and I figured every company would standardize on one solution to do [innersourcing](/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/) and we wanted that solution to be GitLab. The need to grow faster became the main reason to apply since there was a window of opportunity of a couple of years before people would standardize on one tool and be decided.\n\nWe feel that the time to apply for Y Combinator is when you have mainly outlined your product vision, you’re still working somewhat on the market, and are still trying to figure out how to sell it, and how to scale to accommodate your customers.\nThe Y Combinator program is ideal when you have a solid team of founders that have been working together for a while but you are ready to hire the rest of the team after you complete the Y Combinator program.\n\n#### Reinder: So why choose Y Combinator if there are more than 2000 accelerator programs in the world?\n{:.gitlab-orange}\n\n**Sid:** We feel that Y Combinator has the best network, the best partners, the best advice to give you because they see the most companies, and they are very strong at selecting them.\nGoing where the other strong candidates are, you will have a program where they have the largest set of data to offer you advice.\nInvestors have noticed the Y Combinator pattern which helps you raise funding under better terms with better investors. Our Y Combinator experience exceeded our high expectations.\n\n#### Reinder: Is it a problem that I'm a single founder?\n{:.gitlab-orange}\n\nJust last week Craig Cannon posted an article on [the most common misconceptions about applying for Y Combinator](http://themacro.com/articles/2016/09/common-misconceptions-about-applying-to-yc/).\nA concern people have sometimes is being a single founder, which is addressed in this article. While Y Combinator does [suggest having a cofounder](http://www.forbes.com/sites/bruceupbin/2011/10/18/paul-graham-dropbox-and-the-single-founder-exception/#1f0fadfb1f77) because startups are hard and cofounders definitely help, of the Summer 2016 batch, 8.5% had a solo founder.\nHere’s how the rest breaks down: 2 Founders (61.3%), 3 Founders (20.8%), 4 Founders (7.5%), 5+ Founders (1.9%). It may feel like being a single founder would make it harder to get the same load of work done,\nwhere it’s not so much that Y Combinator will be hard on your own, running a company on your own will be too.\n\n#### Reinder: If you decide to apply, how do you get in?\n{:.gitlab-orange}\n\n**Sid:** Take your time working on your answers for the application. Apply ahead of the deadline and don’t wait until the last minute if you can. But even last minute and late applications get a fair review so feel free to sleep on it.\nDescribe what your company does and why it’s unique. Be concise and opt for simple descriptions with the use mundane language, because a main reason why you get declined is that a reviewer doesn’t understand you business.\nHave other people review your application. Then ask them “what does my company do”? and write down their answer. Take that answer they have given you and use it to improve your description.\nWriting down what your company does is one of the hardest things, and if you don’t agree with their answer than your first answer wasn’t clear enough.\n\nEveryone feels their product is better, faster, easier, so get down to specifics why you feel that way but keep it simple. If people can’t recite back to you what it is you do and why you’re different, you have to change your answers.\nThere are a few question in the application that are of high importance to highlight you as a founder, one of them being: “Please tell us about the time you most successfully hacked some (non-computer) system to your advantage.”\nDon’t gloss over any questions but this one in particular is important. Choose answers or situations that show you’re an independent thinker and are creative.\nWhen you get invited to do a 10 minute interview after you’ve sent in your application make sure to prepare for the interview in detail.\nThey will ask you questions which are to be found on the internet so make sure to write down your answers and practice those. Your answers need to be concise and clear, when they are too long you will get cut off. I had someone ask me the questions over and over and interrupt me if my answer was longer than one breath.\n\n#### Reinder: So spill the beans; what’s it like?\n{:.gitlab-orange}\n\n**Sid:** Y Combinator raises your ambition level; everyone is motivated by the feeling of progress, and that’s what fast growth gives you.\nYou’re in a batch with the best people in the world, it’s a form of healthy peer pressure that motivates you to work harder and set that high pace to keep developing your product.\nThe first thing they ask you to do is launch, in case you haven’t done that yet. Y Combinator teaches you not to want your feature or product to be a certain way before shipping.\nShip today, and make it better or nicer over time. As soon as it’s live you’ll have more information and data on what the real problems are.\nFiguring out who your ideal customers are, how to reach them, how to raise your financing, how to hire people, these are questions that everyone in the program has.\nThe team of Y Combinator is really good at helping you to answer these questions, both during and after the 3 month program.\nBut the best part are the other founders, they are all interesting people and I'm very glad to call some of them my friends.\n",{"slug":4335,"featured":6,"template":681},"what-founders-ask-founders-about-getting-into-yc","content:en-us:blog:what-founders-ask-founders-about-getting-into-yc.yml","What Founders Ask Founders About Getting Into Yc","en-us/blog/what-founders-ask-founders-about-getting-into-yc.yml","en-us/blog/what-founders-ask-founders-about-getting-into-yc",{"_path":4341,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4342,"content":4348,"config":4353,"_id":4355,"_type":17,"title":4356,"_source":18,"_file":4357,"_stem":4358,"_extension":21},"/en-us/blog/gitlab-and-yubico-security-webcast",{"title":4343,"description":4344,"ogTitle":4343,"ogDescription":4344,"noIndex":6,"ogImage":4345,"ogUrl":4346,"ogSiteName":667,"ogType":668,"canonicalUrls":4346,"schema":4347},"Security Webcast with Yubico","GitLab and Yubico discuss security best practices for Git users.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666581/Blog/Hero%20Images/fido-u2f-yubikey.jpg","https://about.gitlab.com/blog/gitlab-and-yubico-security-webcast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Security Webcast with Yubico\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amara Nwaigwe\"}],\n        \"datePublished\": \"2016-08-31\",\n      }",{"title":4343,"description":4344,"authors":4349,"heroImage":4345,"date":4351,"body":4352,"category":14},[4350],"Amara Nwaigwe","2016-08-31","\n{::options parse_block_html=\"true\" /}\n\n\u003Cp>Git is distributed, meaning that people can maintain a copy of the source code. While Git’s distributed nature is what makes it so\npopular amongst developers, it is also what makes it a security concern to enterprises. The concern is that your source code is only\nas secure as the machine it’s been copied. Each of these devices could be a point of exposure. We understand how important it\nis to maintain the integrity of your source code.\u003C/p>\n\nWith the release of [GitLab 8.9][8.9] we announced that we partnered with [Yubico][youb-home] to help\ncustomers strengthen their authentication process with YubiKeys. YubiKeys are a single key providing universal 2nd factor\nauthentication into an unlimited number of applications. After [our announcement][yub], we asked Yubico to join us on a webcast. In this\nwebcast, we talked about common security threats and how you can use GitLab and Yubico to protect your private data\nand maintain a secure Git repo as a single source of truth.\n\n\u003C!-- more -->\n\n## In this Webcast\n\n- Top security threats\n- Inside look at how YubiKeys work\n- Demo of setting up and using a YubiKey with GitLab\n- Demo GitLab’s additional security capabilities beyond authentication\n- Industry best practices for securing your Git repository\n\n## Recording & Slides\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pO9-7R3N5Ok\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003Cbr>\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://docs.google.com/presentation/d/175zQz9CcQf3fQ65rbYFH_ysgllEkXrtnjYpAH_CDcrc/embed?start=false&loop=false&delayms=5000\" frameborder=\"0\" width=\"1280\" height=\"749\" allowfullscreen=\"true\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Key Takeaways\n\nIf you don’t have time to watch the full video, here are the highlights.\n\n\u003Cdiv class=\"panel panel-info\">\n\u003Cp class=\"panel-heading\"> \u003Cstrong>Definition of a YubiKey\u003Cstrong>\u003Cp>\n\u003Cdiv class=\"panel-body\">\n  \u003Cp>A \u003Ca href=\"https://www.yubico.com/faq/yubikey/\">YubiKey\u003C/a> is a small hardware device that offers two-factor authentication with a simple touch of a button.\u003C/p>\n\u003C/div>\n\u003C/div>\n\u003Cbr>\n\u003Cdiv class=\"panel panel-success\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>Reasons YubiKeys are preferred over 2FA via SMS\u003C/strong>\u003C/p>\n\n\u003Cdiv class=\"panel-body\">\n  \u003Cp>From a security standpoint, push notifications and SMS codes (a form of \u003Ca href=\"https://en.wikipedia.org/wiki/One-time_password\">One-time Passwords\u003C/a>) are all\nvulnerable to phishing attacks and replay attacks. Getting a bit technical here, if you are using the U2F protocol\nwith the YubiKey, a properly implemented U2F registration flow contains Origin (phishing protection!) information\nas well as TLS Channel Identification information (Man in the Middle attack protection). Finally, the\n    challenge-response piece of the U2F protocol provides complete replay attack protection.\u003C/p>\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>GitLab + YubiKey\u003C/strong>\u003C/p>\n\u003Cdiv class=\"panel-body\">\nOur goal is to secure our customer’s work with proven, seamless solutions. The YubiKey provides\n  \u003Ca href=\"https://www.yubico.com/2015/11/yubico-docker-codesign/\">one-touch authentication\u003C/a>, reducing the number of steps users have to take to access their accounts.\nRemembering and entering passwords or pins can be a cumbersome process. Hopefully, YubiKeys can reduce some\nof that friction and encourage more teams to secure their GitLab instance.\n\u003C/div>\n\u003C/div>\n  \u003Cbr>\n\n\u003Cdiv class=\"panel panel-danger\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>GitLab's additional security capabilities beyond authentication\u003C/strong>\u003C/p>\n\n\u003Cdiv class=\"panel-body\">\n  \u003Cul>\n    \u003Cli>Access and permissions: control who has access to your repositories\u003C/li>\n     \u003Cli>Workflow management: control what changes are being made to your repositories\u003C/li>\n     \u003Cli>Audit trail: keep a record of what happened within you GitLab instance\u003C/li>\n  \u003C/ul>\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>Nine security best practices\u003C/strong>\u003C/p>\n\n\u003Cdiv class=\"panel-body\">\n\u003Cp>Of course there are many more than just nine. These were the ones that stuck out to us but for more resources\n  take a look at \u003Ca href=\"http://resources.infosecinstitute.com/security-best-practices-for-git-users/\">InfoSec’s article on security best practices for Git users\u003C/a> and you can also check out\n  the \u003Ca href=\"/handbook/security/\">security section\u003C/a> of our employee handbook.\u003C/p>\n\n  \u003Col>\n    \u003Cli>Assign strong passwords and store in an encrypted vault (e.g., \u003Ca href=\"https://1password.com/\">1Password\u003C/a>).\u003C/li>\n    \u003Cli>Never reuse your passwords across accounts.\u003C/li>\n    \u003Cli>Ensure proper user identity by restricting the use of shared or system accounts.\u003C/li>\n    \u003Cli>Enforce two-factor authentication.\u003C/li>\n    \u003Cli>Assign and review the proper access and permissions levels to projects.\u003C/li>\n    \u003Cli>Only use HTTPS or SSH to access git repositories, git repository management software, CI systems and ticketing / bug tracking systems.\u003C/li>\n    \u003Cli>Enforce integrity checks on all incoming objects by setting \u003Ccode>transfer.fsckObjects\u003C/code>, \u003Ccode>fetch.fsckObjects\u003C/code> and \u003Ccode>receive.fscObjects\u003C/code> to \u003Ccode>true\u003C/code>.\u003C/li>\n    \u003Cli>Enforce usage of \u003Ccode>.gitignore\u003C/code> files by providing a proper \u003Ccode>.gitignore\u003C/code> file content to all current and future projects.\u003C/li>\n  \u003C/ol>\n\u003C/div>\n\u003C/div>\n\nAs always, if you have any questions feel free to comment on this post or [tweet at us].\n\n\u003C!-- identifiers -->\n\n[1-pass]: https://1password.com/\n[1-t-pass]: https://en.wikipedia.org/wiki/One-time_password\n[8.9]: /releases/2016/06/22/gitlab-8-9-released/\n[hand]: /handbook/security/\n[post]: http://resources.infosecinstitute.com/security-best-practices-for-git-users/\n[touch]: https://www.yubico.com/2015/11/yubico-docker-codesign/\n[tweet at us]: https://twitter.com/gitlab\n[what-is]: https://www.yubico.com/faq/yubikey/\n[yub]: /blog/gitlab-adds-support-for-u2f/\n[youb-home]: https://www.yubico.com/\n\n\u003C!-- custom styles -->\n\n\u003Cstyle>\n.panel-gitlab {\n  border-color: rgba(252,163,38,.3);\n}\n.panel-gitlab > .panel-heading {\n  color: rgb(226,67,41);\n  background-color: rgba(252,163,38,.3);\n  border-color: rgba(252,163,38,.3);\n}\n.panel-gitlab-purple {\n  border-color: rgba(107,79,187,.3);\n}\n.panel-gitlab-purple > .panel-heading {\n  color: rgb(107,79,187);\n  background-color: rgba(107,79,187,.3);\n  border-color: rgba(107,79,187,.3);\n}\n\u003C/style>\n",{"slug":4354,"featured":6,"template":681},"gitlab-and-yubico-security-webcast","content:en-us:blog:gitlab-and-yubico-security-webcast.yml","Gitlab And Yubico Security Webcast","en-us/blog/gitlab-and-yubico-security-webcast.yml","en-us/blog/gitlab-and-yubico-security-webcast",{"_path":4360,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4361,"content":4367,"config":4372,"_id":4374,"_type":17,"title":4375,"_source":18,"_file":4376,"_stem":4377,"_extension":21},"/en-us/blog/using-gitlab-labels",{"title":4362,"description":4363,"ogTitle":4362,"ogDescription":4363,"noIndex":6,"ogImage":4364,"ogUrl":4365,"ogSiteName":667,"ogType":668,"canonicalUrls":4365,"schema":4366},"Using GitLab Labels","Learn how Brian uses GitLab Labels for his workflow","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684871/Blog/Hero%20Images/gitlab-labels-cover.jpg","https://about.gitlab.com/blog/using-gitlab-labels","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Using GitLab Labels\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brian O'Connell\"}],\n        \"datePublished\": \"2016-08-17\",\n      }",{"title":4362,"description":4363,"authors":4368,"heroImage":4364,"date":4370,"body":4371,"category":14},[4369],"Brian O'Connell","2016-08-17","\nThis post is a customer story on how using **GitLab Labels** can help you (a lot) to\ndirect your **focus** and to organize your **workflow**.\n\n\u003C!-- more -->\n\n## Steps\n\n1. Drink the [DevOps](/topics/devops/) Koolaid\n1. Start managing your infrastructure as code\n1. Become afraid of how a small change in the wrong place could devastate\nyour infrastructure\n1. Freak out\n1. Put controls in place so changes don't get pushed to production without approval\n1. Pull your hair out trying to figure out which MRs need your attention\n1. These were the steps we took that resulted in us embracing GitLab labels\nto direct focus. Once you start managing your infrastructure as code, using\nChef or other tools, you may quickly find a need to restrict who can merge to\nmaster in order to prevent chaos.\n\nWe use [GitLab Enterprise][ee] for [source code management](/solutions/source-code-management/).\n\nOne of the great features it has is the ability to use **labels** to help\ndirect **focus** and **workflow**.\n\n## GitLab labels\n\nHow does [GitLab define their label feature][doc]?\n\n> _Labels provide an easy way to categorize the issues or merge requests based\non descriptive titles like bug, documentation or any other text you feel like.\nThey can have different colors, a description, and are visible throughout the\nissue tracker or inside each issue individually._\n\nWhat labels did we adopt?\n\nRight now we are using 11 GitLab labels in our projects.\n\n![GitLab labels](https://about.gitlab.com/images/blogimages/using-gitlab-labels/gitlab-labels.jpg){: .shadow}\n\nEach of these has a specific meaning understood by all of our team members.\n\n| Label | Description | Applied Automatically? |\n| ----- | ----------- | ---------------------- |\n| Blocked | Indicates a request should not be merged yet because it is blocked by an external entity. This could be waiting on another cookbook update or service needs to be updated/deployed. | N |\n| Blocked by Events | This MR should not be merged because it is waiting for one or more events to complete. Sometimes potentially impacting changes don't get pushed out if we have an active sporting event. | N |\n| Blocked by Maintenance | This MR should not be merged until site maintenance is complete. | N |\n| Dogfooding | This MR should not be merged, but is being internally tested. This is usually used for our custom Chef Dev Environment. | N |\n| Major | This is a major and breaking change as defined by [SemVer]. This code should be reviewed very carefully to understand the scope of impact. | Y |\n| Minor | This is a minor change as defined by [SemVer]. It adds a new feature to the API. | Y |\n| Patch | This is a fix as defined by [SemVer]. | Y |\n| Needs Changes | Someone has reviewed the MR and the code needs to be updated. Reviewers comments are sufficient to update. | N |\n| Needs Discussion | Someone has reviewed the MR and a discussion is necessary to get this MR back on track. | N |\n| Needs Review | This is a new MR and no one has looked at it yet. | Y |\n| Ready to Deploy | This MR has been reviewed by the correct number of individuals and is ready to be deployed. | N |\n\n## How do we use labels?\n\nIn general, a new MR will get two labels automatically applied to it.\nThe \"Needs Review\" and either Major/Minor or Patch.\n\nThe merge request will look a bit like this.\n\n![Labels view on a MR](https://about.gitlab.com/images/blogimages/using-gitlab-labels/gitlab-labels-on-mr.jpg){: .shadow}\n\nOnce someone does an initial review, they may add additional labels such\nas \"Blocked\", \"Needs Changes\", or \"Needs Discussion\". After the minimum\nnumber of reviewers have looked at the change, the last reviewer will\nremoved the \"Needs Review\" label and either merge the MR or add a\n\"Ready to Deploy\" label so that it can be merged at the appropriate time.\n\n## How does this help us?\n\nGitLab displays labels when viewing all open MRs. This makes it to quickly\nglance at all MRs that need some form of attention, generally this is those\nwith a \"Needs Review\" tag. Prior to implementing this labeling system I\nwould have to open every MR and read the comments to understand the state.\nNow I can direct my attention to only those items that need it.\n\n----\n\nThis post was [originally published][post] by Brian O'Connell himself.\n{: .note}\n\n\u003C!-- \noriginal cover photo: http://www.freeimages.com/photo/labels-1420786\nlicense: http://www.freeimages.com/license\n-->\n\n\u003C!-- identifiers -->\n\n[doc]: https://docs.gitlab.com/ee/user/project/labels.html\n[EE]: /features/#enterprise\n[post]: http://infrastructuredevops.com/08-04-2016/gitlab-labels.html\n[semver]: http://semver.org/\n",{"slug":4373,"featured":6,"template":681},"using-gitlab-labels","content:en-us:blog:using-gitlab-labels.yml","Using Gitlab Labels","en-us/blog/using-gitlab-labels.yml","en-us/blog/using-gitlab-labels",{"_path":4379,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4380,"content":4386,"config":4390,"_id":4392,"_type":17,"title":4393,"_source":18,"_file":4394,"_stem":4395,"_extension":21},"/en-us/blog/trends-in-version-control-land-microservices",{"title":4381,"description":4382,"ogTitle":4381,"ogDescription":4382,"noIndex":6,"ogImage":4383,"ogUrl":4384,"ogSiteName":667,"ogType":668,"canonicalUrls":4384,"schema":4385},"Trends in Version Control Land: Microservices","The benefits and drawbacks of microservices and how to decide if it is right for your team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667875/Blog/Hero%20Images/trends-in-version-control-land-microservices-cover.jpg","https://about.gitlab.com/blog/trends-in-version-control-land-microservices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Trends in Version Control Land: Microservices\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-08-16\",\n      }",{"title":4381,"description":4382,"authors":4387,"heroImage":4383,"date":4388,"body":4389,"category":14},[911],"2016-08-16","\n\nOne trend of the last few years is microservices architecture. In this post we’re\nlooking at what that is, and what some of the benefits and drawbacks are.\n\n**Note:** This is the third post of our four-post series on **Trends on Version Control Land**. Take a look at the first post on [Innersourcing][post-1] to learn more about common challenges large organizations face and how Innersourcing can solve them. Also check out our second post, [Release Early, Release Often][post-2], to read about how and why GitLab releases monthly.\n{: .note}\n\n\u003C!-- more -->\n\n## What are microservices?\n\n[Microservices architecture][micro-arch] is a way of designing software applications as smaller, independent,\ncloud-based services rather than one monolithic data center. [Netflix][netflix-micro] is a good example: their\nusers application, movies application and ratings application are deployed independently.\nNetflix has made a lot of the code behind their [microservice architecture open source][netflix-oss]. [Uber][uber-eng], [Soundcloud][soundcloud-micro], [Hailo][hailo-micro], [Amazon][amazon-micro], and [Ebay][ebay-micro]\nare a few other companies that [are using microservices][companies-micro] to deliver their applications. Uber shared\na really nice narrative of their [move from monolith to microservices][uber-blog] on their blog.\n\n## Benefits of microservices\n\n**System-wide stability:** Using Nextflix as an example again, since moving to a microservices architecture, they have achieved much greater system-wide stability,\nbecause API service interruptions are restricted to one service.\n\n**Scale teams:** With [microservices](/topics/microservices/) you can move more quickly because each app can\ndeploy independently of the others. Teams can operate independently. Since larger teams have more overhead (decisions, training, etc.), being able to split them up per service increases efficiency.\n\n**Diverse technology:** Since each service is independent, you can use the best programming language and database for each respective job.\n\n**Improved architecture:** Splitting up the application in multiple services enforces module boundaries; each application has its own responsibilities. Please note that it only helps with enforcement, in a monolitic application you can also have great module boundaries.\n\n## Drawbacks\n\n**Latency:** Making function calls between different services instead of in an application slows everything down.\n\n**Distributed system:** The [first rule of distributed object design](http://martinfowler.com/bliki/FirstLaw.html) is don't distribute your objects. Distributed systems are harder to debug, reason about, and do transactions in.\n\n**Three-step rollouts:** If you have a change that affects other services you first have to push a new version of your application, then ensure all other services start using that, and finally deprecate the old version. If it was a single application that process could be done in one step.\n\n**The need to accommodate failure modes:** You can only increase system-wide stability if services can deal with other services being down. You will have to program this into your application. For example, if Netflix's recommendations service goes down, they can't just remove recommendations from the console. Instead they'll need to build their application to display generic recommendations instead of personalized ones.\n\n**Infrastructure complexity:** Microservices increase the number of applications you have to deploy, monitor, and throttle. You will need to automate everything to make this work.\n\n**Multiple projects:** Each service will need to be its own project to achieve the necessary independence. Each service will need multiple repositories, CI, CD, and issue trackers.\n\n## GitLab and microservices\n\nA major goal for us at GitLab is to make sure you can do everything you need to do within GitLab, with as few external integrations to deal\nwith as possible. This way, you don’t have to set up [CI/CD](/features/continuous-integration/), and an issue tracker for each project and spend the time integrating them, they're all already pre-configured to use from one single UI.\nYou can [move issues](/blog/feature-highlight-move-issues/) between the projects of the different services and aggregate them with [group level milestones](https://docs.gitlab.com/ee/user/project/milestones/index.html).\nTo ensure the right people have access to each project you can use [LDAP group sync](/blog/feature-highlight-ldap-sync/) and the ability to invite teams from other projects.\n\n## When are microservices right for your team?\n\nWe think that microservices are great when your team is spending too much time coordinating.\nThere is no set number but when you have more than 25 backend developers, coordination becomes more challenging.\nFor another take on the benefits and drawbacks see [Martin Fowler's take on the trade-offs](http://martinfowler.com/articles/microservice-trade-offs.html).\n\nWatch out for our last post of this series,  we'll share our thoughts on what industries are likely to embrace **Open Source**!\n\n\u003C!-- identifiers -->\n\n[post-1]: /topics/version-control/what-is-innersource/\n[post-2]: /blog/release-early-release-often/\n\n[amazon-micro]: http://thenewstack.io/led-amazon-microservices-architecture/\n[companies-micro]: http://microservices.io/articles/whoisusingmicroservices.html\n[ebay-micro]: http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html\n[hailo-micro]: https://sudo.hailoapp.com/services/2015/03/09/journey-into-a-microservice-world-part-2/\n[micro-arch]: http://martinfowler.com/articles/microservices.html#MicroservicesAndSoa\n[netflix-micro]: http://techblog.netflix.com/2015/02/a-microscope-on-microservices.html\n[netflix-oss]: https://netflix.github.io/\n[soundcloud-micro]: https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith\n[uber-blog]: https://eng.uber.com/building-tincup/\n[uber-eng]: https://eng.uber.com/soa/\n\n\u003C!--\ncover image: http://hubblesite.org/newscenter/archive/releases/2016/28/image/a/format/xlarge_web/layout/thumb/\ncopyright - public domain: http://hubblesite.org/about_us/copyright.php\n-->\n",{"slug":4391,"featured":6,"template":681},"trends-in-version-control-land-microservices","content:en-us:blog:trends-in-version-control-land-microservices.yml","Trends In Version Control Land Microservices","en-us/blog/trends-in-version-control-land-microservices.yml","en-us/blog/trends-in-version-control-land-microservices",{"_path":4397,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4398,"content":4404,"config":4408,"_id":4410,"_type":17,"title":4411,"_source":18,"_file":4412,"_stem":4413,"_extension":21},"/en-us/blog/release-early-release-often",{"title":4399,"description":4400,"ogTitle":4399,"ogDescription":4400,"noIndex":6,"ogImage":4401,"ogUrl":4402,"ogSiteName":667,"ogType":668,"canonicalUrls":4402,"schema":4403},"Release Early, Release Often","Let’s explore the rise of releasing early and often!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683752/Blog/Hero%20Images/release-early-release-often-cover.jpg","https://about.gitlab.com/blog/release-early-release-often","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Release Early, Release Often\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-07-21\",\n      }",{"title":4399,"description":4400,"authors":4405,"heroImage":4401,"date":4406,"body":4407,"category":14},[911],"2016-07-21","\n\nAnother trend that keeps popping onto the radar is a continuing **reduction in time between deploys**. In this post we’re looking at what that means and why it’s happened.\n\n**Note:** this post is the second of the series on _Trends in Version Control_. The first one explored _[Innersourcing][part-1]_.\n{: .note}\n\n\u003C!-- more -->\n\nSoftware development has changed a lot over the decades. Development practices have shifted from traditional waterfall to [agile development](/solutions/agile-delivery/) and now to even faster deployments. Applications used to be deployed every 6 months. There would be one big deploy. Teams would be briefed in advance. Then on release day it’s all hands on deck to ensure the release goes as planned. While two releases a year seems frequent compared to the days when we used to wait several years for new product and operating systems, people are still moving away from biannual releases and opting for more frequent release cycles.\n\n## The logic behind deploying early and often\n\nOne of the biggest issues with carrying out a large deployment once or twice a year is that it creates a bottleneck and you end up with a coordination problem between all the features you want to release. If everything is ready to go but one small feature is delayed, then everything is delayed. Also let’s say that there is a very real off chance that there is a bug in the deployment that you’ve spent 6 months working on. You deploy it and realize there is a bug; however, your deployment contains so many lines of code that it won’t be easy to spot the exact thing that caused the bug.\n \nEverything will not be perfect when it’s sent out the door the first time. The early-and-often deployment mindset is about shifting away from full-featured perfection to smaller slices of customer value. Everything is thought of in terms of iterations, or drafts; basically, it is a permanent work in progress, always getting better.\n \nIf there’s a bug, it’s not nearly as a big of a deal as in the days of the annual or biannual deployment, because it’s much easier to isolate what caused it and to fix it, and you can release a fix almost immediately. If a particular feature isn’t ready, that won’t hold up the release; that feature can just be released next month.\n\n## Moving to time-based releases\n\nTo make releasing early and often possible, teams have started using [time-based releases] versus feature-based releases. Moving to time-based releases means no more waiting for features to be ready; instead you only merge features that are ready at the time of your release. At GitLab, we stick to time-based releases, also does  [Docker], [Ubuntu] and [GNOME]. Some may even say we’ve taken them to the extreme. Since 2011, we always ship on the 22nd of every month. Then any patches are released when they are ready. When we first started doing time-based releases, it was difficult to stick to them. Here’s some advice on how you make the move.\n\n- Decouple features so you don’t have to hold the deploy for one feature\n- Focus on getting smaller features out the door when the first iteration is usable \n- Adopt time-based releases and ship on that date \n- Patches can be released when they are ready\n- Reduce the time between releases by getting from issue to deploy quicker\n\n## Key takeaway\n\nThe longer you wait between releases, the more attractive it can be to hold your release to wait for the next feature. However, you should stick to time-based release. Keep in mind with time-based releases you also have to shorten the time between releases too. The reality is that the idea of the perfect software release is now obsolete, because technology advances too quickly for that to ever be possible, and that’s a good thing. Perfection is no longer the point: usability, fast turnaround, and overall development efficiency are far more important.\n\nWant to read up on more trends? Check out our last post on [Innersourcing][part-1].\n\n\u003C!-- cover image: https://unsplash.com/photos/r-EecLdRRww - resized and compressed -->\n\n\u003C!-- Identifiers, in alphabetical order -->\n\n[DOCKER]: https://github.com/docker/docker/wiki\n[GNOME]: https://wiki.gnome.org/ReleasePlanning/TimeBased\n[part-1]: /topics/version-control/what-is-innersource/\n[time-based releases]: http://www.infoworld.com/article/2638146/open-source-software/time-based-release-methodologies-and-open-source-communities.html\n[Ubuntu]: https://wiki.ubuntu.com/TimeBasedReleases\n",{"slug":4409,"featured":6,"template":681},"release-early-release-often","content:en-us:blog:release-early-release-often.yml","Release Early Release Often","en-us/blog/release-early-release-often.yml","en-us/blog/release-early-release-often",{"_path":4415,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4416,"content":4422,"config":4426,"_id":4428,"_type":17,"title":4429,"_source":18,"_file":4430,"_stem":4431,"_extension":21},"/en-us/blog/gitlab-is-open-core-github-is-closed-source",{"title":4417,"description":4418,"ogTitle":4417,"ogDescription":4418,"noIndex":6,"ogImage":4419,"ogUrl":4420,"ogSiteName":667,"ogType":668,"canonicalUrls":4420,"schema":4421},"GitLab is open core, GitHub is closed source","We think of ourselves as an open source company. But today paxcoder on Hacker News rightly remarked that calling it an open core company is more accurate.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683647/Blog/Hero%20Images/sailing-5.jpg","https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab is open core, GitHub is closed source\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-07-20\",\n      }",{"title":4417,"description":4418,"authors":4423,"heroImage":4419,"date":4424,"body":4425,"category":14},[911],"2016-07-20","\n\nDisclosure: I'm the CEO of GitLab and we compete with GitHub.\n\nWe think of ourselves as an open source company. But today paxcoder on Hacker News rightly [remarked that calling it an open core company is more accurate](https://news.ycombinator.com/item?id=12129626).\n\nWe ship [GitLab CE](/install/ce-or-ee/) which is open source and GitLab EE that is closed source. We try to be [a good steward of the open source project](/company/stewardship/). GitLab EE is proprietary, closed source code but we try to work in a way similar to GitLab CE: the [issue tracker](https://gitlab.com/gitlab-org/gitlab-ee/issues) is publicly viewable and the [EE license](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE) allows modifications.\n\nWhen we mention that GitLab is available in an open source edition people frequently ask [\"Isn't GitHub open source?\"](http://stackoverflow.com/questions/24254324/is-github-com-source-code-open-source). I understand the confusion between open source hosting and open source software. The hosted service [GitHub.com](https://github.com/) is free for open source projects and it has fundamentally improved open source collaboration. But the software GitHub's service is based on is closed source.\n\n\u003C!-- more -->\n\nAt the end of [a presentation in Spanish](https://vimeo.com/62219734) at RubyConf Argentina in 2012 ([our English translation](https://gitlab.com/snippets/22853)) you see someone in the audience ask why GitHub isn't open source. The presenter's answer is that this would hurt their business. Also mentioned in the presentation is that GitHub encrypts their source code with [Ruby Encoder](https://www.rubyencoder.com/) and they have text in [the license](https://enterprise.github.com/license) that forbids customers from using GitHub Enterprise to compete with GitHub.com.\n\nOf course, GitHub has every right to close and encrypt their source code. GitHub [very actively contributes to open source](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) themselves, including many contributions to Git and Ruby on Rails, and releasing libraries and applications like libgit2, [Atom](https://atom.io/), and Hubot. Also note that we build GitLab with software that GitHub open sourced such as libgit2.\n\nIn conclusion (TLDR), GitLab has an open core business model and ships both open and closed source software. GitHub hosts most open source projects but ships closed source software.\n",{"slug":4427,"featured":6,"template":681},"gitlab-is-open-core-github-is-closed-source","content:en-us:blog:gitlab-is-open-core-github-is-closed-source.yml","Gitlab Is Open Core Github Is Closed Source","en-us/blog/gitlab-is-open-core-github-is-closed-source.yml","en-us/blog/gitlab-is-open-core-github-is-closed-source",{"_path":4433,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4434,"content":4439,"config":4444,"_id":4446,"_type":17,"title":4447,"_source":18,"_file":4448,"_stem":4449,"_extension":21},"/en-us/blog/building-an-open-source-company-interview-with-gitlabs-ceo",{"title":4435,"description":4435,"ogTitle":4435,"ogDescription":4435,"noIndex":6,"ogImage":4436,"ogUrl":4437,"ogSiteName":667,"ogType":668,"canonicalUrls":4437,"schema":4438},"Building an Open Source Company: Interview with GitLab's CEO","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684717/Blog/Hero%20Images/team_gitlab.png","https://about.gitlab.com/blog/building-an-open-source-company-interview-with-gitlabs-ceo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Building an Open Source Company: Interview with GitLab's CEO\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Chen\"}],\n        \"datePublished\": \"2016-07-14\",\n      }",{"title":4435,"description":4435,"authors":4440,"heroImage":4436,"date":4442,"body":4443,"category":14},[4441],"Jason Chen","2016-07-14","\n\nPlease note that while we think of ourselves as an open source company it would be more accurate to call it an open core company since we ship both the open source GitLab Community Edition and the close source GitLab Enterprise Edition. Thanks to paxcoder for [pointing this out on Hacker News](https://news.ycombinator.com/item?id=12129626).\n\n[GitLab] began as a labor of love from [Dmitriy Zaporozhets] and [Valery Sizov], who built the first version together in 2011. Like many open source authors, they were only able to work on the project part time. [Sid Sijbrandij] joined forces a year later and created [GitLab.com], the first SaaS offering and first experiment with monetization.\n\n\u003C!-- more -->\n\nToday GitLab is a model for open source sustainability and [stewardship]. It is being used in over 100,000 organizations including RedHat, NASA, Intel, Uber, to name just a few. Large organizations buy [enterprise licenses], sustaining and growing both the company and the free open source project. GitLab now has over 90 employees, including Sid and Dmitriy who serve as CEO and CTO, respectively.\n\n**There has been a lot of discussion recently around long term sustainability in open source. Naturally, some of these conversations have turned towards companies. GitLab is one of the most successful examples of a company born out of and supporting an open source project. How do you think about open source in GitLab’s DNA and other similar open source companies?**\n{: .alert .alert-info}\n\n**Sid:** I think people are realizing more and more that open source is not just a license. It is also a way your company behaves. I think if you want to get the benefits of open source, it’s better to have an open development process. Everyone can see what’s going on all the time - what features are planned, who’s working on them, what was the decision process of how they would be implemented. We sometimes then receive comments on our issue tracker from real users explaining that a feature, given the way we designed and planned to build it, does not address their need. We learn from that and we get a better end product.\n\nWe took that a bit further at GitLab. We also just try to be very open as a company. Our complete company handbook - with many, many pages describing everything from sales, marketing, infrastructure - is completely open. We’re even going so far that our issue trackers for finance and marketing are open as well, so you can see what they are working on too. I’m not sure this is necessary, but being open is something we enjoy. It helps us be better and helps attract great new people to work with us.\n\n**For open source projects that have gone down the company path, do you think open source itself is enough of a differentiator to be competitive against a similar proprietary product?**\n{: .alert .alert-info}\n\n**Sid:** I don’t think open source by itself is enough. Open source is wind in your back. It’s something that users and customers prefer. It’s a great go-to market, so it makes it a lot easier for people to adopt. It allows you, compared to previous enterprise software plays, to focus more on building a great product, and a bit less than previously on building a sales force. You’ll always need both the product and sales and marketing to be able to build a sustainable company.\n\nWe think GitLab is already the best product but we want to keep building to make it even better and communicate its value. GitLab is now the most popular solution for single-tenant installations. Our immediate goal is most revenue for single-tenant installations. Then we want to focus on private repositories through SaaS, then maybe someday public repositories. We’re not going to get there by just the power of open source.\n\n**How did GitLab’s business model come about?**\n{: .alert .alert-info}\n\n**Sid:** At first I thought SaaS would be the sustainable business model for GitLab. People were using it, but mostly with smaller teams, not larger teams. The larger organizations were all running single tenant installations in house. They had a lot of feature requests so we kind of pivoted towards serving them better. Listening to those customers worked out really well. We built what they needed but shipped most of the features to everyone. The ones that were more appropriate for very large organizations with 100+ users, we put them into our proprietary enterprise product.\nWe then looked at the SaaS product and realized most of the revenue is going to come from single-tenant installations, so we decided to make the GitLab.com totally free - no restrictions on the number of private projects or collaborators and free CI.\n\n**How did GitLab figure out its pricing?**\n{: .alert .alert-info}\n\n**Sid:** By making lots of mistakes. The common mistake that we’ve also made is that we priced too low. GitLab used to be $20/user/year, now it’s $40. I think it’s probably still on the low side.\n\n**At Salesforce, I was told by an SVP if 20% of your customers are not upset at you over pricing, you are leaving money on the table.**\n{: .alert .alert-info}\n\n**Sid:** I think we have very few. I actually can’t think of a customer that’s really upset at us for our pricing, so probably we’re leaving too much money on the table. The great thing is we can make it work right now and we’re always close to being cash flow positive. We give away a lot, but that also helps companies adopt a product quickly. If it’s great value for money, it will spread faster.\n\n**GitLab has a pretty impressive list of customers. How did they find out about GitLab? Did you do any marketing or outbound?**\n{: .alert .alert-info}\n\n**Sid:** No, nothing. They just found the open source project. If you wanted proper version control, single tenant, and open source, GitLab was and is the best option. We are just now beginning to do sales and hired three inbound SDRs and an outbound SDR Lead in the last two months, so we're just now starting to build those teams.\n\n**Does GitLab’s success with the on premise model challenge the conventional wisdom that everything, including the enterprise is moving to the cloud?**\n{: .alert .alert-info}\n\n**Sid:** Yeah, I think it challenges it a bit. We still believe in the cloud, as in computing infrastructure. I think most GitLab installations run on AWS. But if you look according to research, in 2019, 80 cents of every dollar spent on software will go to on premises or single tenant software.\n\nIt differs for the product as well. I think right now everybody has accepted a cloud CRM solution. But we see that, for various reasons, source control is one of the last movers. Sometimes it’s for security reasons - companies want to put it behind a VPN - and sometimes it’s for legal reasons - companies want to know exactly where it’s hosted, and who has access to it.\n\n**With so many of your users behind private installations, how do you get analytics and feedback from them?**\n{: .alert .alert-info}\n\n**Sid:** That’s hard. We don’t have a lot of data since GitLab doesn’t call home per se and we don’t want it to, as a good steward of the open source project. What GitLab does have is a version check. It shows you an image whether your version is up to date, out of date, or whether there’s a security problem with it. We receive those checks, so we can see what is out there in the wild, which helps a bit.\n\n**Do you have to rely on users asking for features then?**\n{: .alert .alert-info}\n\n**Sid:** Yeah, we want to make user feedback easier by having open issue tracking. Anything we do feature-wise, it’s all happening on our issue tracker. When a sales person is talking with a customer and they have a request, we’ll post a public issue about it. We won’t tell you who the customer is, but the issue will be linked in our CRM system so internally we can all see who it is and what the interaction is or reach out to the customer to get more information. We really try to make everything happen in public. Before we used to have internal and external issue trackers, and we found there was a lot of duplication. This way, whatever we’re making, we get the best input. We get to get input from our developers, from the community, from our sales people and sometimes customers actually engage on the issue tracker themselves too.\n\n**Has GitLab’s open source and SaaS offering been a good funnel into the enterprise offering?**\n{: .alert .alert-info}\n\n**Sid:** We actually crunched some numbers the other day, with some help of external people. We kind of expected our open source version to be a really good indicator of people getting the enterprise version. But it turned out that GitLab.com was an even better indicator. It was a lot more important than we thought as a go-to market and making people aware. Which is, for us, kind of nice, because we have e-mail addresses of the people using GitLab.com, so we can reach out to them. We don’t have that for people that download the community edition. So that finding was a relief to us.\n\n**How did you decide to take GitLab from the sustainable business path, onto the venture funded company track?**\n{: .alert .alert-info}\n\n**Sid:** In 2014, we had a customer that was using GitLab, who then switched to GitHub, not because they didn’t like it, but because somewhere up the corporate hierarchy, it was decided that the whole company should use GitHub.\n\nThey were super happy with GitLab, but they still had to switch. We were like “Oh, wow. This might happen with all our large customers,” because every company in the world is going to standardize on one solution within the company. We want that to be GitLab. So we need to grow a lot faster to be able to convince those people at the top that make the decisions - the CIOs. And to reach them we need sales and marketing. We don’t have 10 years to do this, this standardization will happen in the next three years.\n\nThat’s why we decided to apply to YCombinator to grow faster. I think that’s been a good decision. By March of 2015, we were 9 people and fit into one large car. Now we’re 93 people and it takes two buses. We’ve since won back this customer, so we’re very glad about that. We don’t want to leave any customer behind. Our mission right now is to make sure all those large enterprises, who are probably using a couple of solutions internally right now, standardize on GitLab.\n\n**It has been said that lot of software markets is winner takes all. Do you think, in the git hosting space, there will be a winner takes all?**\n{: .alert .alert-info}\n\n**Sid:** I think there’s room for multiple solutions. I think most companies will standardize on one thing for the whole company. I’ve talked to a few venture capitalists, and they say it’s common that 70% of the profit in the market goes to **#1**. Then **#2** has something, and number **3** ends up with very little.\n\nAs soon as you take VC money, you want to make sure you end up as **#1**. Also, we think it makes a lot of sense for developer collaboration software to be open source. And so we want people to use GitLab.\n\nWe’re excited. We think we have a great product, and we’re even more excited of what’s coming out next month and the month after that. We just want to make it a little bit better every month. That served us well so far, and that’s what we’re going to continue to do. We think there’s a big advantage to having the whole flow in one product, so we’re going to try to make the market aware of that.\n\n_This post was originally posted on [medium.com] by [Jason Chen] himself._\n\n\u003C!-- Identifiers -->\n\n[Jason Chen]: https://medium.com/@jhchen\n[medium.com]: https://medium.com/@jhchen/290180d172da#.niptat9rb\n[GitLab]:\n[GitLab.com]: https://gitlab.com/users/sign_in\n[Dmitriy Zaporozhets]: https://twitter.com/dzaporozhets\n[Valery Sizov]: https://twitter.com/Sizov_Valeriy\n[Sid Sijbrandij]: https://twitter.com/sytses\n[stewardship]: /company/stewardship/#our-stewardship-of-gitlab-ce\n[enterprise licenses]: /pricing/\n",{"slug":4445,"featured":6,"template":681},"building-an-open-source-company-interview-with-gitlabs-ceo","content:en-us:blog:building-an-open-source-company-interview-with-gitlabs-ceo.yml","Building An Open Source Company Interview With Gitlabs Ceo","en-us/blog/building-an-open-source-company-interview-with-gitlabs-ceo.yml","en-us/blog/building-an-open-source-company-interview-with-gitlabs-ceo",{"_path":4451,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4452,"content":4458,"config":4463,"_id":4465,"_type":17,"title":4466,"_source":18,"_file":4467,"_stem":4468,"_extension":21},"/en-us/blog/fearless-contribution-a-guide-for-first-timers",{"title":4453,"description":4454,"ogTitle":4453,"ogDescription":4454,"noIndex":6,"ogImage":4455,"ogUrl":4456,"ogSiteName":667,"ogType":668,"canonicalUrls":4456,"schema":4457},"Fearless Contribution: A Guide for First-Timers","First time contributions can be scary. If you're worried your skills are not up to par, you're not alone.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672230/Blog/Hero%20Images/fearless-contribution-a-guide-for-first-timers.jpg","https://about.gitlab.com/blog/fearless-contribution-a-guide-for-first-timers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Fearless Contribution: A Guide for First-Timers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Drew Blessing\"}],\n        \"datePublished\": \"2016-06-16\",\n      }",{"title":4453,"description":4454,"authors":4459,"heroImage":4455,"date":4461,"body":4462,"category":14},[4460],"Drew Blessing","2016-06-16","\n\n> This post is part of a series [Celebrating 1,000 Contributors][1k-post]\n\nThere are clear benefits to contributing to open-source projects. For starters,\nyou'll solve your own problems more quickly and you will have a positive effect\non your favorite projects.\n\nHowever, the barrier to entry can be high for first-time contributors. Perhaps\nyou feel your coding skills are not up to par, or maybe you aren't a programmer\nat all. When you do approach a project, you may find the contribution guidelines\nare unclear, the maintainers are unresponsive, or you may disagree over\npriorities.\n\nI'll give you some practical advice on overcoming these hurdles. We'll also\nlook at the ways GitLab tries to make contributing easier in our own project.\n\n\u003C!-- more -->\n\n## Ways to contribute\n\nFirst time contributions can be scary. If you're worried your skills are not\nup to par, you're not alone. Many new and seasoned people in the technology\nfield feel this way at one point or another. The best way to overcome this\nfeeling is to jump in *somewhere*. No matter how large or small the\ncontribution, you will gain confidence and feel more comfortable each time.\n\nSome may believe that the only way to contribute to an open-source project is\nby writing code - fixing bugs or contributing new features. In reality, there\nare more ways to contribute.\n\n### Documentation\n\nAs you were learning to use the application or tool, did you notice gaps in the\ndocumentation? This is a great way to start contributing to a project. If you\nexperienced and overcame a challenge because the documentation was lacking,\nit's an opportunity to get involved and help others.\n\nMany projects commit documentation in the same repository as the code. For\nexample, GitLab stores all documentation in the `doc` directory within a\nproject. For GitLab CE, you can see documentation source at\n[https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc).\nIf you don't find documentation in repository then you may find a hint on the\ndoc site. Look for a link near the bottom of the page that points to the source.\nOn [https://docs.gitlab.com](https://docs.gitlab.com) we have a link at the\nbottom of each page pointing to a specific source document. Here is an example\nof the doc site footer:\n\n---\n\n![Doc site footer](https://about.gitlab.com/images/first_time_contribution/doc_site_footer.png)\n\n---\n\n### Issue Tracker\n\nGet involved in the project's issue tracker. To begin with, you may only create\nbug reports for issues you encounter. As you become more comfortable, consider\ntriaging other bug reports.\n\nStart by picking an existing issue and try to reproduce the problem in your own\nsystem. If you can reproduce it, outline the steps as a comment on the issue.\nThis will save developer's time when they come to fix the bug later. If you\ncannot reproduce the issue, ask the reporter for more information. Triaging\nissues has a side-effect of helping you learn more about the project. This will\ncome in handy as you contribute documentation and/or code in the future.\n\n### Bug Fixes and New Features\n\nIf you can write code, consider contributing bug fixes and, eventually, new\nfeatures. Chances are you've encountered a bug or two in the course of using\na project. Contribute a fix for one of these bugs first. It's\nrewarding when you solve one of your own problems and see the change accepted.\n\nSome projects may have labels to help direct you to easier bug fixes. For\nexample, GitLab projects contain an `up-for-grabs` label that signifies a\nbug that newer contributors may be able to solve. Beyond that, browse the\nissue tracker for an interesting problem that you believe you can fix.\n\n## Contribution Guidelines\n\nMany open-source projects have defined guidelines that contributors\nare expected to adhere to when submitting issue reports or merge requests. These\nguidelines are meant to reduce the amount of time the maintainers spend\nrepeatedly asking for required details or changes to code style.\n\nBefore creating an issue report or merge request, look for a CONTRIBUTING.md\nfile in the root of the repository. To make finding this guide easier, GitLab\nhas a link to 'Contribution guide' on project home pages if there is a\nCONTRIBUTING.md in the repository.\n\n![GitLab Project Page](https://about.gitlab.com/images/first_time_contribution/project_page.png)\n\nAdhering to the guidelines is a great way to prevent your contributions from\nbeing rejected or delayed. Most maintainers don't intend to discredit your\nwork or be tough on contributors. However, many are busy and are doing this\nin their free time.\n\nScan the [GitLab Community Edition Contribution Guide][contrib-guide]\nto see how we handle community contributions. Notice our requirements for\nmerge request descriptions. There are five headines that we request so we have\nall the information we need to understand the purpose of the proposed change.\n\n```\n## What does this MR do?\n\n## Are there points in the code the reviewer needs to double check?\n\n## Why was this MR needed?\n\n## What are the relevant issue numbers?\n\n## Screenshots (if relevant)\n```\n\n## Conflicting priorities\n\nSometimes a request will be turned down because of conflicting priorities.\nWhether you're requesting a new feature, or providing a fix, remember that the\nmaintainer has to weigh the contribution. They're the ones that will have to\nsupport this code in the future and resources are often slim. Additionally,\nit's important to understand whether a feature will be helpful to the wider\nuser community. Try not to be discouraged if your feature request or merge\nrequest is turned down. Be open-minded and, if necessary, propose\nan alternative idea after hearing their concerns.\n\n## Unresponsive maintainers\n\nThis can be a really frustrating part of open-source. When you're experiencing\na bug or waiting on some functionality for your use-case, a lack of response\ncan be maddening. Remember that some project maintainers are working on projects\nin their spare time and aren't paid to do this. In some cases, projects may be\nabandoned because the maintainer no longer has the need or interest.\n\nThere aren't always good ways to deal with this scenario. Interested and\nexperienced people may offer to take over maintainership, or the project could\nbe forked. Often, though, patience is key.\n\n## Start a project\n\nAs you become more experienced, consider starting a small project that is\na command line tool or utility. Choose something that will be useful in\nyour daily tasks so you will be motivated. Don't necessarily be concerned about\ncompeting projects to begin with. The ultimate goal of this endeavor is to\nlearn.\n\nAs an example, 3 years ago I thought it would be useful to have a command line\ntool for GitLab. I really wanted to be able to create a snippet by piping\nsome text to a command. Up until this point I had written very little Ruby\nbut I tried it anyway. I learned a lot about Ruby, how to organize a project,\nand I used this tool successfully for quite a while. I no longer maintain this\nproject but I'm still happy I created it. For sentimental purposes, you can see\nthe code at https://github.com/drewblessing/gitlab-cli.\n\n## Get involved in GitLab!\n\nWe always welcome new contributors to the GitLab community so jump right in and\nwork on one of the areas mentioned above. If you can write code, we recently\npublished a blog post about [Getting Started with GitLab Development Kit][gdk-post].\nThere are also community-based support channels that are great places to get\ninvolved. See the [Getting Help][getting-help] section of our website for links\nto these channels.\n\n## Final Thoughts\n\nI find being part of an open-source community to be a fun and rewarding\nexperience. In almost every project I've been involved with I started out\nknowing next to nothing about the project, or programming language. Start small\nand don't underestimate your skills. Over time you will learn a lot through\nyour involvement and you'll become more confident.\n\n[1k-post]: /2016/05/24/1k-contributors/\n[gdk-post]: /2016/06/08/getting-started-with-gitlab-development-kit/\n[getting-help]: /get-help/\n[contrib-guide]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md\n",{"slug":4464,"featured":6,"template":681},"fearless-contribution-a-guide-for-first-timers","content:en-us:blog:fearless-contribution-a-guide-for-first-timers.yml","Fearless Contribution A Guide For First Timers","en-us/blog/fearless-contribution-a-guide-for-first-timers.yml","en-us/blog/fearless-contribution-a-guide-for-first-timers",{"_path":4470,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4471,"content":4477,"config":4481,"_id":4483,"_type":17,"title":4484,"_source":18,"_file":4485,"_stem":4486,"_extension":21},"/en-us/blog/customer-story-charge-communications",{"title":4472,"description":4473,"ogTitle":4472,"ogDescription":4473,"noIndex":6,"ogImage":4474,"ogUrl":4475,"ogSiteName":667,"ogType":668,"canonicalUrls":4475,"schema":4476},"Customer Story: Charge","In this post we will share how Charge, a telecommunications company uses GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684736/Blog/Hero%20Images/person-on-phone.jpg","https://about.gitlab.com/blog/customer-story-charge-communications","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Customer Story: Charge\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-05-31\",\n      }",{"title":4472,"description":4473,"authors":4478,"heroImage":4474,"date":4479,"body":4480,"category":14},[762],"2016-05-31","\n\nWe always like to hear how our customers are using GitLab. In this post we will share how [Charge](https://charge.co/), \na telecommunications company uses GitLab. \n\n\u003C!-- more -->\n\n- **Industry:** Data-only telecommunications\n- **Company Size:** 5\n- **Development Team:** 5\n- **Location:** San Francisco\n\n## Overview\n\nCharge, the San Francisco-based startup, is looking to change the way we pay for our phone \nservice. They offer simple pay-as-you-go plans for data, text, and calls on LTE devices. Charge \nruns lean with a small team of five. This mighty team of five is working on a solution to rival the telecommunications giants. \nTheir mission to provide simple mobile phone service that puts consumers in control is no small undertaking. \nWith their ambitious goal in mind, they quickly realized that their team couldn’t afford any missteps.\n\n![](https://about.gitlab.com/images/blogimages/Charge-customer-story/person-on-phone-2.jpg)\n\nCharge needed to find a distributed version control solution that would help improve their engineering workflow, speed up \ntheir development process, and withstand industry security requirements. After looking into a number \nof different tools across the market, the team decided that GitLab Community Edition was the \nbest solution for their needs. Since Charge migrated to GitLab they have already \nseen decreased development times and increased confidence in the code they’re deploying.  \n\n## Looking for a secure alternative\n\nBefore GitLab, Charge was using raw git with git+ssh for access. They didn’t have a web interface for repo management \nor code review. Feeling like they had the opportunity to drastically improve their engineering workflow, \nthe Charge team decided to look for a product to support their 25 repositories and 5 developers. However, \nthe team could not go with just any solution. They needed one with a specific set of features that would \nalign with their strict industry regulations.\n\nCharge’s CTO, Chris Goddard, explains: \"When working with telecom carriers like we do, there are legal \nrequirements concerning customer information (called CPI) and the software that interacts with customer \ninformation that we must adhere to.” The need to keep customer information secure is one of the primary \nreasons that Chris considered GitLab’s self-managed Community Edition. Chris added, \"privacy is very important \nto us generally. And we like to be in control of the software that we use for system-critical work. Being able \nto self-host things that store important company secrets is paramount, which is why we love GitLab!\" \n\n## Decreased deployment time and increased confidence\n\nGitLab is currently Charge's sole code review tool, hosting all of their 25 internal git repositories. \nThe team runs GitLab using an on-host database (Postgres), with daily backups. Charge uses \nGoogle OAuth integration, a feature that was crucial to the team when they were searching for \nthe right software for their needs. The five-strong development team also use both webhooks \nand git hooks for integration with their build server. \n\nFor Chris, Charge’s CTO, GitLab has been an amazing revelation to the team’s engineering workflow. \nChris comments on the positive changes that he and the team have witnessed, stating that they are \nextremely pleased with their new code review process. He continues: \"But the biggest change was in deployment time. \nGitLab allowed us to easily integrate with our build server and automate deployments. Before, deployment \nwas an hour-long disaster-prone mess. After, we've got it down to a couple minutes and can deploy with confidence.\"\n\n## Conclusion\n\nGitLab Community Edition is enabling Charge to meet their goal of simplifying data for mobile devices. \nGitLab is helping Charge to take on large telecommunications providers by offering a secure and consumer-friendly\npay-as-you-go model. Thanks to GitLab CE, Charge is experiencing an improved engineering workflow with dramatically faster \ndeployment time and adherence to strict industry security requirements.  \n\n## Tell us your story\n\nIs your team using Gitlab? We’d love to hear from you.\nEmail us at community@gitlab.com if you’re interested in sharing.\n",{"slug":4482,"featured":6,"template":681},"customer-story-charge-communications","content:en-us:blog:customer-story-charge-communications.yml","Customer Story Charge Communications","en-us/blog/customer-story-charge-communications.yml","en-us/blog/customer-story-charge-communications",{"_path":4488,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4489,"content":4494,"config":4499,"_id":4501,"_type":17,"title":4502,"_source":18,"_file":4503,"_stem":4504,"_extension":21},"/en-us/blog/feature-highlight-push-to-remote-repository",{"title":4490,"description":4491,"ogTitle":4490,"ogDescription":4491,"noIndex":6,"ogImage":947,"ogUrl":4492,"ogSiteName":667,"ogType":668,"canonicalUrls":4492,"schema":4493},"Feature highlight: Push to a remote repository","In GitLab 8.7 we introduced the second part of the mirroring functionality: the ability to push changes to an external repository from GitLab.","https://about.gitlab.com/blog/feature-highlight-push-to-remote-repository","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature highlight: Push to a remote repository\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ivan Nemytchenko\"}],\n        \"datePublished\": \"2016-05-10\",\n      }",{"title":4490,"description":4491,"authors":4495,"heroImage":947,"date":4497,"body":4498,"category":14},[4496],"Ivan Nemytchenko","2016-05-10","\n\nSince [GitLab Enterprise](/enterprise/) Edition 8.2 you could sync all changes from a remote repository to one on GitLab.\n\nIn GitLab 8.7 we introduced the second part of the mirroring functionality: the ability to push changes to an external repository from GitLab.\n\nThis means that now you can use GitLab as the main place for your development, and get all your changes pushed to another repository.\nThere are a number of reasons why it may be important to keep an existing repository in addition to your new GitLab repository:\n\n- You can be tied with company policy to keep using the legacy system\n- You want your existing git hosting service to keep playing the role of showcasing your project\n- You don't want to spend time reconfiguring all your existing integrations\n\nIn any of these cases \"Push to remote repository\" might be your savior.\n\n## Setting up\n\nIt can be configured in **Settings** → **Mirror Repository**:\n\n![Settings: Push to a remote repository](https://about.gitlab.com/images/blogimages/push-to-remote-repository/settings.png)\n\nIt will be pushed every hour. You can also trigger it manually right from the project page:\n\n![Trigger push to a remote repository](https://about.gitlab.com/images/blogimages/push-to-remote-repository/trigger.png)\n\n## Playing with mirroring functionality\n\nAs an experiment, I built a chain of 3 repositories: [Bitbucket](https://bitbucket.org/ivannemytchenko/sync) → [GitLab](https://gitlab.com/inem/sync) → [GitHub](https://github.com/inem/sync).\n\nEvery change from the Bitbucket repository goes to GitLab, triggers build there (since I checked \"Trigger builds for mirror updates\" checkbox). Then all the changes are pushed to the repository at GitHub.\n\n![Checkbox](https://about.gitlab.com/images/blogimages/push-to-remote-repository/checkbox.png)\n\nAs you can see, mirroring gives you an additional dimension of flexibility. You can use it to modify an existing workflow, or to build one from scratch.\n\n\"Push to remote repository\" is a feature of GitLab Enterprise Edition (EE), which means that you can use it on your own GitLab EE instance or for free at GitLab.com.\nGitLab.com is the free SaaS version of GitLab, running most of the features of GitLab EE.\n",{"slug":4500,"featured":6,"template":681},"feature-highlight-push-to-remote-repository","content:en-us:blog:feature-highlight-push-to-remote-repository.yml","Feature Highlight Push To Remote Repository","en-us/blog/feature-highlight-push-to-remote-repository.yml","en-us/blog/feature-highlight-push-to-remote-repository",{"_path":4506,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4507,"content":4513,"config":4518,"_id":4520,"_type":17,"title":4521,"_source":18,"_file":4522,"_stem":4523,"_extension":21},"/en-us/blog/feature-highlight-move-issues",{"title":4508,"description":4509,"ogTitle":4508,"ogDescription":4509,"noIndex":6,"ogImage":4510,"ogUrl":4511,"ogSiteName":667,"ogType":668,"canonicalUrls":4511,"schema":4512},"Feature highlight: Move issues between projects","In GitLab 8.6 we added a feature allowing you to move issues between projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684674/Blog/Hero%20Images/truck.jpg","https://about.gitlab.com/blog/feature-highlight-move-issues","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature highlight: Move issues between projects\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Grzegorz Bizon\"}],\n        \"datePublished\": \"2016-04-20\",\n      }",{"title":4508,"description":4509,"authors":4514,"heroImage":4510,"date":4516,"body":4517,"category":14},[4515],"Grzegorz Bizon","2016-04-20","\n\n\nIn [8.6][releasepost] we added a feature allowing you to move issues between projects.\n\nIf you work on multiple projects, it's possible to accidentally create an issue\nin the wrong issue tracker. It's a seemingly simple mistake that is easy to miss.\nLet's say you don't catch it right away and you do a decent amount of work\non the wrong project. Now, your \"seemingly simple\" mistake just became a bigger one.\nWe've all been in this position before. With our 8.6 release, we want to avoid the\npanic that can come from creating an issue in the wrong project. Now, if you\ncreate an issue in the wrong project, you can easily move it to the right one.\n\n\u003C!-- more -->\n\n![Move issues between projects](https://about.gitlab.com/images/8_6/move-issue.png)\n\nWhen you move the issue, the original issue will be copied, closed, and then referenced.\nThis process makes sure nothing is lost in the move.\n\nAdditionally, anyone who is subscribed to the issue will get a notification that the\nissue was moved, with a link to the new location. This will, of course,\ndepend on your notification settings.\n\n![Moved issue email](https://about.gitlab.com/images/blogimages/moved-issue-email.png)\n\nIt's a relatively simple feature, but it was\n[tricky to implement][Merge request !2831].\n\n## Behind the scenes: Moving issues between projects\n\nAt first, moving issue between projects seemed like an easy task. However,\nwe encountered a tricky problem with references in the issue description or\ncomments.\n\nSuppose we have a project called Alice, and we created an issue inside it:\n\n```markdown\nHey, this issue is related to #123 and the solution is implemented in !456.\n```\n\nNow let's suppose we want to move this issue to Bob. The reference #123 points\nto an issue in Alice. Similarly, !456 points to a merge request in Alice as well.\nIf a user moves an issue to Bob, these references need to be updated so that they\ncontinue pointing to Alice, not Bob. Otherwise, the resulting references would\nlink to the wrong project. The same goes for snippets, labels, commits, etc.\n\nWe knew that we needed to fix these references by using GitLab's Markdown\ncross-project reference notation. However, at the time, not everything in GitLab\nsupported this notation. For example, labels (e.g. `~\"My Label\"`) could not be\nshared across projects. We had to fix that, so we did via [Merge request !2996].\n\n\nAnother step was simply substituting `#123` with `gitlab-org/gitlab-ce#123`.\nBut it is possible you could have text like this:\n\n```markdown\nHi, this is a duplicate of http://gitlab.com/gitlab-org/gitlab-ce/issues/123.\nAlso see documentation docs.gitlab.com/ee/some-page#123. Also take a look at this code:\n\n    puts 'some code' #123 is a comment\n```\n\nSo we know that this description holds a reference to issue 123 but we do not\nknow *where it is*, or how to substitute it in the right place. We needed to modify\nthe source text. However, changing the source text would interfere with Markdown.\nTo solve this, I tried some prototypes but couldn't find a better solution than\nwriting yet another parser for Markdown that would support the full Abstract\nSyntax Tree of Markdown. This would add support for mutable nodes in a tree,\nallowing us to modify text where needed.\n\nHowever, once I started this work, I felt that this was a complicated solution so\nI decided to look for a [boring solution][values]. I reached out to my fellow\ndevelopers on the team to find a better boring solution. After sometime,\n[Kamil] helped me and we came with different solution.\n\nWe decided to use existing mechanisms to verify if we can substitute reference\nin place it has been detected at. We knew that resulting HTML should not change,\nso we could try substituting local reference with cross-project variation and\nsee if generated HTML is different than the original one. If it didn't change,\nthen substitution is valid.\n\nBelow you can find some implementation details of current solution.\n\n1.  Match all local references to project, issue, merge request and all other\n    entities using Regexp.\n\n    References like `#123` for issue, `!456` for merge request are being\n    matched.\n\n1.  Substitute each subsequent match with fully-expanded cross-project\n    reference.\n\n    This substitutes reference like `#123` with `gitlab-org/gitlab-ce#123`.\n\n1.  For each substitution generate HTML twice, using a new content and using an\n    old content.\n\n    Because of the fact that cross-project reference, when used in a context\n    of the project it refers to is rendered as a local reference, both resulting\n    HTMLs should be the same.\n\n1.  If resulting HTMLs are the same, we permanently alter original text to\n    contain cross-project reference instead of local reference.\n\nThis solution is not the most optimal one because of performance reasons, but\nit allowed us to ship this feature quickly and in the future we can improve it\nby using Abstract Syntax Tree implementation for Markdown.\n\nWith this approach, we are also sure that modifications to issue/comments\ncontent are correct and don't break your issue which can hold valuable\ninformation.\n\n[Kamil]: https://twitter.com/ayufanpl\n[Merge request !2831]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2831\n[values]: https://handbook.gitlab.com/handbook/values/\n[releasepost]: /releases/2016/03/22/gitlab-8-6-released/\n[Merge request !2996]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2966\n",{"slug":4519,"featured":6,"template":681},"feature-highlight-move-issues","content:en-us:blog:feature-highlight-move-issues.yml","Feature Highlight Move Issues","en-us/blog/feature-highlight-move-issues.yml","en-us/blog/feature-highlight-move-issues",{"_path":4525,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4526,"content":4532,"config":4537,"_id":4539,"_type":17,"title":4540,"_source":18,"_file":4541,"_stem":4542,"_extension":21},"/en-us/blog/feature-highlight-subscribe-to-label",{"title":4527,"description":4528,"ogTitle":4527,"ogDescription":4528,"noIndex":6,"ogImage":4529,"ogUrl":4530,"ogSiteName":667,"ogType":668,"canonicalUrls":4530,"schema":4531},"Feature Highlight: Subscribe to Label","In GitLab 8.6 and up, you can subscribe to a label. Whenever an issue is tagged with the label you subscribed to, you will get a notification.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684195/Blog/Hero%20Images/ios-development.jpg","https://about.gitlab.com/blog/feature-highlight-subscribe-to-label","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature Highlight: Subscribe to Label\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2016-04-13\",\n      }",{"title":4527,"description":4528,"authors":4533,"heroImage":4529,"date":4535,"body":4536,"category":14},[4534],"Job van der Voort","2016-04-13","\n\nIn active projects, it can be hard to keep track of issues that are important to you.\nFor example, a project like GitLab has thousands of issues, but you might only\nbe interested in those related to *performance*.\n\nYou can already mention people in GitLab by using someone's @-handle, but as\nmore people join a project, it becomes harder to keep track of who is interested in what.\n\nTo solve this, in GitLab 8.6 and up, you can subscribe to a label.\nWhenever an issue is tagged with the label you subscribed to, you will get\na notification. This is irrespective of your notification level to the project.\n\n\u003C!-- more -->\n\n## How to Subscribe to a Label\n\nTo subscribe to a label, visit the labels in your project and click on subscribe\nfor any of the labels.\n\n![Subscribe to Label](https://about.gitlab.com/images/blogimages/gitlab-subscribe-labels.png)\n\nYou will now get a notification whenever any issues or merge requests get\ntagged with this label.\n\n## At GitLab\n\n[Yorick](https://twitter.com/Yorickpeterse), resident performance expert at\nGitLab, is subscribed to the performance\nlabel. This allows him to cut through the noise of the thousands of issues\ncreated in the various GitLab projects and focus on anything related to\nperformance.\n\nEveryone on the team does their best to tag issues with a relevant label.\nWhenever someone adds the `performance` label to an issue, Yorick immediately\ngets a notification, without having to watch Issues closely.\n\nHaving recently joined GitLab, Amara Nwaigwe immediately started using the\nSubscribe to Label feature. She says:\n\n> \"I subscribe to various labels because they relate to things I would like to\nknow. I want to maintain a level of visibility of things that are relevant to\nme\"\n\nWe hope you like this feature!\n\n## What's coming next?\n\nIf you're curious what is coming next in GitLab, you can always visit our\n[Direction](/direction/) page for insight into our\nroadmap. We always love your feedback.\n",{"slug":4538,"featured":6,"template":681},"feature-highlight-subscribe-to-label","content:en-us:blog:feature-highlight-subscribe-to-label.yml","Feature Highlight Subscribe To Label","en-us/blog/feature-highlight-subscribe-to-label.yml","en-us/blog/feature-highlight-subscribe-to-label",{"_path":4544,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4545,"content":4551,"config":4555,"_id":4557,"_type":17,"title":4558,"_source":18,"_file":4559,"_stem":4560,"_extension":21},"/en-us/blog/stack-overflow-support-network",{"title":4546,"description":4547,"ogTitle":4546,"ogDescription":4547,"noIndex":6,"ogImage":4548,"ogUrl":4549,"ogSiteName":667,"ogType":668,"canonicalUrls":4549,"schema":4550},"Customer Story: Stack Overflow","In this post we'll look at how Stack Overflow uses GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684759/Blog/Hero%20Images/stack.jpg","https://about.gitlab.com/blog/stack-overflow-support-network","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Customer Story: Stack Overflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-04-07\",\n      }",{"title":4546,"description":4547,"authors":4552,"heroImage":4548,"date":4553,"body":4554,"category":14},[762],"2016-04-07","\n\nIn this post we'll look at how [Stack Overflow] uses GitLab.\n\n\u003C!-- more -->\n\n- **Industry:** Support network for programming community\n- **Company Size:** 254\n- **Development Team:** 30\n- **Location:** Global. Stack Overflow HQ is in New York, but most developers\nwork remotely.\n\n## Background Info\n\n[Stack Overflow] is a question and answer site run by and for programmers.\nIt is part of the Stack Exchange network of Q&A sites.\nUnlike discussion forums, this platform is all about getting answers.\nThe concept is simple: good answers get up-voted by the community and rise to\nthe top so they can be easily viewed. Users who receive positive feedback\nreceive privileges including the ability to vote, comment on, and edit posts.\n\nAll questions get tagged with their subject areas. Users can click on the tag\nlist to see if their question has already been asked by a member of the community.\nOver time, users are building a library of detailed answers to programming questions.\n\n## Getting It Right\n\nWhen the team of developers at Stack Overflow set up their service for\nprogrammers, they knew they had to get the right source control solution.\nGet it right, and users would flock to the support resource; get it wrong, and\nthe response wouldn’t be so positive.\n\nStack Overflow senior developer Geoff Dalgas explains that when the team was\nlooking around for the best possible solution, it became clear that GitLab fit\nthe bill. Their initial choices of Git-web and Kiln were superseded by the\ncontinued development and improvements in performance offered by GitLab.\n\nStack Overflow adopted GitLab as their primary source control. It is used\non-premises and is currently self-managed. They have opted to use a self-hosted\nchat system, as none of their preferences are integrating with GitLab at present.\nAs basic GitLab users, the platform does not use the integrated CI into GitLab\n– they have opted for Team City.\n\nAs a Q&A network that is itself constantly growing and developing, it is\nessential that it has a solution on board that enables its users to build a\nlibrary of detailed, trustworthy answers to the questions posed by professional\nand amateur programmers. When asked to describe the special considerations for\nsoftware that the Stack Overflow development team must consider, Geoff Dalgas\nanswers succinctly: “Maintenance, reliability, and maintainability.”\n\n## Being Part of On-Going Developments\n\nGiven that fit, function and speed are essential for the programming industry,\nGitLab has become ingrained in the Stack Overflow culture. As early adopters,\nGeoff’s team has been part of the ongoing developments of GitLab.\nHe describes the increased development time, quicker code review and easier\ncollaboration as being the main changes that he has witnessed.\n\nAs active contributors to open source, Geoff and his colleagues have also seen\nan increase in the use of merge requests.\n\nThe developers at Stack Overflow use [LDAP integration](http://doc.gitlab.com/ee/integration/ldap.html#gitlab-ldap-integration).\nThe team have recently made the decision to implement [GitLab Geo](/releases/2016/02/22/gitlab-8-5-released/).\nThey are hoping that it could be a solution to their multi datacenter\nreplication, but Geoff reports that analysis is ongoing and it’s too soon to\ntell for sure. His colleagues feel that an improved search experience would be\na huge benefit to their work.\n\n## Tell us your story\n\nIs your team using Gitlab? We’d love to hear from you.\nEmail us at community@gitlab.com if you’re interested in sharing.\n\n[Stack Overflow]: https://stackoverflow.com/\n",{"slug":4556,"featured":6,"template":681},"stack-overflow-support-network","content:en-us:blog:stack-overflow-support-network.yml","Stack Overflow Support Network","en-us/blog/stack-overflow-support-network.yml","en-us/blog/stack-overflow-support-network",{"_path":4562,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4563,"content":4569,"config":4573,"_id":4575,"_type":17,"title":4576,"_source":18,"_file":4577,"_stem":4578,"_extension":21},"/en-us/blog/git-contributors-summit",{"title":4564,"description":4565,"ogTitle":4564,"ogDescription":4565,"noIndex":6,"ogImage":4566,"ogUrl":4567,"ogSiteName":667,"ogType":668,"canonicalUrls":4567,"schema":4568},"Notes from the Git Merge Core Contributors Summit","Sytse, Job and Marin attended to represent GitLab and learn more about what is happening in the core Git community. Here are our notes and impressions from this event.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684654/Blog/Hero%20Images/notes.jpg","https://about.gitlab.com/blog/git-contributors-summit","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Notes from the Git Merge Core Contributors Summit\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-04-06\",\n      }",{"title":4564,"description":4565,"authors":4570,"heroImage":4566,"date":4571,"body":4572,"category":14},[762],"2016-04-06","\n\nAt GitLab, we’re really proud to support the open source projects which underpin\nour service. Obviously, Git is a main part of absolutely everything we do.\nWe recently sponsored [Git Merge](http://git-merge.com/#sponsors), an event\norganized by GitHub and sponsored by Atlassian, Bloomberg, Compose, SAP, and of\ncourse, GitLab. Even competitive organizations must work together to improve\nupon and negotiate the direction of key open source software.\nOn the day before [Git Merge](http://www.git-merge.com), we joined the Git Merge\nCore Contributors Summit to discuss the direction of the project and new\ndevelopments.\n\n[Sytse](https://twitter.com/sytses), [Job](https://twitter.com/jobvo) and [Marin](https://twitter.com/maxlazio)\nattended to represent GitLab and learn more about what is happening in the core\nGit community. Here are our notes and impressions from this event.\n\n\u003C!--more-->\n\n![Git Core Contributor Summit - 2016 Git Merge](https://about.gitlab.com/images/blogimages/git-core-contrib-summit-2016-marin.jpg)\n\nPhoto by [Marin Jankovski](https://twitter.com/maxlazio)\n\n## Scaling Git  \n\nGit is growing in popularity, and projects are growing in size and complexity\nas larger organizations adopt Git. This has lead to efforts in improving Git\nperformance. Twitter reported an example repo with: 1m commits,\n1500 contributors, and 0.25m files. The main problem is, the checkout is slow.\nBooking.com reported an example repo which took 500ms to read all the references.  \n\nOne way to improve this is [Repacking](https://www.kernel.org/pub/software/scm/git/docs/git-repack.html)\nwhich greatly helps with performance.\n\n## Growing Git Adoption  \n\nAs Git expands into organizations and different types of projects, Git is being\nused by people who are less familiar with the command line. Having web based\ninterfaces, like GitLab, which allow users to perform Git commands through the\nweb UI is helping organizations adopt Git.  \n\n## Protecting the Git trademark  \n\nGit is a member of the [Software Freedom Conservancy](http://sfconservancy.org/)\nwhich helps to protect and defend free software. Taking care of software\ntrademarks for open source projects is important to protect the software and\nits users. The official Git website has guidelines about\n[trademark](https://git-scm.com/trademark) use which can help to prevent any\nmisuse of the trademark which could misguide users. Git project maintainers\nwill be making the decisions about which projects can make use of the Git trademark.  \n\nAs Git proliferates and grows, there would be attempts to misuse or mislead\nusers seeking Git related services and could be coerced into paying for free\nsoftware or using software which isn’t actually Git. Protecting the Git\ntrademark is work which requires more financial support to be sustainable.\n[Software Freedom Conservancy](http://sfconservancy.org/donate/) is seeking\nmore support.  \n\n## Diversity  \n\nDiversity was discussed at the event. Our team noted that all attendees were men,\nincluding those from our team. It was an unfortunate realization and one which\nhas inspired us to take action. We will continue to focus efforts on our own\n[diversity sponsorship program](/community/sponsorship/).\nWe also aim to support events in areas with\nlow-opportunity, to increase global diversity in technology.\n\nGreat projects which need more support:  \n\n- [Gnome’s Outreachy](https://www.gnome.org/outreachy/) supports interns.  \n- [GSOC](https://developers.google.com/open-source/gsoc/) - Google Summer of Code internships  \n\n\n## Submit Git - patches by email\n\nSubmit Git is a Scala app which is used to bridge between GitHub and the Git\nmailing list. Using Submit Git allows the Git mailing list to continue to use a\npatch submission process through a web UI. Users make a pull request on GitHub,\nand this lets you preview the patch and submit it to the mailing list.\nOf 40 contributors in the last year, 15 have been using it during this beta\nperiod. Soon, there will be updates to documentation to explain how to use\nSubmit Git to submit patches to Git, and pull requests will no longer be\naccepted. There will be an automatic notification when people attempt to open\npull requests on the [Git project](https://github.com/rtyley/submitgit).  \n\n## Submodules\n\nIt sounds like there may be improvements to submodules in Git.\nGoogle engineers expressed an interest in making\nthis better, such as with improvements to both the UI and initialization.\nThey are also interested in working to improve speed with parallel downloads.\nWhen this works, perhaps it could replace the Android repository tool called\n[Repo](https://source.android.com/source/developing.html)?\nWe look forward to seeing what happens next.\n\n\nWe'd like to thank [Peff](https://github.com/peff) for including us in the Git\nMerge Core Contributors Summit. We look forward to the next one!  \n\nPlease leave your opinions in the comments. We'd love to hear your thoughts.\n",{"slug":4574,"featured":6,"template":681},"git-contributors-summit","content:en-us:blog:git-contributors-summit.yml","Git Contributors Summit","en-us/blog/git-contributors-summit.yml","en-us/blog/git-contributors-summit",{"_path":4580,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4581,"content":4587,"config":4592,"_id":4594,"_type":17,"title":4595,"_source":18,"_file":4596,"_stem":4597,"_extension":21},"/en-us/blog/feature-highlihght-confidential-issues",{"title":4582,"description":4583,"ogTitle":4582,"ogDescription":4583,"noIndex":6,"ogImage":4584,"ogUrl":4585,"ogSiteName":667,"ogType":668,"canonicalUrls":4585,"schema":4586},"Feature Highlight: Confidential issues","Since GitLab 8.6, in both Community and Enterprise edition, there is a small checkbox available when you create or edit an issue, allowing you to mark an issue as confidential.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684753/Blog/Hero%20Images/door.jpg","https://about.gitlab.com/blog/feature-highlihght-confidential-issues","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature Highlight: Confidential issues\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Douglas Alexandre\"}],\n        \"datePublished\": \"2016-03-31\",\n      }",{"title":4582,"description":4583,"authors":4588,"heroImage":4584,"date":4590,"body":4591,"category":14},[4589],"Douglas Alexandre","2016-03-31","\n\nSince GitLab 8.6, in both Community and Enterprise edition, there is a small\ncheckbox available when you create or edit an issue, allowing you to mark an\nissue as confidential.\n\nIn some ways it’s a simple feature, but there are complex considerations.\nThe main point is to keep the confidential issues secure.\nHowever, taking care of those considerations caused some problems during\ndevelopment which are typical when you develop a feature for a relatively\nlong time (in this case two weeks). We'll look at that in this feature highlight.\n\n\u003C!-- more -->\n\n## About Confidential Issues\n\nIn the course of maintaining a project, it may be necessary to keep some\ninformation from public view. A typical use case for confidential issues would\nbe a security report. Different projects support different ways to report\nsecurity issues, so if someone needed to report a security issue, they would\nhave to:\n\n- Follow the instructions for security vulnerabilities, if there are any.\n- File an issue with their findings and a request to get in contact with the\n  project maintainer.\n- Find other means to contact the maintainer.\n\nIn general, most of the projects advise to not use the issue tracker, and\ninstead send an email to a specific email address. As you might imagine before\nthis release we, as an open source project, advised the same\n[security vulnerability disclosure][disclosure] in our contributing guide:\n\n> Please report suspected security vulnerabilities in private to\nsupport@gitlab.com, also see the disclosure section on the GitLab.com website.\nPlease do NOT create publicly viewable issues for suspected security\nvulnerabilities.\n\nThis generated a lot of overhead.\n\nBehind the scenes, when we got a security report email, we would immediately\ncreate an issue in our internal issue tracker to discuss possible fixes. So in\nthat case, we needed to keep in track two issues trackers: a public one on\nGitLab.com and another private. In addition, the process to report a security\nissue would be more complex than it is now. First, you need to discover how to\nreport the issue, and then report the issue itself.\n\nNow, with Confidential Issues, the reporter can mark an issue as confidential\nwhen creating or editing an issue, and only project members can see the issue,\nas well as those who are assigned to it. As it turns out, the process is\nconsiderably easier, since reporters don't need to find how to report security\nissues anymore, and we don't need to work on two different issue trackers for\nthe vulnerability disclosures.\n\nWhen an issue is marked as confidential, it is only visible to the team members.\nIt will be hidden from the public view, which means the issue tracker, the\nactivity feed, the milestone views, the auto-complete options, etc. Even if you\nget a `@mention`, and you don’t have explicit access to the project, you won't\nreceive any kind of notification (in this case emails, and todos).\n\n## Behind the scenes: Resolving merge conflicts as you go\n\nWhile this is a simple feature, it created an interesting problem, and I'm not\ntalking code-wise.\n\nBecause it causes lots of concern about security, we needed to very careful\nwith this. I had the branch open for a relatively long time (about two weeks),\nand over time, I was running into merge conflicts almost daily. My work was\naffected by other features being developed at the same time, for example\nsubscribe to labels. This happens very often if you have a merge request open\nfor a long time.\n\nI do try and avoid this when I can. I check everyday if my merge request has\nconflicts and I resolve these as I work, that is, instead of waiting until\nthe final release to merge.\n\nIt also helps a lot to do development with automated tests. As you work in\nparallel with other developers and constantly update the feature, you can tell\nif something is going to break.\n\nNormally, you don’t work a long time on issues like this but in this case it\nwas unavoidable due to the security nature of the feature. Again, using tests\nmade this a lot easier.\n\n## More about GitLab 8.6\n\nThis *confidential issues* feature is just one of the many recent changes in GitLab.\nFind out more [about our latest release, 8.6][release] with new improvements\nand features.\n\n\n[disclosure]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#security-vulnerability-disclosure\n[release]: /releases/2016/03/22/gitlab-8-6-released/\n",{"slug":4593,"featured":6,"template":681},"feature-highlihght-confidential-issues","content:en-us:blog:feature-highlihght-confidential-issues.yml","Feature Highlihght Confidential Issues","en-us/blog/feature-highlihght-confidential-issues.yml","en-us/blog/feature-highlihght-confidential-issues",{"_path":4599,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4600,"content":4606,"config":4611,"_id":4613,"_type":17,"title":4614,"_source":18,"_file":4615,"_stem":4616,"_extension":21},"/en-us/blog/feature-highlight-saml",{"title":4601,"description":4602,"ogTitle":4601,"ogDescription":4602,"noIndex":6,"ogImage":4603,"ogUrl":4604,"ogSiteName":667,"ogType":668,"canonicalUrls":4604,"schema":4605},"Feature Highlight: SAML and its future within GitLab","In this blog post I'll give you an overview of what I've been working on, how it affects GitLab, and what we plan to do with SAML in the future.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684764/Blog/Hero%20Images/galaxy-small.jpg","https://about.gitlab.com/blog/feature-highlight-saml","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature Highlight: SAML and its future within GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patricio Cano\"}],\n        \"datePublished\": \"2016-03-30\",\n      }",{"title":4601,"description":4602,"authors":4607,"heroImage":4603,"date":4609,"body":4610,"category":14},[4608],"Patricio Cano","2016-03-30","\n\nAs a Service Engineer I'm in constant contact with customers, listening to their\nneeds, and I've noticed a steadily-increasing interest in SAML from our\nEnterprise Customers. That inspired me to dive a little deeper into the topic in\nan effort to improve our integration with SAML and to add better documentation.\nI hope this helps our customers and our community to better understand this\nfeature.\n\nIn this blog post I'll give you an overview of what I've been working on, how it\naffects GitLab, and what we plan to do with SAML in the future. Our plan is to\nbring SAML up to par with the features that LDAP offers within GitLab.\n\n\u003C!-- more -->\n\n## What is SAML?\n\nSAML stands for Security Assertion Markup Language. It is an XML standard that\nallows secure web domains to exchange user authentication and authorization data.\nUsing SAML, an online service provider can contact a separate online identity\nprovider to authenticate users who are trying to access secure content.\n[[1]](https://developers.google.com/google-apps/sso/saml_reference_implementation)\n\nThis gives you the ability to add users to your service without having to know\nanything about them beforehand. You just need to trust the identity provider.\n\nIt also provides you with the ability to enable Single Sign On (SSO) for your\nGitLab instance, allowing your users to access your GitLab instance without\nhaving to create a new account and set a password.\n\nHere is an example on how the SAML request and response work. In this example\nGitLab would be the \"Service Provider\":\n\n![SAML Workflow Example](https://about.gitlab.com/images/saml_workflow_vertical.gif)\n\n[Public domain image from Wikipedia](https://en.wikipedia.org/wiki/SAML_2.0#/media/File:Saml2-browser-sso-post.gif)\n\n## SAML & GitLab\n\n### The beginnings\n\nGitLab first introduced SAML support in version [7.12](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/722/diffs)\nvia a contribution from our amazing community. The feature was contributed by\n[CERN](http://home.cern/) almost 10 months ago. Since the original contribution,\nnot much changed around the SAML support offered by GitLab. But interest from\nour users and our customers increased. You can check all SAML related merge\nrequests\n[here](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?utf8=%E2%9C%93&issue_search=saml&state=merged&scope=all&assignee_id=&author_id=&milestone_id=&label_id=).\n\nDue to the increased interest, I decided to dive into all the parts required to\nget GitLab to speak SAML. Here I encountered `omniauth-saml`, a project with thousands\nof downloads that has been dormant for the past 6 months.\n\n### Reviving omniauth-saml\n\nThe `omniauth-saml` gem was originally developed and maintained by\n[Practically Green](http://www.wespire.com/), but in the last couple of months\nit lost momentum from its maintainers.\nThe gem on which this one is based, `ruby-saml`, started to add new features\nrecently and merge requests were made on the `omniauth-saml` repo to add these\nnew features as well, but they went without review from the maintainers\nfor quite some time.\n\nLuckily the maintainers realized that there was still a lot of interest in the\n`omniauth-saml` gem and [decided](https://github.com/omniauth/omniauth-saml/issues/67)\nto give control of the gem to the community. Since I was one of the people\ninvolved in the latest merge requests, I was included in the list of people\ngiven owner access. This allowed a small group of passionate people to continue\nthe amazing work that the developers at Practically Green started almost 5\nyears ago.\n\nOnce this process was completed we immediately got to work reviewing pending pull\nrequests, asking community members to update their code to resolve conflicts,\nsolving old issues, updating dependencies, and adding a continuous integration\nservice. All this work culminated a few weeks ago when we released `omniauth-saml`\nversion [1.5.0](https://github.com/omniauth/omniauth-saml/blob/master/CHANGELOG.md#150-2016-02-25)\nwith support for [Custom Attributes](http://doc.gitlab.com/ce/integration/saml.html#attribute_statements),\nbetter error handling, and a couple of bug fixes.\n\nThe inclusion of these features, especially the Custom Attributes, are of great\nuse to GitLab users. You no longer need to change your Identity Provider (IdP)\nserver to match the parameters that GitLab is expecting, you can now tell\n`omniauth-saml`, and therefore GitLab, where to look for them.\n\nGitLab relies on [`omniauth-saml`](https://github.com/omniauth/omniauth-saml) to\nprovide the integration with a SAML IdP. It also uses\n[Devise](https://github.com/heartcombo/devise) as an authentication platform.\nDevise allows you to extend its authentication mechanism using Omniauth.\n`omniauth-saml` is a strategy that allows Omniauth to retrieve user information\nfrom a SAML IdP and relay this information to GitLab to either create a new user,\nor bind this new authentication mechanism to an existing user (if GitLab is\n[configured](http://doc.gitlab.com/ce/integration/saml.html) to do so).\n\nAlong with the inclusion of better SAML documentation, these changes will help\nusers and admins better integrate their GitLab installation with their SAML provider,\nand more easily detect and troubleshoot any errors.\n\n## The future\n\nWe recently started [separating SAML](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2882/)\nfrom the rest of the regular Omniauth providers to give us some room to improve\nthe integration between SAML and GitLab.\n\nAt the moment SAML only functions as an authentication provider, but with SAML 2.0\n(the only version of SAML supported by GitLab) you can also retrieve Group Membership\ninformation from the Identity Provider, if the IdP server supports this feature\nand is configured to respond with this information. For this to work, the\nmembership information needs to be added to the SAML response as a SAML\nAttribute in the generated SAML 2.0 Assertion.\n\nIf we leverage this feature, we would be able to manage GitLab Group Memberships\nvia SAML, as we do now for LDAP within Enterprise Edition. This would allow\nadmins to offload the management of user groups to a different service, offer\ntheir users an SSO system, and not have to worry about setting up LDAP as well\nas SAML to accomplish both. For this we will need to use `ruby-saml` directly.\n\n### ruby-saml\n\n[`ruby-saml`](https://github.com/onelogin/ruby-saml) is a Ruby library for\nimplementing client-side SAML authorization. `omniauth-saml` relies on this library\nfor initialization and validation of a SAML request/response protocol. `ruby-saml`\nis maintained by the amazing people at [OneLogin](https://www.onelogin.com/).\n\n",{"slug":4612,"featured":6,"template":681},"feature-highlight-saml","content:en-us:blog:feature-highlight-saml.yml","Feature Highlight Saml","en-us/blog/feature-highlight-saml.yml","en-us/blog/feature-highlight-saml",{"_path":4618,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4619,"content":4625,"config":4630,"_id":4632,"_type":17,"title":4633,"_source":18,"_file":4634,"_stem":4635,"_extension":21},"/en-us/blog/webcast-gitlab-86",{"title":4620,"description":4621,"ogTitle":4620,"ogDescription":4621,"noIndex":6,"ogImage":4622,"ogUrl":4623,"ogSiteName":667,"ogType":668,"canonicalUrls":4623,"schema":4624},"Webcast Recording and Slides: GitLab 8.6","If you're new to GitLab, this webcast will give you a good overview of using GitLab, and if you're experienced you get to see the new features in action.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683732/Blog/Hero%20Images/stars.png","https://about.gitlab.com/blog/webcast-gitlab-86","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Webcast Recording and Slides: GitLab 8.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather McNamee\"}],\n        \"datePublished\": \"2016-03-25\",\n      }",{"title":4620,"description":4621,"authors":4626,"heroImage":4622,"date":4628,"body":4629,"category":14},[4627],"Heather McNamee","2016-03-25","\n\nIn our latest webcast, we looked at highlights from GitLab 8.6.\n\nOur special guest, [Douwe Maan][Douwe], gave us a live demo of the latest features\nin [GitLab 8.6][releasenotes] with a special focus around improved confidentiality.\nWe looked at project configuration and user permissions to start.\nDouwe followed a typical GitLab workflow to demonstrate new features\nwhich make it easier to keep track of what is happening (subscribe to label)\nand features which save you time (create a new branch from an issue), and more.\n\nIf you're new to GitLab, this webcast will give you a good overview of using GitLab,\nand if you're experienced you get to see the new features in action.\n\nSign up to our [newsletter][newsletter]\nto make sure you don't miss any of our live webcasts.\n\n\u003C!-- more -->\n\nIn this webcast:\n\n- Demo: Feature highlights from GitLab 8.6\n- Highlight: Improved confidentiality with confidential issues and external users\n- Q&A: Questions from webcast attendees answered live\n- New resources: Getting started with GitLab Pages ([skip ahead](https://youtu.be/4r-dUrdpLo8?t=3128))\n- Community news! ([skip ahead](https://youtu.be/4r-dUrdpLo8?t=3284))\n\n## Webcast Recording\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/4r-dUrdpLo8\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\n## Webcast Slides\n\n\u003Cscript async class=\"speakerdeck-embed\" data-id=\"5e2c749028334614b567bc173a464d31\" data-ratio=\"1.77777777777778\" src=\"//speakerdeck.com/assets/embed.js\">\u003C/script>\n\n## Join our next webcast!\n\nIn our next webcast on April 14th, we'll take a look using continuous\nintegration in GitLab. Join the GitLab CI team for this introduction!\n\n- Date: Thursday, April 14, 2016\n- Time: 9am PDT; 12pm EST; 5pm BST (British Standard time); (16:00 UTC)\n- [Register here][webcast]\n\nCan't make it? Register anyway, and we'll send you a link to watch it later.\n\n[newsletter]: /company/contact/#newsletter\n[webcast]: http://page.gitlab.com/apr-2016-gitlab-intro-ci-webcast.html\n[Douwe]: https://twitter.com/DouweM\n[releasenotes]: /releases/2016/03/22/gitlab-8-6-released/\n",{"slug":4631,"featured":6,"template":681},"webcast-gitlab-86","content:en-us:blog:webcast-gitlab-86.yml","Webcast Gitlab 86","en-us/blog/webcast-gitlab-86.yml","en-us/blog/webcast-gitlab-86",{"_path":4637,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4638,"content":4644,"config":4648,"_id":4650,"_type":17,"title":4651,"_source":18,"_file":4652,"_stem":4653,"_extension":21},"/en-us/blog/gitlab-in-case-you-missed-it",{"title":4639,"description":4640,"ogTitle":4639,"ogDescription":4640,"noIndex":6,"ogImage":4641,"ogUrl":4642,"ogSiteName":667,"ogType":668,"canonicalUrls":4642,"schema":4643},"GitLab: In case you missed it","The first two weeks working with GitLab have been full of pleasant surprises and dispelled delusions. If you haven't been following GitLab for the last two years, this post is for you.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684623/Blog/Hero%20Images/key-concepts.jpg","https://about.gitlab.com/blog/gitlab-in-case-you-missed-it","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab: In case you missed it\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ivan Nemytchenko\"}],\n        \"datePublished\": \"2016-03-14\",\n      }",{"title":4639,"description":4640,"authors":4645,"heroImage":4641,"date":4646,"body":4647,"category":14},[4496],"2016-03-14","\n\nI've recently joined GitLab as a Developer Advocate. \nPart of my role will be traveling to community events where I hope we'll meet in person. \nI'm also an experienced Ruby developer. \nAs a rubyist, naturally, I've heard about GitLab and even used it couple of times.\n\nThe first two weeks working with GitLab have been full of pleasant surprises and dispelled delusions. \nIf you haven't been following GitLab for the last two years, this post is for you.\n\n\u003C!--more-->\n\n## GitLab.com\n\nYou don't have to download and install GitLab nowadays. \nYou can simply [sign up for GitLab.com](https://gitlab.com/users/sign_in) and host your own repositories. \nEven the private ones. \nYes, for free and without any restrictions. \nNo, there is no catch.\n\nIt should be noted that repositories are actually called \"projects\". \n\nAnd that is not the only thing that catches your eye at first. \nAs it turns out, the terminology is justified.\n\n## The terminology \n\nThese aren't just fancy terms to stand out from the crowd. \nI strongly recommend reading the article about [GitLab, GitHub and Bitbucket and terms comparison](/blog/comparing-terms-gitlab-github-bitbucket/), if you wish to sort out the details. \nI'd like to bring up the \"Merge requests\" topic, as it's the most controversial.\n\nMy initial reaction, naturally, was rejection. Most of us are accustomed to\n\"Pull requests\", so what's the big idea?\nBut then I remembered that the title \"Pull request\" never did make perfect\nsense to me because closing a pull request actually does branch merging.\n\nAs it turns out, there is a command [`git request-pull`](https://git-scm.com/docs/git-request-pull),\nhence the feature title.\n\nPull requests have nothing in common with this git command. So, technically the correct name is \"merge request\". \n[Learn more](/blog/comparing-terms-gitlab-github-bitbucket/) on terminology differences, if you're interested.\n\nThe terminology was just a part of the deal. \nWhen reading the documentation, I discovered something called \"omnibus\" and\nfound some mysterious \"runners\" and \"shared runners\" in the settings. \nBut first things first. \nRunners are connected to CI. \nOmnibus is related to GitLab installation on your own server.\n\n## Continuous Integration (CI)\n\nContinuous Integration is a best practice in software development.\nFor example, a CI server runs your tests every time you push changes to the repository.\n\nA lot of companies have a separate CI service but in GitLab, [CI is embedded](https://docs.gitlab.com/ee/ci/).\n\nIf you had to manually connect two services before, it just works on its own in GitLab.\nThough you can still use other continuous integration services such as [Jenkins](http://doc.gitlab.com/ee/integration/jenkins.html).\n\nAnd it works through runners.\n\n## Runners\n\nA runner is a virtual machine that runs your tests, builds your builds or generates static files for your websites. \nGitLab.com users are able to make use of a special [Shared Runners](http://doc.gitlab.com/ce/ci/quick_start/README.html#shared-runners) pool to simply make everything work. \n\nSince the pool is shared across all projects on GitLab.com, sometimes it can\ntake a while to wait for your project's build to be processed.\n\nIf you are not satisfied with the Shared runners performance, you can\n[set up a runner](/blog/gitlab-runner-with-docker/)\non your own server and connect it to one or more projects.\n\nDon't forget that you can install GitLab on your own server as well. \n\n## GitLab installation with Omnibus\n\n\nIn the past, GitLab was installed manually. \nNow you can install and update the service from packages thanks to Omnibus.\n[Omnibus](http://doc.gitlab.com/omnibus) is a tool developed by Chef\nthat helps to create installation packages for complex software with a lot of\ncomponents for various platforms.\n\nAny installation using Omnibus lasts for 2-6 minutes tops, depending on your server performance. \nThis is what GitLab installation looks like on Ubuntu 14.04 using a relatively slow VPS with 2Gb running memory:\n\u003Cscript type=\"text/javascript\" src=\"https://asciinema.org/a/39151.js\" id=\"asciicast-39151\" async>\u003C/script>\n\nHint: in case you'd prefer not to mess with console installation and updates at\nall, you can simply rent a GitLab server on [Githost.io](https://githost.io/)\n\nBoth Omnibus and built-in CI are just a portion of what is being done to make developers' jobs easier.\nLet us review a few features.\n\n## Small features that make a difference\n\n### Merge when build succeeds\n\nWith GitLab, you don't have to wait for your build to turn green to finally merge the branch. \nYou can simply ask GitLab to do that for you.\n\n![Merge when build succeeds](https://about.gitlab.com/images/automerge.jpg)\n\n### Publishing with GitLab Pages\n\nGitLab Pages runs on top of the built-in CI.\nThanks to the feature, you can host websites created by any static site generators on GitLab.\n\nFork a repo from [GitLab examples](https://gitlab.com/groups/gitlab-examples?utf8=%E2%9C%93&filter_projects=pages-)\nor figure out GitLab CI settings to forget all about the manual static generation.\nYou simply push your changes to the repository and GitLab generates and deploys everything on its own.\n\nCustom CNAME and TLS [are supported](http://doc.gitlab.com/ee/pages/README.html#add-a-custom-domain-to-your-pages-website).\n\nThese kinds of features have become possible due to the synergy between system components.\nThere's much more coming.\n\n## GitLab Direction\n\nPlease don't be surprised once a crashed build creates a TODO automatically or GitLab introduces built-in chat.\n\nIf you want to know where GitLab is heading, keep an eye on the [Direction page](/direction/).\nThis includes not only the short term objectives for the next release, but also the long-range vision.\n\n* * * \n\nHopefully, this article has helped you to fill in the gaps in understanding what GitLab is now. \nI'm planning to write two more articles: about migrating personal projects to GitLab and about contributing to GitLab.\nStay tuned and [follow me on Twitter](https://twitter.com/inemation).\n\nI'm always happy to answer your questions in comments or personally.\nOver the next several weeks I will be speaking at the following Ukrainian Ruby-meetups, where we can catch up:\n\n- [Ruby Meditation, Kiev](https://www.facebook.com/events/406794219490854/) (March 18)\n- [Pivorak, Lviv](https://www.facebook.com/pivorak/) (March 26)\n\n## Join our webcast about GitLab CI.\n\nI mentioned Gitlab CI a few times in this blog post. If you're interested,\nwe'll have a live webcast all about GitLab CI.\n\n- Date: Thursday, April 14, 2016 \n- Time: 5pm (17:00) UTC; 12pm EST; 9am PST \n- [Register here][webcast]\n\nCan't make these times? Register anyway, and we'll send you a link to watch later.\n[webcast]: http://page.gitlab.com/apr-2016-gitlab-intro-ci-webcast.html\n",{"slug":4649,"featured":6,"template":681},"gitlab-in-case-you-missed-it","content:en-us:blog:gitlab-in-case-you-missed-it.yml","Gitlab In Case You Missed It","en-us/blog/gitlab-in-case-you-missed-it.yml","en-us/blog/gitlab-in-case-you-missed-it",{"_path":4655,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4656,"content":4662,"config":4666,"_id":4668,"_type":17,"title":4657,"_source":18,"_file":4669,"_stem":4670,"_extension":21},"/en-us/blog/commits-do-not-equal-productivity",{"title":4657,"description":4658,"ogTitle":4657,"ogDescription":4658,"noIndex":6,"ogImage":4659,"ogUrl":4660,"ogSiteName":667,"ogType":668,"canonicalUrls":4660,"schema":4661},"Commits Do Not Equal Productivity","In this post we'll consider some ways people evaluate or represent productivity, and I ask for your thoughts on what you track and what you think matters.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684616/Blog/Hero%20Images/racing.png","https://about.gitlab.com/blog/commits-do-not-equal-productivity","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Commits Do Not Equal Productivity\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2016-03-08\",\n      }",{"title":4657,"description":4658,"authors":4663,"heroImage":4659,"date":4664,"body":4665,"category":14},[4534],"2016-03-08","\n\nIf you’re interested in an indication of productivity of individual software engineers (programmers), don’t look at commits or other measures of activity. Look at _consistent progress_ instead.\nIn this post we'll consider some ways people evaluate or represent productivity,\nand I ask for your thoughts on what you track and what you think matters.\n\n\u003C!-- more -->\n\n## Commits\n\nCommits are arbitrary changes captured in a single moment in time. Their size and frequency do not correlate with the work needed to achieve that change. At best, commits can be viewed as an indication of activity.\n\nAs a general rule, a programmer should consistently be making commits throughout their work. This can be reduced to ‘a programmer should write code’, which is not very enlightening.\nThe frequency of the commits, nor the size should be compared between programmers. What should be committed is often a matter of personal preference and is subject to debate.\n\nIt can be argued that diminishing commits by a single engineer on a single project can be an indicator of lower productivity. However, that engineer might’ve just read a Hacker News thread that argues for squashing smaller commits.\n\nDon’t measure productivity with commits.\n\n## Weights and Points\n\nAre you using an issue tracker with weights or points? That’s a good start. You can now get a sense of the total volume of work planned and delivered by a team.\n\nTypically, you’d sum the total sum of delivered work and call that _velocity_. You now have a good idea how well your _team_ can estimate the effort required to build things versus how much they actually build things.\n\nEstimating issue weights is notoriously hard and is advised to be done in a group, using games like [Planning Poker]. The issue weight should be taken as an abstract idea of the total body of work, not directly related to the amount of time necessary for this task (this is also why people often use the Fibonacci sequence, and as bigger tasks are harder to estimate).\n\nMeasuring the productivity of individuals by looking at velocity on an engineer-by-engineer basis would mean they’d be measured against the ability of the group to estimate work load. Worse is that this would encourage engineers to over-estimate or otherwise ‘play the system’.\n\nDon’t measure productivity with velocity.\n\n## Progress\n\nTo get an indication of productivity, look at the progress someone is making in their work. In this sense, progress means someone is taking deliberate steps to work towards solving the problem they are working on.\n\nThe best way to get an idea of someone’s progress is to look at _both their communication and activity_. An effective engineer will either be making commits to further their progress or communicate in some way about their work. It’s only when you look at both these factors that you can say something about their productivity.\n\n**A productive engineer communicates and commits. At times, only one of the two.**\n\n## How to Gauge Productivity\n\nI argue that an engineer’s productivity should not be judged by their deliverables or direct output, rather it should be measured by progress. Progress as I define it, is hard to measure, but easy to gauge:\n\n> How is your work going?\n\nA productive programmer will tell you to stop distracting them and come back\nin an hour. And then they’ll give you a pretty good idea of their productivity.\n\n## How to Measure Productivity\n\nRight now, in GitLab you can see your commit activity in your profile:\n\n![In your profile, view commits per day in GitLab](https://about.gitlab.com/images/commitsprod/commits.png)\n\nand get an idea of how everyone in a project is committing on average during\nthe day:\n\n![View average project commit activity in GitLab](https://about.gitlab.com/images/commitsprod/perday.png)\n\nBut both of these measures only relate to direct commit activity.\nIn GitLab Enterprise Edition, you can get a detailed overview of\nthe activity of everyone in a group with our [Contribution Analytics].\nHere, we give a better overview of the total amount of activity of any\ndeveloper, but in all fairness doesn't resolve all problems that I've outlined.\n\nIn future releases, we're planning to add more analytics to GitLab,\nboth relating to code (quality) and activity of its users. I hope that by\ncombining more data in smart ways, we can give better insights into developer\nactivity.\n\nI'm especially interested to hear what you think we should measure.\nPlease feel free to leave a comment below or [create an issue] suggesting\nhow we can improve analytics in GitLab.\n\n## Live tutorial: GitLab workflow\n\nIn our next webcast on March 10th, we'll dig into the GitLab workflow.\n\nThis will take you through the steps of making an issue, merge requests, and\nusing tools in GitLab for cross-referencing and keeping your issue tracker\norganized with labels and milestones.\n\n- Date: Thursday, March 10, 2016\n- Time: 5pm (17:00) UTC; 12pm EST; 9am PST\n- [Register here][webcast]\n\nCan't make it? Register anyway, and we'll send you a link to watch it later.\n\n[Planning Poker]: https://www.planningpoker.com\n[webcast]: http://page.gitlab.com/mar-2016-gitlab-introduction.html\n[Contribution Analytics]: http://doc.gitlab.com/ee/analytics/contribution_analytics.html\n[create an issue]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new\n",{"slug":4667,"featured":6,"template":681},"commits-do-not-equal-productivity","content:en-us:blog:commits-do-not-equal-productivity.yml","en-us/blog/commits-do-not-equal-productivity.yml","en-us/blog/commits-do-not-equal-productivity",{"_path":4672,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4673,"content":4679,"config":4683,"_id":4685,"_type":17,"title":4686,"_source":18,"_file":4687,"_stem":4688,"_extension":21},"/en-us/blog/comparing-terms-gitlab-github-bitbucket",{"title":4674,"description":4675,"ogTitle":4674,"ogDescription":4675,"noIndex":6,"ogImage":4676,"ogUrl":4677,"ogSiteName":667,"ogType":668,"canonicalUrls":4677,"schema":4678},"Comparing Confusing Terms in GitHub, Bitbucket, and GitLab","In this post, we have a handy reference guide to explain some potentially confusing terms, especially if you're new to GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666738/Blog/Hero%20Images/trees-raysoflight.jpg","https://about.gitlab.com/blog/comparing-terms-gitlab-github-bitbucket","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comparing Confusing Terms in GitHub, Bitbucket, and GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather McNamee\"}],\n        \"datePublished\": \"2016-01-27\",\n      }",{"title":4674,"description":4675,"authors":4680,"heroImage":4676,"date":4681,"body":4682,"category":14},[4627],"2016-01-27","\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fas fa-exclamation-triangle\" style=\"font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nPlease read the [up-to-date version of this article](/blog/comparing-confusing-terms-in-github-bitbucket-and-gitlab/)!\n  \u003Ci class=\"fas fa-exclamation-triangle\" style=\"font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\n{::options parse_block_html=\"false\" /}\n\nDevelopers rely on multiple platforms to manage repositories, depending on\nclient and project needs.\nThey might contribute to a community project on GitHub, while working on one\nclient's on premises GitLab instance and another client's project in Mercurial\non Bitbucket.\nConfusion can arise when you switch between platforms.\nIn this post, we have a handy reference guide to explain\nsome potentially confusing terms, especially if you're new\nto GitLab.\n\n\u003C!--more-->\n\nWith the [8.4 Release][release], GitLab has improved migration support for\nthose coming from GitHub to GitLab.\nGitLab now [imports][imports] your repositories, wikis, issues and\npull requests from GitHub.\nWhile most terminology is shared\nbetween the platforms, some differences lead to confusion\nfor users.\nGit-specific terms like commits, push, and so forth are the same.\nCommon features most repository managers have are also the same: such as users, issues, webhooks, etc.\n\nHowever some features have different names.\nFor example a “pull request” in GitHub and Bitbucket is called a “merge request” in GitLab.\nWe figured since you're often making a request to `merge` a feature branch into the master branch, we call this a\n\"merge request\" and you'll hear us talk about MRs and not PRs.\n\nIf you’re brand new to GitLab, we’ve made this handy cheat-sheet to help you orient yourself and clear things up.\n\n![The Import Project UI in GitLab showing you can import from GitHub, Bitbucket, etc](https://about.gitlab.com/images/blogimages/gitlab-terminology.png)\n\n## Teams, Repositories, Organizations?\n\nFrom teams to repositories to organizations, there’s a potential for fresh confusion.\nIn GitHub, *repositories* contain the Git/SVN repository, and the project assets\nsuch as issues, contribution metrics, etc.\nHowever users often refer to repos as *projects* interchangeably.\n\nSo in GitLab, we call that container a Project.\nThat includes the Git repository, issues, MRs, etc.\nWhen you configure a project, you can;\n\n- Choose [project features][projects].\n- Set the project avatar.\n- Set the visibility level for that project such as Private, Internal or Public.\n- Transfer it, remove it or archive it.\n- Configure [GitLab CI for a project][gitlabci].\n- Add [project-level services](https://docs.gitlab.com/ee/user/project/integrations/index.html) for third-party integrations.\n\nIt's important to make this distinction because you import *project* in\nGitLab, regardless of whether that is called a *repository* elsewhere.\n\n![The Import Project UI in GitLab showing you can import from GitHub, Bitbucket, etc](https://about.gitlab.com/images/blogimages/import-project.jpg)\n\nThis is where it could get confusing.\nNow Bitbucket groups multiple repositories into *Projects*, multiple projects into teams,\nand teams in Bitbucket are analogous to an *Organization* in GitHub.\n\nIn GitLab, we call this a *Group*.\nThis allows you to collect several projects together and also have members.\nThose members can then configure their own group-level notifications.\nProjects can be stored in only one group at once.\nHowever you can share a project with other groups in GitLab Enterprise Edition\n([available in GitLab Community Edition from 8.5 onward](https://gitlab.com/gitlab-org/gitlab-ce/issues/12831)).\nAnd even those settings can be locked at the group level so you can avoid\nsomeone sharing a private project to other groups, for example.\n\nThe confusion is understandable, especially if like many developers,\nyou work with a number of clients each on different platforms.\n\nI hope this has cleared up confusion. If you have any questions,\nyou can join us for a [live Q & A in our webcast][webcast] Thursday, January 28, 5pm (17:00) UTC; 12pm EST; 9am PST.\n\n[imports]: http://doc.gitlab.com/ce/workflow/importing/import_projects_from_github.html \"Importing from GitHub to GitLab\"\n[services]: https://docs.gitlab.com/ee/user/project/integrations/overview.html \"Configure Services for Projects\"\n[gitlabci]: http://doc.gitlab.com/ce/ci/yaml/README.html \"configure GitLab CI\"\n[projects]: http://doc.gitlab.com/ce/workflow/project_features.html \"Documentation of Project features\"\n[webcast]: http://page.gitlab.com/Jan282016Webcast.html \"Webcast: 8.4 Feature Walk-through\"\n[release]: /releases/2016/01/22/gitlab-8-4-released/ \"Announcing GitLab's 50th Release: 8.4\"\n[bitbucket]: https://blog.bitbucket.org/2016/01/21/distributed-teams-can-now-build-faster-with-bitbucket/ \"Bitbucket announces Projects\"\n",{"slug":4684,"featured":6,"template":681},"comparing-terms-gitlab-github-bitbucket","content:en-us:blog:comparing-terms-gitlab-github-bitbucket.yml","Comparing Terms Gitlab Github Bitbucket","en-us/blog/comparing-terms-gitlab-github-bitbucket.yml","en-us/blog/comparing-terms-gitlab-github-bitbucket",{"_path":4690,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4691,"content":4697,"config":4701,"_id":4703,"_type":17,"title":4704,"_source":18,"_file":4705,"_stem":4706,"_extension":21},"/en-us/blog/swag-gitlab-plan",{"title":4692,"description":4693,"ogTitle":4692,"ogDescription":4693,"noIndex":6,"ogImage":4694,"ogUrl":4695,"ogSiteName":667,"ogType":668,"canonicalUrls":4695,"schema":4696},"Swag matters - share your #swagportrait","Please let us know about your favourite swag, from stickers to surprises, and don’t forget to share your #swagportrait.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684568/Blog/Hero%20Images/trees-xmas.png","https://about.gitlab.com/blog/swag-gitlab-plan","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Swag matters - share your #swagportrait\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather McNamee\"}],\n        \"datePublished\": \"2015-12-30\",\n      }",{"title":4692,"description":4693,"authors":4698,"heroImage":4694,"date":4699,"body":4700,"category":14},[4627],"2015-12-30","\n\nSome GitLab users who should be celebrating the festive season might be suffering from post-Christmas blues. Maybe you didn’t get everything you wanted for Christmas. We feel partly responsible for that, and we want to make it up to you. \n\nWe’re so happy when people contact us to ask for some swag: a sticker, a t-shirt, anything! Then we feel sad because we don’t have a swag shop and we have no way to get people something to show their appreciation. This is a great problem to have: too much love. \n\nSo now we’re hard at work to get a swag shop set up. If you want to be the absolute first to know about it, sign up below. Bonus: You’ll be entered into a prize draw for a gift. Good luck! \n\nThere's another way to win too.\n\n\u003C!-- more -->\n\n## Please share pics tagged #swagportrait\n\nThe truth is, swag does matter. Even the humble sticker can communicate so much about identity and interest. On OpenSource.com Rikki Endlsey wrote about [Open source sticker culture](https://opensource.com/business/15/11/open-source-stickers#culture). Rikki details how people share their support for and help promote projects and people by using stickers, including more exclusive “earned” stickers showing achievements or events attended.\n\n\u003Cblockquote class=\"twitter-tweet\" lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">It's harder for me to choose stickers for my laptop than \u003Ca href=\"https://twitter.com/hashtag/JavaScript?src=hash\">#JavaScript\u003C/a> framework. \u003Ca href=\"https://twitter.com/hashtag/DevProblems?src=hash\">#DevProblems\u003C/a> 😂😂😂 \u003Ca href=\"https://t.co/fnN02tHpk0\">pic.twitter.com/fnN02tHpk0\u003C/a>\u003C/p>— Pablo Villoslada (@Puigcerber) \u003Ca href=\"https://twitter.com/Puigcerber/status/677815759297511424\">December 18, 2015\u003C/a>\u003C/blockquote> \u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nMy friend Kristof Van Tomme, who works within several networks, can demonstrate his affiliations and connections quickly. Something as simple as a sticker can spark the next important conversation he has. \n\n\u003Cblockquote class=\"twitter-tweet\" lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">My current laptop sticker collage \u003Ca href=\"https://twitter.com/nearlythere\">@nearlythere\u003C/a> \u003Ca href=\"https://t.co/pPmX9GFiLf\">pic.twitter.com/pPmX9GFiLf\u003C/a>\u003C/p>— Kristof Van Tomme (@kvantomme) \u003Ca href=\"https://twitter.com/kvantomme/status/670630306936979457\">November 28, 2015\u003C/a>\u003C/blockquote> \u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nI’m really curious about the great swag you’ve seen. Please share a pic of your laptop as a self portrait on twitter. As another incentive, we’re going to run this until our swag store opens and then we’ll do a draw from all the #swagportrait hashtag entries on anyone who shares on the hashtag. Will you play along? Here’s mine! (Well OK this is my old computer, my new one needs stickers.)\n\n\u003Cblockquote class=\"twitter-tweet\" lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Here's my \u003Ca href=\"https://twitter.com/hashtag/swagportrait?src=hash\">#swagportrait\u003C/a> on my old laptop. Since then, had a work laptop which is now gone. \u003Ca href=\"https://t.co/Uxlb8tKTKb\">pic.twitter.com/Uxlb8tKTKb\u003C/a>\u003C/p>— Heather (@nearlythere) \u003Ca href=\"https://twitter.com/nearlythere/status/677821197585940480\">December 18, 2015\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n## Let’s talk swag\n\nI think it’s pretty clear we need to have some nice stickers, with designs for events and as rewards. But we want to develop some other ideas. What we want to avoid is “bad swag”. Bad swag might be poor quality and wasteful swag. \n\nWe can promise that we will never make a comedy unibrow mug.\n\n\u003Cblockquote class=\"twitter-tweet\" lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Looking forward to the \u003Ca href=\"https://twitter.com/webawards\">@webawards\u003C/a> next week & giving away some \u003Ca href=\"https://twitter.com/hashtag/badswag?src=hash\">#badswag\u003C/a> \u003Ca href=\"https://twitter.com/hashtag/realexwebs15?src=hash\">#realexwebs15\u003C/a> \u003Ca href=\"http://t.co/tKo4IUpLkw\">pic.twitter.com/tKo4IUpLkw\u003C/a>\u003C/p>— Martin O'Leary (@Martinoleary) \u003Ca href=\"https://twitter.com/Martinoleary/status/651760858524164096\">October 7, 2015\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nRealex Payments’ [“Bad Swag” campaign](https://www.realexpayments.com/bad-swag) made a point in saying that some companies consider “developer relations” to be about making swag, forgetting that swag is just a symbol of a relationship with developers, not the relationship itself. \n\nAt GitLab, we don’t want to focus only on building tools for developers that we forget to support the community and help them connect.  So let’s talk about **good swag**. What is some good swag you've seen? \n\nAmong [other great swag ideas](http://blog.hubspot.com/blog/tabid/6307/bid/33361/Event-Swag-Your-Attendees-Will-Love-and-Loathe.aspx), Hubspot lists “Unique Food Items” as great swag. We did stroopwafels for OSCON in Amsterdam. Everyone loves a good stroopwafel! \n\n\u003Cblockquote class=\"twitter-tweet\" lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">I'm a winner and so is \u003Ca href=\"https://twitter.com/gitlab\">@gitlab\u003C/a> - thanks folks! \u003Ca href=\"https://twitter.com/hashtag/OSCON?src=hash\">#OSCON\u003C/a> \u003Ca href=\"https://t.co/B40tPfOMax\">pic.twitter.com/B40tPfOMax\u003C/a>\u003C/p>— Duane O'Brien (@DuaneOBrien) \u003Ca href=\"https://twitter.com/DuaneOBrien/status/659022203279798272\">October 27, 2015\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nWe’re also thinking of ways to use alternative materials, create locally, and support makers. I love the [Resketch notebooks](http://resketchbook.com/) by Shawn Smith which use reclaimed materials to make fun notebooks. I like that this kind of product reduces waste. Have you seen other cool products like that?\n\nA while back, I asked a talented craftsperson I know, [A Million Paper Stars](https://www.facebook.com/amillionpaperstars), to make a bag for me to carry my various computer charger, mouse, etc. I wanted to get creative and try something different. Would you be interested in handmade swag?\n\n![GitLab bag by A Million Paper Stars](https://about.gitlab.com/images/blogimages/gitlab-bag-amillionpaperstars.png)\n\nI’m really curious about the great swag you’ve seen. Creative ideas welcome! Please let us know about your favourite swag, from stickers to surprises, and don’t forget to share your #swagportrait if you’d like to be in with a chance to win some of GitLab’s first swag shop offerings. \n\n## GitLab Swag Alert\n\nWhen you add your name to this list you'll be put on our \"Swag Alert\" list. We'll contact you to find out more about your swag ideas. And as soon as the swag shop is open, you'll be the first to know. Then whenever we have a new product, we'll tell ya.\n\n\u003Cscript src=\"//page.gitlab.com/js/forms2/js/forms2.min.js\">\u003C/script>\n\u003Cform id=\"mktoForm_1125\">\u003C/form>\n\u003Cscript>MktoForms2.loadForm(\"//page.gitlab.com\", \"194-VVC-221\", 1125);\u003C/script>\n\nThanks, and looking forward to hearing from you and seeing your #swagportraits\n\n",{"slug":4702,"featured":6,"template":681},"swag-gitlab-plan","content:en-us:blog:swag-gitlab-plan.yml","Swag Gitlab Plan","en-us/blog/swag-gitlab-plan.yml","en-us/blog/swag-gitlab-plan",{"_path":4708,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4709,"content":4715,"config":4720,"_id":4722,"_type":17,"title":4723,"_source":18,"_file":4724,"_stem":4725,"_extension":21},"/en-us/blog/gitlab-release-process",{"title":4710,"description":4711,"ogTitle":4710,"ogDescription":4711,"noIndex":6,"ogImage":4712,"ogUrl":4713,"ogSiteName":667,"ogType":668,"canonicalUrls":4713,"schema":4714},"How we managed 49 monthly releases","In this article I’ll give you an overview of how we release our product and how it helps our team improve process and documentation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684538/Blog/Hero%20Images/leavesonbranch.png","https://about.gitlab.com/blog/gitlab-release-process","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we managed 49 monthly releases\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dmitriy Zaporozhets\"}],\n        \"datePublished\": \"2015-12-17\",\n      }",{"title":4710,"description":4711,"authors":4716,"heroImage":4712,"date":4718,"body":4719,"category":14},[4717],"Dmitriy Zaporozhets","2015-12-17","\n\nSince October 2011 we’ve released GitLab each month, without fail, without exceptions. On December 22nd that will be 49 monthly releases, not including patch releases or security releases. In this article I’ll give you an overview of how we release our product and how it helps our team improve process and documentation.\n\nYour release strategy affects how you plan, develop, test, and publish your software. At GitLab we follow a monthly release cycle which works really well for our project. If you’re running an open source distributed software project, you might consider if a predictable time-based release can help your project. You can even get started by using our release cycle documentation as your template.\n\n\u003C!-- more -->\n\n## Why time-based release cycles?\n\nTime-based releases make absolute sense if you develop distributed software. Take for example Apple macOS. They have a fixed release date, everyone knows when it will be coming out. With distributed software, users need to be prepared for a release. Another advantage is that it builds anticipation for the software release.\n\nIf you have SaaS type services, they don’t need a fixed release date. People are already using the software so it’s a matter of delivering features as soon as they are ready.\n\nAn open source project isn’t only you, working on your own. Even from very early on GitLab was always collaborative. The truth is, I’m a lazy person. I like to have lots of fun, and I always have stuff to do whether it’s playing video games or hanging out with friends. It’s actually a hack to deal with myself. You need some discipline or schedule, otherwise you will always find some reason to delay. A certain date makes it easier.\n\nThis has been a popular method in some open source projects. At the time I started GitLab I was inspired by Ubuntu’s [time based releases](https://wiki.ubuntu.com/TimeBasedReleases). I was always anticipating their next release, and this was inspiring. Ubuntu's time-based cycle was heavily influenced by the release process [used by the GNOME project](http://live.gnome.org/ReleasePlanning/TimeBased). Both of those projects follow a six month cycle generally. We follow a one month cycle.\n\n## Why monthly cycles?\n\nIn some ways the date and duration of a cycle is arbitrary. People ask me “Why is it on the 22nd?” perhaps expecting there is some meaning in the number. Actually, it was just the date of the previous release when we decided to make it monthly.\n\nBy choosing monthly it greatly simplifies communication. A bi-monthly release could cause confusion (\"Was it last month or the one before?\") and longer cycles could mean stagnation in development. Another advantage is that a short cycle keeps you focused on smaller iterations, and getting feedback quickly. It’s easier to test and see what is not working, and easier to roll back changes. This is the most awesome part of time-based release cycles.\n\nSometimes what happens on larger projects and teams is that people can be working in parallel and might be duplicating effort without knowing it. Someday, a manager might come to you and say “Yeah… we decided not to ship that feature you were working on. Someone else on another team was working on something similar, and your feature no longer makes sense.” That’s unfortunately a common experience.\n\nA short release cycle doesn’t allow you to work for a long time between when you create a feature and get feedback. It prevents people from losing their focus.\n\n## How do we organize who works on what and when?\n\nInstead of one person assigning tasks to team members, the team members pick up tasks from the pool. This is an [Agile practice](/solutions/agile-delivery/) which gives greater autonomy to the members of the team. You work on what you want to from the pool within the goals of the project.\n\nThe leaders define the direction. They work on the pool and define the milestones. We do work on large features, but these are split up into tasks. Our release priorities are published in our [Direction document in the Handbook](/direction/), and everyone on the team can see the current milestones we’re tracking against.\n\nWe do have some things which are high priority and which must be worked on first, such as security issues and priority features. After that, it’s a matter of what you want to work on yourself. This process of selecting issues and prioritization is outlined in our GitLab Handbook, under [GitLab Workflow](/handbook/communication/#gitlab-workflow). For example, “Assign an issue to yourself as soon as you start to work on it, but not before that time.” If an issue is assigned to someone, someone is working on it. If it’s not assigned to someone, no one is working on it. If it’s assigned to a milestone, there’s commitment to work on it. This also makes it easier for everyone on the team to collaborate. Having a manager to bring this distributed effort to release is very important.\n\n## The Release Manager is a role, not a person\n\nIn most software development projects a release process is followed by a team lead who delegates tasks. If there is always one person doing it, it’s not always documented. Also, you rely on that one person being available. We can’t wait if someone is sick or on vacation to get our release out. Having one person managing a release is a potential single point of failure.\n\nFor a long time, I managed all the releases. As soon as we had more people on our team at GitLab, I was able to hand this task over to others. Now we rotate the role of release management to a new appointed member each month. This means we don’t have one person who is always in charge of releases.\n\nThe benefits of making the Release Manager a role and not a person don’t stop at improving reliability, it also means a better process over all. When you pass the role to other people, a new person can contribute new ideas or improvements, for example to the process or documentation. The release itself becomes an object of collaboration. If a new person can follow along, we know the documentation is where it needs to be.\n\nThe release process is a good experience for any member of the team. It gives you a wider overview of the entire pipeline. Being a Release Manager requires that you collaborate with developers, operations, marketing, sales -- every aspect of the company. It’s a great way for you to get to know the entire team.\n\n## What does the Release Manager do?\n\nEach month the Release Manager is appointed to follow the release process which begins 7 business days prior to the release date. That person stays the Release Manager until the end of their cycle and the next Release Manager initiates the next release. The monthly release process is outlined in [our documentation](https://gitlab.com/gitlab-org/release-tools/blob/master/README.md).\n\nIt’s up to the Release Manager to delegate and coordinate activity among the team members, and to ensure everyone is up-to-date. They create an issue in the GitLab CE project, and use the `monthly.md` file as a template. This generates a checklist which the Release Manager updates as the release progresses. Finally, the Release Manager also appoints the next Release Manager who will initiate the next cycle.\n\n![Example monthly release checklist GitLab 8.3](https://about.gitlab.com/images/blogimages/monthly-release-checklist.jpg)\n\n## What are the steps towards release?\n\nSix business days before the 22nd, the first release candidates are created for CE and EE. After that, the team is testing and doing QA on the release. Four days before the release, we deploy to GitLab.com and test further. In the final days before the release we are working on building packages and preparing the blog post, which includes selecting a contributor MVP for the [GitLab Hall of Fame](/community/mvp/index.html).\n\nFinally, we release GitLab at 12am CET (Central European Time) of the 22nd. This ensures we have enough time during the European work day to address any issues that might arise.\n\n## What happens after a release?\n\nAs part of the release process, we have a regression issue where people point out functionality that may have been broken by the new release. We create fixes for issues as they arise, and prepare a patch release. Patch releases have no schedule. One might be released within 24 hours if it relates to security or data loss. We don’t want to do too many patch releases, especially because soon the next release will be coming out. It’s up to the Release Manager to decide how to handle this.\n\nIn the past we’ve held team calls to celebrate, but this can be interrupted. Even right after we deploy the release and publish the blog post there’s more work to do, small things to fix, and patch releases to prepare. I always celebrate it at home. I recommend you get a good bottle of beer, toast your teammates, and enjoy the moment. You probably want to spend some time with your friends and family after the intensity of a release.\n\n## Does this have an advantage for open source projects?\n\nMost open source projects don’t follow this strict release process. This means it’s up to the leaders to decide when it’s time to release.\n\nI’ve contributed code to other open source projects, and when I see upstream issues that are important but not released I start wondering. If there are people specifically asking “Can you release a new version?” then I’m very skeptical about these projects. I don’t trust any project that doesn't know when the next release is coming out.\n\nPeople can trust open source projects which have a stable release schedule. It’s a sign of a healthy project which is actively developed. I do feel that for open source projects, developing a timed release process is the best option for distributed software. And I now know, it’s something that people love about GitLab.\n\nIn January we’re going to have our 50th monthly release of our project. We’re looking forward to celebrating!\n\nIf you'd like to read more about our release philosophy you can read our previous post, [Why we shift objectives and not release dates at GitLab](/blog/why-we-shift-objectives-and-not-release-dates-at-gitlab/).\n",{"slug":4721,"featured":6,"template":681},"gitlab-release-process","content:en-us:blog:gitlab-release-process.yml","Gitlab Release Process","en-us/blog/gitlab-release-process.yml","en-us/blog/gitlab-release-process",{"_path":4727,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4728,"content":4733,"config":4737,"_id":4739,"_type":17,"title":4740,"_source":18,"_file":4741,"_stem":4742,"_extension":21},"/en-us/blog/feature-highlight-user-preferences",{"title":4729,"description":4730,"ogTitle":4729,"ogDescription":4730,"noIndex":6,"ogImage":947,"ogUrl":4731,"ogSiteName":667,"ogType":668,"canonicalUrls":4731,"schema":4732},"Feature Highlight: User preferences to customize GitLab behavior","Users requested a few customizations to help the UI better fit their daily use. We are happy to share new user preferences in GitLab 8.1.","https://about.gitlab.com/blog/feature-highlight-user-preferences","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature Highlight: User preferences to customize GitLab behavior\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Drew Blessing\"}],\n        \"datePublished\": \"2015-11-05\",\n      }",{"title":4729,"description":4730,"authors":4734,"heroImage":947,"date":4735,"body":4736,"category":14},[4460],"2015-11-05","\n\nIn GitLab 8.0 we worked hard to refine the UI so it is really enjoyable\nto use. After the release we received a lot of positive feedback. However,\nusers requested a few customizations to help the UI better fit their daily use.\nWe considered all of this feedback and are happy to share some new user preferences\nin GitLab 8.1.\n\nAmong these new user preferences are the ability to choose between a fluid or fixed\nwidth layout and the option to choose activity as the default dashboard instead of\nthe project list.\n\n\u003C!-- more -->\n\n## Layout width\n\nGitLab 8.0 introduced a fixed width layout in an attempt to make content\neasier to follow. The fixed width layout on large monitors\nwill have a gray negative space on either side of content.\n\n![Fixed width wide screen](https://about.gitlab.com/images/user_preferences/fixed_width_wide_screen.png)\n\nSome users still like the idea of the fluid layout and now they\nhave a choice.\n\nFrom the GitLab dashboard, go to 'Profile Settings' and then 'Preferences'.\n\nScroll down to the 'Behavior' section and choose 'Fluid' from the 'Layout width'\ndropdown. Save changes and you will now take full advantage of your large screen.\n\n![Fluid width wide screen](https://about.gitlab.com/images/user_preferences/fluid_width_wide_screen.png)\n\n## Default Dashboard\n\nAnother change in GitLab 8.0 was that the old dashboard containing both the\nproject list and activity were split out in to two different pages - 'Projects'\nand 'Activity'. By splitting them out we are able to add some additional scopes\nto each page, such as a tab for starred projects and starred projects' activity.\nBeginning in 8.1 users can choose between four different default dashboard views.\n\nFrom the GitLab dashboard, go to 'Profile Settings' and then 'Preferences'.\n\nScroll down to the 'Behavior' section and choose one of four options from the\n'Default Dashboard' dropdown.\n\n* **Your Projects** This view is the default and shows a list of all projects in which you are a\nmember.\n* **Starred Projects** This view shows a list of projects that you have starred. If you are a member\nof many projects you may want to star a few so this list will display your\nmost common projects.\n* **Your Projects' Activity** This view shows activity for all projects in which you are a member. This is\nsimilar to the previous activity on the dashboard prior to 8.0.\n* **Starred Projects' Activity** This view will show activity only for those projects that you star. Again,\nif you are involved in many projects you may want to star a few so your\nactivity is not so crowded.\n\n## Project view\n\nAlthough not new for GitLab 8.1, it's also worth sharing the 'Project view'\nuser preference. By default, a project's main page will display the Readme\nfile. This is great for first-time visitors who are not familiar with the project.\nHowever, project members that frequent this page may be more interested in the\nrecent activity.\n\nFrom the GitLab dashboard, go to 'Profile Settings' and then 'Preferences'.\n\nScroll down to the 'Behavior' section and choose either 'Readme' or 'Activity'\nin the 'Project view' dropdown.\n\n### Readme View\n\n![Project Readme View](https://about.gitlab.com/images/user_preferences/project_readme.png)\n\n### Activity View\n\n![Project Activity View](https://about.gitlab.com/images/user_preferences/project_activity.png)\n\n## Documentation\n\nWe hope these new user preferences allow users to customize GitLab in a way that\nbest fits their daily use. See the [GitLab 8.1 release post](/releases/2015/10/22/gitlab-8-1-released/)\nfor information on upgrading so you can take advantage of these features today.\nUsers on GitLab.com can take advantage of these features immediately.\n",{"slug":4738,"featured":6,"template":681},"feature-highlight-user-preferences","content:en-us:blog:feature-highlight-user-preferences.yml","Feature Highlight User Preferences","en-us/blog/feature-highlight-user-preferences.yml","en-us/blog/feature-highlight-user-preferences",{"_path":4744,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4745,"content":4751,"config":4755,"_id":4757,"_type":17,"title":4758,"_source":18,"_file":4759,"_stem":4760,"_extension":21},"/en-us/blog/6-reasons-why-pre-is-better-than-post-production-code-review",{"title":4746,"description":4747,"ogTitle":4746,"ogDescription":4747,"noIndex":6,"ogImage":4748,"ogUrl":4749,"ogSiteName":667,"ogType":668,"canonicalUrls":4749,"schema":4750},"6 reasons why pre is better than post production code review","Six good reasons why you should review code before it's being deployed/ released/ merged.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670664/Blog/Hero%20Images/code.png","https://about.gitlab.com/blog/6-reasons-why-pre-is-better-than-post-production-code-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"6 reasons why pre is better than post production code review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2015-08-05\",\n      }",{"title":4746,"description":4747,"authors":4752,"heroImage":4748,"date":4753,"body":4754,"category":14},[4534],"2015-08-05","\n\nCode review is very important. You don't want to run the risk of [technical debt].\nActually doing code review is another matter. Besides the variety of tools and tricks\nfor the act of code review, the timing is vital.\n\n[Quora published a great article] about maintaining velocity in projects.\nThe article is really great but we think that their post production code review\nis timed wrong.\n\n\u003C!-- more -->\n\n## Requirements for Early Review\n\nThe Quora article mentions two things that can go wrong if you do a pre production\ncode review:\nIf you do early code review it has to be fast or it'd undo some of the advantages\nand slow down your release cycle. An easy fix for this is to not wait for particular\npeople, rather just have a number of required reviewers (you can do this with\n[merge request approvals] or just agree on something internally).\n\nSecond, the big picture has to be in scope for you and your reviewers. It's possible\nthat a larger piece of code needs refactoring. If this is the case,\ndo it within the merge request or schedule the refactoring as a separate issue.\n\nHere, we give you six good reasons why you should review code before it's being\ndeployed / released / merged, rather than doing code review on code that is\nin use already.\n\n## 1. It's still fresh\n\nIf you get feedback on something that you recently worked on, you're\nlikely to have the context and structure in mind of that piece of code.\n\nProduction code that is reviewed much later on will require you to do another\ndeep dive into code that you might have not touched in a while. This is inefficient\nand sets you up for failure, as the context is never as clear as it was while you\nworked on it.\n\n## 2. Less Resistance to Change\n\nWhen your code is running in production for some time, seemingly doing what it\nshould, it'll be harder to convince you to change it. You will be more resistant\nto changes suggested by your colleagues.\n\nWith unproven code the \"it works, why change it?\" argument is much harder to make.\n\n## 3. Higher Focus on Quality\n\nAs you will be less resistant to code that is not running successfully yet,\nyour reviewers will be more insistent on the functionality and quality of the\ncode. The code has not proven itself yet, so you can't assume it works,\ninspiring more thorough review.\n\n## 4. Catch mistakes before Production\n\nThis seems obvious, but if you review before code going live, there will be\nmuch less issues on the live code. In turn, this means your software is more\nreliable and you'll fight less with emergency bug-fixes and spend more time\nwriting new features.\n\n## 5. You Must Review\n\nSkipping code review on already deployed code is easy. You just don't do it.\n\nHowever, if you use early code review, you can easily set up a workflow\nthat forces code review. For instance, with [GitLab's Merge Request Approvals],\nyou can require any N of your colleagues to approve a merge request before it's\nmerged into the target branch.\n\nThis way code review can never be skipped, with all the benefits of that.\n\n## 6. Small Reviews > Large Reviews\n\nWe observed that smaller reviews gather much more comments per line of code,\nthan large reviews.\nTypically code that is already in production is reviewed by reviewing piece of\nfunctionality, this tends to be larger than a change.\nThis means that you can expect a more thorough review\non code that is not merged yet, over code that is already live just by the\nline count of the review.\n\n## How do you review?\n\nAs we're always looking to improve code review in GitLab, we're very curious\nto hear what you do with your code, how you review it in your team and how\nwe can improve GitLab to support better code review.\nLet us know in the comments below.\n\n\n[technical debt]: https://en.wikipedia.org/wiki/Technical_debt\n[merge request approvals]: /blog/feature-highlight-merge-request-approvals/\n[GitLab's Merge Request Approvals]: /blog/feature-highlight-merge-request-approvals/\n[Quora published a great article]: http://engineering.quora.com/Moving-Fast-With-High-Code-Quality?share=1\n",{"slug":4756,"featured":6,"template":681},"6-reasons-why-pre-is-better-than-post-production-code-review","content:en-us:blog:6-reasons-why-pre-is-better-than-post-production-code-review.yml","6 Reasons Why Pre Is Better Than Post Production Code Review","en-us/blog/6-reasons-why-pre-is-better-than-post-production-code-review.yml","en-us/blog/6-reasons-why-pre-is-better-than-post-production-code-review",{"_path":4762,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4763,"content":4769,"config":4774,"_id":4776,"_type":17,"title":4777,"_source":18,"_file":4778,"_stem":4779,"_extension":21},"/en-us/blog/how-we-use-gitlab-to-build-gitlab",{"title":4764,"description":4765,"ogTitle":4764,"ogDescription":4765,"noIndex":6,"ogImage":4766,"ogUrl":4767,"ogSiteName":667,"ogType":668,"canonicalUrls":4767,"schema":4768},"How we use GitLab to build GitLab","Have you ever wondered how GitLab employees use GitLab? Well read this article and get the inside scoop!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671577/Blog/Hero%20Images/dog-food.jpg","https://about.gitlab.com/blog/how-we-use-gitlab-to-build-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we use GitLab to build GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Karen Carías\"}],\n        \"datePublished\": \"2015-07-07\",\n      }",{"title":4764,"description":4765,"authors":4770,"heroImage":4766,"date":4772,"body":4773,"category":14},[4771],"Karen Carías","2015-07-07","\n\nHave you ever wondered how GitLab employees use GitLab? Before I worked here, I always wondered how some products are used for their own creation.\nThis actually has a name and it's called [dogfooding](https://en.wikipedia.org/wiki/Eating_your_own_dog_food).\n\nSome months ago I went to an event in Facebook Headquarters and it called my attention that they use Facebook for everything, including registering guests and getting feedback.\nMost companies have certain technical departments that will work on making everything more “user friendly” or less technical for the rest of the company.\nIn GitLab, we all try to learn how to use our platform and do everything that’s technical ourselves.\nThat allows us to test our product and have more confidence in it.  \n\n\u003C!--more-->\n\n## Using GitLab.com\nWe use [GitLab.com](https://gitlab.com) for any work that can be done in the open.\nThat includes our [GitLab website](https://gitlab.com/gitlab-com/www-gitlab-com), [GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce), and more.\nWe add Issues and Merge Requests for anything related to this.\nIt is a [public repository](https://gitlab.com), so everybody can contribute to it (not only employees).\n\n![GitLab.com](https://about.gitlab.com/images/gitlab-com.png)\n\n## dev.GitLab.org\nWe have a different platform for GitLab development.\nThe idea is for our developers and team to work there with things that are sensitive because customers or security issues are involved.\nWe have different projects for different purposes; Documentation, Organization, our different services, etc.\nStill, we try to work as much as possible in the [open](https://gitlab.com).\n\nOnce you become part of the GitLab team, you are granted access to the beta site dev.GitLab.org.\nAt the beginning it’s a little bit confusing to be using both sites and knowing when to use each; but with time, it becomes more natural.\nI personally decided to customize each site with a different color so that it wouldn't be confusing anymore.\nWe can use our beta site for tests and all of our version release actions. It is updated daily with the latest version, so that we are constantly testing it.\nOur new logo was tested there before it was released. We all agreed that it looked very nice.\n\n![dev.gitlab.org](https://about.gitlab.com/images/dev-gitlab.png)\n\n## Our employee Handbook\nOur onboarding is very simple and [accessible for anyone](/handbook/).\nSince we are open source, it is public and once you become part of the team, you should read it and if you have any questions, you may use Slack to ask.\nIt’s very simple and easy to use. If it’s written, I guess there’s no confusion.\n\n![Handbook](https://about.gitlab.com/images/handbook.png)\n\n## Communication\nWe use Slack for general information, emails for non-urgent information, and Issues for things that need to be improved or solved.\nWe usually mention people and then we let the people assign the issues to themselves.\n\nThe way we use issues is very interesting because we add them in the repository that is mostly related to the subject the issue is about.\nWe add all the links and information that we have and mention the people involved.\nEverybody comments, we work on the issues and then we link to the Merge Request where the issue is solved.\n\nThe improvements are added through Merge Requests and we link the issue where the improvement is suggested, if it applies.\n\nTo help improve our communication and to work on our team building, every year, there's an event that the entire team will attend.\nIt's a great opportunity to integrate the team and to get to know each other in person.\nThis year, we are all going to [OSCON](http://www.oscon.com/open-source-eu-2015) in The Netherlands.\nIt will be a great opportunity to interact and share some quality time with the team.\n\n![OSCON](https://about.gitlab.com/images/oscon.png)\n\nSo, how do you use the product at the company where you work at?\n",{"slug":4775,"featured":6,"template":681},"how-we-use-gitlab-to-build-gitlab","content:en-us:blog:how-we-use-gitlab-to-build-gitlab.yml","How We Use Gitlab To Build Gitlab","en-us/blog/how-we-use-gitlab-to-build-gitlab.yml","en-us/blog/how-we-use-gitlab-to-build-gitlab",{"_path":4781,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4782,"content":4788,"config":4793,"_id":4795,"_type":17,"title":4796,"_source":18,"_file":4797,"_stem":4798,"_extension":21},"/en-us/blog/why-ship-on-premises-in-the-saas-era",{"title":4783,"description":4784,"ogTitle":4783,"ogDescription":4784,"noIndex":6,"ogImage":4785,"ogUrl":4786,"ogSiteName":667,"ogType":668,"canonicalUrls":4786,"schema":4787},"Why deploy on-premises in the SaaS era?","Take a moment to view some highlights of the reasons why deploying on-premises in SAAS era is not such a bad idea after all.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684779/Blog/Hero%20Images/on_premises.jpg","https://about.gitlab.com/blog/why-ship-on-premises-in-the-saas-era","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why deploy on-premises in the SaaS era?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haydn Mackay\"}],\n        \"datePublished\": \"2015-02-12\",\n      }",{"title":4783,"description":4784,"authors":4789,"heroImage":4785,"date":4791,"body":4792,"category":14},[4790],"Haydn Mackay","2015-02-12","\nWhen I started in the software industry 10 years ago the idea of\nputting your company's crown jewels (source code) on someone else's\ninfrastructure was preposterous. It was typically the domain of\nopen-source projects or hobby programmers looking to avoid server\nmanagement, taking backups, etc. Although some services have been\naround since the late 90's it wasn't until the [second half of the last\ndecade](http://en.wikipedia.org/wiki/Comparison_of_source_code_software_hosting_facilities) that 3rd party code hosting became more acceptable, especially\namong SME's. There's been a [proliferation of providers](http://blog.profitbricks.com/top-source-code-repository-hosts/) in the space since.\n\nThe advantages of SaaS over on-premises deployments has been written\nabout ad nauseam and there's certainly good reasons why but let's take\na moment to highlight some of the reasons why on-premises is not such a\nbad idea after all.\n\n\u003C!-- more -->\n\n## Containment\nFirewalls exist to protect private networks from unauthorized access.\nContaining your companies IP to within their own network puts the\nsecurity onus squarely on them and they can lock it down like Fort Knox\nshould they wish. Let's not forget what [happened to poor old Code\nSpace](http://www.infoworld.com/article/2608076/data-center/murder-in-the-amazon-cloud.html). Lots of lessons learned after the attack but with a hosting\nprovider you're still putting the kids in someone else's car and you're\nnot driving.\n\n## Integrations – LDAP / AD and others\nManaging permissions and access controls to code repositories is an\nimportant responsibility. Having the ability to authenticate users\nagainst an LDAP or Active Directory server makes this task less\ndaunting because they contain the single source of truth about an\nemployee's status. Furthermore, synchronizing LDAP and AD groups to your\ndevelopment project groups automates access controls by ensuring up to\ndate visibility levels. Using a multi tenant hosting provider makes\nauthentication against LDAP and AD servers impossible.\n\nOn premise servers are also much more conducive to integrating with\nother tools in your CD pipeline such as ALM, PLM, [Agile](/solutions/agile-delivery/) and Automation\ntools. Hosted services usually provide a small selection of  tool\nintegrations to choose from and API access is limited or nonexistent.\n\n## Control\nThere's something to be said about knowing where your code is stored,\nhow it's backed-up, which servers are managing the repositories and\nwhat the failover plan is. Being at the mercy of your hosting provider\nreduces that level of control and introduces a new level of risk.\nAlthough unscheduled downtime of hosted services is few and far\nbetween, it still happens and when it does, thousands of developers are\nleft twiddling their thumbs. Most large development organizations are\nspread across multiple time zones and scheduling maintenance windows\ncan be tricky. With an on premise server, you're in control of these\nwindows.\n\n## Performance\nI've seen hundreds of RFP's over the years and every one of them\nincluded a section on performance. Performance is one of the biggest\ndrivers behind a migration off legacy systems after all. Having your\nrepositories in a data center that's local to your developers reduces\nlatency, speeding up push / pull times and especially initial clone\ntimes.  As repositories grow large, latency exacerbates performance\ndegradation making on-prem servers more conducive to big code bases.\n\n## Choice and Flexibility\nOn-premises deployments can be installed on physical servers,\nvirtualized servers (dedicated or shared), purpose-built appliances and\nvirtualized appliances. These aren't available with hosted solutions.\nLikewise, most on-premises servers can be deployed on a variety of\noperating systems and there's more choice of on-premises solutions in\ngeneral.\n\n## Retrieval\nGetting your IP back from cloud vendors that store data in proprietary formats can be a costly and lengthy process. No such trouble with on-premises.\n\n## Conclusion\nAlthough there's plenty of good reasons for using a hosted solution,\nthe advantages of on-premises deployments should not be overlooked.\nGitLab is the most adopted on-premises solution for developer\ncollaboration, deployed at over 100,000 organizations worldwide.\n",{"slug":4794,"featured":6,"template":681},"why-ship-on-premises-in-the-saas-era","content:en-us:blog:why-ship-on-premises-in-the-saas-era.yml","Why Ship On Premises In The Saas Era","en-us/blog/why-ship-on-premises-in-the-saas-era.yml","en-us/blog/why-ship-on-premises-in-the-saas-era",{"_path":4800,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4801,"content":4807,"config":4812,"_id":4814,"_type":17,"title":4815,"_source":18,"_file":4816,"_stem":4817,"_extension":21},"/en-us/blog/why-move-to-a-single-code-collaboration-tool",{"title":4802,"description":4803,"ogTitle":4802,"ogDescription":4803,"noIndex":6,"ogImage":4804,"ogUrl":4805,"ogSiteName":667,"ogType":668,"canonicalUrls":4805,"schema":4806},"Why move to a single code collaboration tool?","Moving to a single code coolaboration tool streamlines process and allows you to free up valuable resources. Learn more here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684346/Blog/Hero%20Images/one_instance.jpg","https://about.gitlab.com/blog/why-move-to-a-single-code-collaboration-tool","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why move to a single code collaboration tool?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marc Radulescu\"}],\n        \"datePublished\": \"2015-02-06\",\n      }",{"title":4802,"description":4803,"authors":4808,"heroImage":4804,"date":4810,"body":4811,"category":14},[4809],"Marc Radulescu","2015-02-06","\n\nSay your department has five teams, and each team is running its own code collaboration tool.\nOne of the teams is still using SVN.\nOther teams have moved on to a Distributed Version Control Solution (DVCS), but the teams all use different solutions.\n\nAll the developers are happy at this time. \nThey get to use their own workflow, the one they prefer.\nThe team leads get to manage tools that they are already comfortable with.\nYou don't have to deal with people complaining that their tool sucks.\n\nBut underneath all that happiness, trouble slowly brews.\n\n\u003C!-- more -->\n\n## Is there anything actually wrong?\n\nThe only reason why your teams are happy, is that someone is putting extra effort in keeping your setup together.\n\nFirst of all, the teams are having trouble collaborating.\nWhen one developer gets involved in another team's project, they need to accommodate their workflow, familiarize themselves with the tool and have all their credentials set up.\nYour admins are spending time facilitating this.\n\nSecond, code security is complicated. \nYou've got five systems to patch for security updates and five permission schemas to enforce.\nYour admins are spending time updating five installations in a timely manner.\n\nThird, integrating these tools into your tool stack always needs extra work.\nThere's five plugins, or APIs, or services to maintain.\nYour admins spend time keeping the integration with the tool stack working.\n\nFourth, is anyone paying for support over these installations?\nIf so, that's five agreements to maintain and bother with, and five vendors to maintain a relationship with.\n\n## You can free up resources by consolidating to a single tool.\n\nThis way, you're improving collaboration between teams.\nWith GitLab Enterprise Edition for instance, all the project master needs to do is press two buttons, and their project is shared with another team.\nFor a front-facing instance, just [switch](http://doc.gitlab.com/ce/public_access/public_access.html) to \"internal\" privacy and your project is now [innersourced](/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/)\n\nKeep security management high level.\nOne installation to patch, [one permissions schema](http://doc.gitlab.com/ce/permissions/permissions.html).\n\nYou're also freeing up your admins from maintaining five different installations.\nThey don't need to schedule downtime five times anymore.\n\nLastly, keep the overhead low on the commercial side.\nOnce point of contact for your questions, one contract to bother legal with, one company to address when you want a new feature.\n\n## There are some caveats, but they can be addressed.\n\nSure, there might be caveats.\n\nYou now have a single solution.\nHowever, that solution is scalable with [Reference Architectures](https://docs.gitlab.com/ee/administration/reference_architectures/) and you can set up disaster recovery if you want.\n\nYou might think that one tool restricts you to just one workflow.\nHowever, Git allows for a number of different workflows for your teams to choose from.\nAnd if they are not comfortable with any, feel free to recommend them the [GitLab flow](/topics/version-control/what-is-gitlab-flow/).\n\n## There are several next steps to consider.\n\nStart by taking a look at what GitLab has to offer.\n\nWith a subscription, you will give you access to a [feature-rich](/features/#compare) self-managed solution capable of scaling to thousands of projects and users.\n\nWe can help you migrate your projects from other tools such as [SVN](http://doc.gitlab.com/ce/workflow/migrating_from_svn.html) or [GitHub](http://doc.gitlab.com/ce/workflow/import_projects_from_github.html) with ur built-in GitHub importer.\nWe will help you set a GitLab instance up.\n\nFor any further questions [contact sales](/sales/) and give us details on your current layout.\n",{"slug":4813,"featured":6,"template":681},"why-move-to-a-single-code-collaboration-tool","content:en-us:blog:why-move-to-a-single-code-collaboration-tool.yml","Why Move To A Single Code Collaboration Tool","en-us/blog/why-move-to-a-single-code-collaboration-tool.yml","en-us/blog/why-move-to-a-single-code-collaboration-tool",{"_path":4819,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4820,"content":4826,"config":4830,"_id":4832,"_type":17,"title":4833,"_source":18,"_file":4834,"_stem":4835,"_extension":21},"/en-us/blog/7-git-personalities",{"title":4821,"description":4822,"ogTitle":4821,"ogDescription":4822,"noIndex":6,"ogImage":4823,"ogUrl":4824,"ogSiteName":667,"ogType":668,"canonicalUrls":4824,"schema":4825},"7 Git personalities, which one are you?","Working on an open source projects we receive many merge and pull requests and see a number of different git personalities. Do you recognize yourself?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684330/Blog/Hero%20Images/git_personalities.jpg","https://about.gitlab.com/blog/7-git-personalities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"7 Git personalities, which one are you?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2015-01-27\",\n      }",{"title":4821,"description":4822,"authors":4827,"heroImage":4823,"date":4828,"body":4829,"category":14},[4534],"2015-01-27","\n\nWorking on an open source project, we're so lucky to receive many merge -and\npull requests. Not unlike dating, we see a number of different _git personalities_.\nDo you recognize yourself or one of your colleagues in one of them? Let us know in the comments\nor tweet about it with #gitlab.\n\n\u003C!-- more -->\n\n## 1. The Build Breaker\n\n> Oh this is a small change, I'll just push it to master..\n\nWe all do it. A small change, preferably at the end of the week, it's not\ngoing to hurt anyone..\n\nHow wrong you are. You just broke the build for everyone\nelse. Either you'll have to fix this yourself quickly or you're leaving your\nteam to clean up your mess.\n\n### Fixing the breaker\n\nRun relevant and fast tests locally, always work with merge requests and only merge when the build\npasses.\n\n## 2. The Repeater\n\n> ```\n> bf30a5b - cool new feature\n> dfd934s - cool new feature\n> 98dfjek - cool new feature\n> ```\n\nIf git history was like actual history, the repeater's history books would only\ncontain only a single sentence, repeated ad infinitum. The repeater repeats a single\nsentence with every commit. To know what a Repeater did, the SHA tells you\nas much as the commit message.\n\n### Fixing the broken record\n\nWrite clear commit messages that highlight the _intent_ of the commit.\nThis makes it easy to navigate through git history, to judge commits\nand find potential sources of problems.\n\n\n## 3. The Wipper\n\nYou thought you were almost done and created a merge request, but still had to\nmake a few more changes. Maybe while making those changes, you could refactor\na bit more. And possibly improve the alignment in some other places and before\nyou know it, your merge request is open for more than a month.\n\nIf this sounds like you, you might be a Wipper. The Wipper leaves their merge\nrequests on WIP forever. Ask yourself:\n\n> Do you believe that your work will ever stop being in progress?\n\n### Merging the Wip\n\nTry to follow test-driven development. Start with high-level tests and go from\nthere. When those tests pass, you're done. Stop it. Ask someone to review and\nmerge it and start with something new. Progress is many small steps.\n\n## 4. The Premature committer\n\n> ```\n> bf30a5b - add capital\n> 9d5550a - add missing period\n> 179c001 - remove 'the'\n> 983hfk2 - remove trailing space\n> ```\n\nYoung premature committers save their reports every sentence. Growing up\nwith the magic of git, they took it one step further and commit every singly\ntiny change.\n\nPremature committers and rebasers are natural enemies and are known to\nannoy one another. Don't put them in the same team if you can prevent it.\n\n### Squashing the premature committer\n\nLet's be honest, premature committer, you don't really push every commit to\nthe remote, do you? If not, then you win nothing by committing every single change!\n\nIf that doesn't wake you up, you should know that the next remedy is rebasing..\n\n## 5. The Rebaser\n\nAdding a new import utility to an open source project? UI, tests, back-end\nall in place? Awesome! In one commit? Not awesome.\n\nYou probably mean well, Rebaser. You write beautiful code and you know some\ngit-fu. But remember that with great power comes great responsibility:\nIf your feature breaks it'll be more likely to be stripped out in its entirety\nas a single commit, rather than having someone go through your history to see\nwhere it went wrong.\n\n### Grounding the Rebaser\n\nYou're probably forgiven. Most open source projects welcome you, but\nkeep your merge requests reasonable. We use git for a reason.\n\n## 6. The Merger\n\n> ```\n> 00fd402 - Merge branch 'master' into 'feature_x'\n> 34jkdi9 - Merge branch 'master' into 'feature_x'\n> svc98u2 - Merge branch 'master' into 'feature_x'\n> ```\n\nAs the Merger, you worked really hard on that new feature. At night or during\nlunch breaks: where everyone is being paid for this, you are not. That comes\nwith a cost, you start to run behind on changes and the easiest solution?\nJust merge in master!\n\nThe Merger's merge request will merge, that's for sure, but it's not pretty.\n\n### Cancelling the Merger\n\nKeep your merge requests small and only start on what you can actually finish.\nOnly merge when needed. Not even before the merge request.\nJust make sure it merges cleanly.\n\n## 7. The Denier\n\nThe Denier is the evil twin of the Build Breaker.\n\nBut really, the tests were all green on your machine! It only broke after\nsomeone else did a commit! Or even worse: the failing test is not related to\nyour code!\n\nSure, Denier, sure. We'll see what `git bisect` tells us..\n\n### Admitting being a Denier\n\nYou are responsible for more than your contribution. You are responsible for\nthe healthy continuation of the project. Show you responsibility, be proud\nto be solver of problems, not a creator of issues and fix those failing tests.\nEveryone will like you a little bit more.\n",{"slug":4831,"featured":6,"template":681},"7-git-personalities","content:en-us:blog:7-git-personalities.yml","7 Git Personalities","en-us/blog/7-git-personalities.yml","en-us/blog/7-git-personalities",{"_path":4837,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4838,"content":4844,"config":4848,"_id":4850,"_type":17,"title":4851,"_source":18,"_file":4852,"_stem":4853,"_extension":21},"/en-us/blog/github-enterprise-vs-gitlab-enterprise-edition",{"title":4839,"description":4840,"ogTitle":4839,"ogDescription":4840,"noIndex":6,"ogImage":4841,"ogUrl":4842,"ogSiteName":667,"ogType":668,"canonicalUrls":4842,"schema":4843},"GitHub Enterprise vs GitLab Enterprise Edition","In this post we discuss the advantages of running GitLab Enterprise Edition, our paid version of GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683801/Blog/Hero%20Images/city_highway_at_night.jpg","https://about.gitlab.com/blog/github-enterprise-vs-gitlab-enterprise-edition","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitHub Enterprise vs GitLab Enterprise Edition\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2015-01-20\",\n      }",{"title":4839,"description":4840,"authors":4845,"heroImage":4841,"date":4846,"body":4847,"category":14},[762],"2015-01-20","We get asked a lot how GitLab compares to GitHub Enterprise Edition, the version of GitHub that you can run on your own servers.\nIn this post we'll briefly discuss what we see as the advantages of running GitLab Enterprise Edition, our paid version of GitLab.\nThe three main advantages are that GitLab focuses on enterprise needs, is easier to operate and scale and it is more inclusive.\n\n\u003C!-- more -->\n\n## Focuses on enterprise needs\n\nGitLab was created as a tool for larger organizations from the start.\nWe want to keep it as simple as possible but not simpler.\nYou should be able to participate in issues without getting read access to the repository.\nSome branches are more important than feature branches and should be [protected against force pushes](/blog/keeping-your-code-protected/).\nAnd if you want to rebase your branches on master just before merging this should be possible from the UI.\n\nKeeping the permissions up to date is a constant struggle in larger organizations.\nThat is why GitLab allows you to synchronize groups with your LDAP server.\nAnd collaboration is a much harder problem when working across organizational boundaries.\nTo enable this 'inner-sourcing' GitLab has internally visible projects that are visible to all signed in users.\n\n## Easier to operate and scale\n\nGitLab was developed to run on your own server from the start.\nIt's architecture is simple but powerful.\nIt is easy to change where repositories are stored so you can store them on a separate fileserver (NFS) or network attached storage (NAS).\nGitLab allows you to modify it to your needs.\nFor example, you can install a different type of web-server.\nThe application server is stateless, allowing you to run multiple active servers.\nThis makes scaling and high availability much easier to handle.\n\nAt the same time this simple and powerful architecture also enables good performance.\nOne server can handle 25,000 active users, the best performance in the industry.\nIt can run on virtualized hardware but you can also run it directly on metal.\n\nIf you want to make changes to GitLab, the Enterprise Edition license allows this.\nBut you'll find that we're very happy to accept contributions and merge your changes upstream if they make life better for everyone.\n\n## More inclusive\n\nGitLab is an open source project with more than 700 contributors that share their improvements.\nThere are more that 100,000 organizations running it of which some sponsor new features.\nThis allows us to keep the cost of GitLab Enterprise Edition very low.\nGitLab Enterprise Edition is great value for money for a tool that includes git hosting, code review, issue tracking, wiki's and [continuous integration](/features/continuous-integration/).\n\nBecause of its great value and easy scalability, you can open up your GitLab instance to everyone in your organisation that needs it.\nSince software is eating the world the people that are involved with software projects are no longer only developers.\nStakeholders in projects need access to the issue tracker and end-users want access to the wiki.\nWith GitHub Enterprise the pricing causes some organizations to limit access to developers.\nWith the affordable pricing made possible by open source, GitLab Enterprise Edition allows collaboration across function groups.\n\n## Conclusion\n\nWe hope the above gives a good overview of the differences between GitHub Enteprise and GitLab Enterprise Edition.\nIf you have any comments, questions or additions feel free to leave them in the comments below or email me at sytse@gitlab.com",{"slug":4849,"featured":6,"template":681},"github-enterprise-vs-gitlab-enterprise-edition","content:en-us:blog:github-enterprise-vs-gitlab-enterprise-edition.yml","Github Enterprise Vs Gitlab Enterprise Edition","en-us/blog/github-enterprise-vs-gitlab-enterprise-edition.yml","en-us/blog/github-enterprise-vs-gitlab-enterprise-edition",{"_path":4855,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4856,"content":4861,"config":4865,"_id":4867,"_type":17,"title":4868,"_source":18,"_file":4869,"_stem":4870,"_extension":21},"/en-us/blog/explaining-gitlab-bugs",{"title":4857,"description":4858,"ogTitle":4857,"ogDescription":4858,"noIndex":6,"ogImage":947,"ogUrl":4859,"ogSiteName":667,"ogType":668,"canonicalUrls":4859,"schema":4860},"Explaining GitLab bugs","This blog post will give a short overview on how GitLab bugs are handled, and what you can do after you identify a potential bug in GitLab.","https://about.gitlab.com/blog/explaining-gitlab-bugs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Explaining GitLab bugs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marc Radulescu\"}],\n        \"datePublished\": \"2014-12-08\",\n      }",{"title":4857,"description":4858,"authors":4862,"heroImage":947,"date":4863,"body":4864,"category":14},[4809],"2014-12-08","\n\nThis blog post will give a short overview on how GitLab bugs are handled, and what you can do after you identify a potential bug in GitLab.\n\nThe GitLab community differentiates between three different types of bugs:\n\n - Security bugs\n - Regression bugs\n - Feature bugs\n\n\u003C!-- more -->\n\nThe image below illustrates the big picture:\n\n[![screenshot](https://about.gitlab.com/images/gitlab_bugs/bugs_alt.png)](/images/gitlab_bugs/bugs_alt.png)\n\n## Security bugs\n\nSecurity bugs are system vulnerabilities that can be exploited to allow a user to gain unauthorized access to the GitLab server.\nThe GitLab B.V. team always treats them as top priority.\nWe give feedback within 1-2 days of notice.\nDepending on the severity of the vulnerability, we will either patch GitLab, or fix the issue in the next minor release.\n\nIf you find a security bug in GitLab, please make sure to use [responsible disclosure](/security/disclosure/), and reach out to the GitLab team via [support.gitlab.com](https://support.gitlab.com/).\n\n## Regression bugs\n\nRegression bugs are bugs in the functionality of GitLab, that are unknowingly introduced in a new release.\nThese refer to features which used to work in an older version, but which are bugged in the current release.\nRegression bugs are treated with priority.\nWe assess the impact of the regression bug and either create a patch or, more frequently, include the fix in the next minor release.\n\nIf you identify a regression bug, please share it to the GitLab community either via [Twitter](https://twitter.com/gitlabhq), or by posting it in the [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues).\n\n## Feature bugs\n\nGitLab's features don't cover all use and corner cases, so you might come across a feature that behaves different from what you'd expect.\nIf this is the case, and if the unexpected behavior is not a regression, it is considered a feature bug.\nDepending on the impact on GitLab's functionality, fixing this kind of bug might be considered a priority.\nBefore announcing it the GitLab issue tracker, please make sure to double-check the community and our teams' comments on the feature on the feedback tracker, on the changelog and in the release blog post.\n\nIf you have a specific corner case that is not covered by the feature, please use the [feedback tracker](http://feedback.gitlab.com/forums/176466-general) to bring it to the community's attention.\n\nIf your use case is generic, and the feature is obviously buggy, please report it in the [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues).\n\n##Contributing\n\nThe majority of GitLab bugs are found and fixed by the GitLab community.\nThere are more than 600 external contributors already.\nWhenever you find a bug in GitLab, you can also [contribute](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md) the fix, and add your contribution in the [changelog](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG).\n",{"slug":4866,"featured":6,"template":681},"explaining-gitlab-bugs","content:en-us:blog:explaining-gitlab-bugs.yml","Explaining Gitlab Bugs","en-us/blog/explaining-gitlab-bugs.yml","en-us/blog/explaining-gitlab-bugs",{"_path":4872,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4873,"content":4879,"config":4883,"_id":4885,"_type":17,"title":4886,"_source":18,"_file":4887,"_stem":4888,"_extension":21},"/en-us/blog/keeping-your-code-protected",{"title":4874,"description":4875,"ogTitle":4874,"ogDescription":4875,"noIndex":6,"ogImage":4876,"ogUrl":4877,"ogSiteName":667,"ogType":668,"canonicalUrls":4877,"schema":4878},"How GitLab Permissions and Protected Branches Keep Your Code Safe","At GitLab we believe that by preventing force pushes and by stimulating code review practices, mistakes can be easily avoided and code quality will improve.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684249/Blog/Hero%20Images/how-permissions-and-protected-branches-keep-your-code-safe.jpg","https://about.gitlab.com/blog/keeping-your-code-protected","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab Permissions and Protected Branches Keep Your Code Safe\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2014-11-26\",\n      }",{"title":4874,"description":4875,"authors":4880,"heroImage":4876,"date":4881,"body":4882,"category":14},[4534],"2014-11-26","\n\nGit is very easy to use and abuse.\nA single `git push --force` command can easily ruin the day for a lot of people:\n\n> As a result, these [186 Jenkins'] repositories have their branch heads rewinded to point to older commits, and in effect the newer commits were misplaced after the bad git-push.\n\nOn November 10, 2013, a Jenkins developer had [accidentally forced pushed](http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th) to 186 repositories,\nbringing them back two months in time.\n\nThe power that Git gives you to change history is great when you're working alone,\nbut potentially disrupting if you're working with others, as shown by a poor Jenkins developer.\nWhen you're working with others, not only do you not want to allow `git push --force`,\nbut before anything is committed to the main repository or branch, the **code should be reviewed**.\n\nAt GitLab we believe that by preventing force pushes and by stimulating [code review](/solutions/source-code-management/) practices,\nmistakes can be easily avoided and code quality will improve.\nTo make it easier to work together with code and Git we have created a surprisingly simple permission system,\nbuilt on top of an elegant authorization method.\n\n\u003C!--more-->\n\n## Read, Write\n\nPermissions in GitLab are fundamentally defined around the idea of having read or write permission to the repository and branches.\nNot only is this an easy-to-grasp concept, it doesn't add any unnecessary complexity to permission management while still offering granular access control.\nBy naming our permissions after their role within a project, it immediately becomes clear what each permission is intended for. **In GitLab, developers are called _Developer_**.\n\n\nIn our experience, this covers almost all cases and can be fitted to any organisation easily.\n\n- Guest     - No access to code\n- Reporter  - Read the repository\n- Developer - Read/Write to the repository\n- Maintainer - Read/Write to the repository + partial administrative capabilities\n- Owner     - Read/Write to the repository + full administrative capabilities\n\nThe permissions are named to reflect their purpose. A user with the lowest private permission _Guest_\nis only able to make use of the issues in a project and does not have read access to the code;\na guest of the project.\n\nThe _Reporter_ permission has the same abilities, but also has read access to the code,\nmeaning they can fork the project.\nThis is ideal for those that you do not want to be pushing to your repository,\nbut still want to give access to the code and give the option to fork off.\n\nAs the name implies, developers on a project should get the role _Developer_.\nAny developer has write permission to the repository, meaning they can branch off,\nwork in and push their own branch back to the repository.\n\nBy defining permission on a read/write basis with clear names,\nit quickly becomes clear which permission or access level should be used to secure a project.\nHowever, they do not solve the issues with modifying history,\nnor do they help with collaboration: anyone can (force) push to any branch (such as the master or default branch).\n\n## Protecting your code with protected branches\n\n\nTo stop people from messing with history or pushing code without review, we've created **protected branches** to add a layer of branch protection. A protected branch does three simple things:\n\n- it prevents pushes from everybody except users with Maintainer permission\n- it prevents _anyone_ from force pushing to the branch\n- it prevents _anyone_ from deleting the branch\n\nYou can make any branch a protected branch. We make the master branch a protected branch by default, but you can turn that off.\n\n[![protected branches in GitLab](https://about.gitlab.com/images/protected_branches.png)](/images/protected_branches.png)\n\n***We use protected branches on the [GitLab repository](https://gitlab.com/gitlab-org/gitlab-ce) to protect our release branches***\n\nNow, if you want to contribute code to a protected branch as a developer, you can simply push your feature branch and **create a merge request** towards the protected branch. History is protected and the code gets reviewed before it's merged.\n\nNote that even _Maintainer_ is not able to force push to or delete a protected branch. We believe in a simple solution:\n\n> Do not let anyone change the history of a shared branch. Revert changes in the present.\n\nYou can easily add a commit on top of history to revert earlier changes.\nThis is much easier to work with than changes in history on top of which people already committed.\nIn addition, you probably do not want to delete such an important branch, hence the inability to remove it.\n\n\n## How we define permissions\n\nBy basing permissions on simple principles and adding protected branches,\nGitLab allows you to set up any type of workflow, while protecting your code from easily made mistakes.\nUnderlying this elegant scheme is a surprisingly simple authorization gem,\n[Six](https://gitlab.com/dzaporozhets/six).\n\nIn a single class `Ability`, we have defined a number of class methods to set the permissions.\nFor instance, for _Developer_:\n\n```\n# app/models/ability.rb:139\ndef project_dev_rules\n  project_report_rules + [\n    :write_merge_request,\n    :write_wiki,\n    :modify_issue,\n    :admin_issue,\n    :admin_label,\n    :push_code\n  ]\nend\n```\nSix has defined an `allowed?` method that check whether a permission exists for a certain object,\nbased on the abilities that you've defined for that class (such as above for _Developer_).\nTo make use of a similar syntax as the often-used [Cancan](https://github.com/ryanb/cancan) authorization gem, you can define a similar method with Six:\n\n```\n# app/models/user.rb:351\ndef can?(object, action, subject)\n  abilities.allowed?(object, action, subject)\nend\n```\n\nThen all we have to do is check the permission wherever we need it.\nFor instance to check whether someone is allowed to destroy a snippet:\n\n```\ndef destroy\n  return access_denied! unless can?(current_user, :admin_personal_snippet, @snippet)\n  @snippet.destroy\n  redirect_to snippets_path\nend\n```\n\nBy using the plain-ruby approach of [Six](https://gitlab.com/dzaporozhets/six) you get a very flexible\nand expendable authorization solution.\nIn GitLab we leverage this to create easy to understand permissions\nthat reflect how most organisations use GitLab.\n\n## About GitLab\n\nInterested in trying GitLab's protected branches?\nYou can try GitLab by [downloading](/install/) the Community Edition and installing it on your own server or by signing up to our free, unlimited GitLab instance [GitLab.com](https://gitlab.com/users/sign_up).\n\nFor support, deep LDAP integration, git hooks, Jenkins integration and more enterprise features, check out [GitLab Enterprise Edition](/features/#enterprise).\n\nFor more on Git workflows, read our article on [GitLab Flow](/topics/version-control/what-is-gitlab-flow/).\n",{"slug":4884,"featured":6,"template":681},"keeping-your-code-protected","content:en-us:blog:keeping-your-code-protected.yml","Keeping Your Code Protected","en-us/blog/keeping-your-code-protected.yml","en-us/blog/keeping-your-code-protected",{"_path":4890,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4891,"content":4896,"config":4900,"_id":4902,"_type":17,"title":4903,"_source":18,"_file":4904,"_stem":4905,"_extension":21},"/en-us/blog/feature-highlight-git-hooks",{"title":4892,"description":4893,"ogTitle":4892,"ogDescription":4893,"noIndex":6,"ogImage":947,"ogUrl":4894,"ogSiteName":667,"ogType":668,"canonicalUrls":4894,"schema":4895},"Feature highlight: Git Hooks in GitLab Enterprise Edition","Sometimes you need additional control over pushes to your repository. For each project you can have unique Git Hooks.","https://about.gitlab.com/blog/feature-highlight-git-hooks","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Feature highlight: Git Hooks in GitLab Enterprise Edition\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2014-08-25\",\n      }",{"title":4892,"description":4893,"authors":4897,"heroImage":947,"date":4898,"body":4899,"category":14},[4534],"2014-08-25","\n\nSometimes you need additional control over pushes to your repository. GitLab already offers protected branches. But there are cases when you need some specific rules like preventing git tag removal or enforcing a special format for commit messages. GitLab Enterprise Edition offers a user-friendly interface for such cases.\n\nFor each project you can have unique Git Hooks. You can set them by going to Project settings -> Git Hooks.\n\n![Git Hooks](https://about.gitlab.com/images/features/git_hooks.png)\n\n\u003C!--more-->\n\nHere you can simply set a regular expression that requires your rule in a commit message. For instance, if you want every commit to reference a JIRA issue such as `JIRA-123`, you could use an expression such as `/JIRA\\-\\d+/`.\n\nIn addition, you can prevent users from deleting tags through pushes.\n\nWe're very excited about Git Hooks and are looking to add more. If you are a customer of GitLab and require a Git Hook, [tell us](https://support.gitlab.com/) and we can implement it for free.\n",{"slug":4901,"featured":6,"template":681},"feature-highlight-git-hooks","content:en-us:blog:feature-highlight-git-hooks.yml","Feature Highlight Git Hooks","en-us/blog/feature-highlight-git-hooks.yml","en-us/blog/feature-highlight-git-hooks",{"_path":4907,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4908,"content":4913,"config":4918,"_id":4920,"_type":17,"title":4921,"_source":18,"_file":4922,"_stem":4923,"_extension":21},"/en-us/blog/feature-highlight-groups",{"title":4909,"description":4910,"ogTitle":4909,"ogDescription":4910,"noIndex":6,"ogImage":947,"ogUrl":4911,"ogSiteName":667,"ogType":668,"canonicalUrls":4911,"schema":4912},"GitLab Feature Highlight: Groups","GitLab groups allow you to group projects into directories and give users access to several projects at once.","https://about.gitlab.com/blog/feature-highlight-groups","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Feature Highlight: Groups\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jacob Vosmaer\"},{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2014-06-30\",\n      }",{"title":4909,"description":4910,"authors":4914,"heroImage":947,"date":4916,"body":4917,"category":14},[4915,4534],"Jacob Vosmaer","2014-06-30","\n\nGitLab is a massive open source project with over 600 contributors, all working together to create an amazing platform to collaborate on code. Every month on the 22nd, a new version of GitLab is released, and every month new features are added.\nTo make you aware of the power of GitLab, we walk through some of its features in these blog posts.\n\n![Barry effectively has 'Master' access to GitLab CI now](https://about.gitlab.com/images/feature_groups/override_access_level.png)\n\nWe start by looking at GitLab Groups. GitLab groups allow you to group projects into directories and give users access to several projects at once.\n\n\n\u003C!--more-->\n\nWhen you create a new project in GitLab, the default namespace for the project is the personal namespace associated with your GitLab user.\nBelow we will see how to create groups, put projects in groups and manage who can access the projects in a group.\n\n## How to create GitLab groups\n\nYou can create a group by going to the 'Groups' tab of the GitLab dashboard and clicking the 'New group' button.\n\n![Click the 'New group' button in the 'Groups' tab](https://about.gitlab.com/images/feature_groups/new_group_button.png)\n\nNext, enter the name (required) and the optional description and group avatar.\n\n![Fill in the name for your new group](https://about.gitlab.com/images/feature_groups/new_group_form.png)\n\nWhen your group has been created you are presented with the group dashboard feed, which will be empty.\n\n![Group dashboard](https://about.gitlab.com/images/feature_groups/group_dashboard.png)\n\nYou can use the 'New project' button to add a project to the new group.\n\nNote that there's also the option to [create subgroups and top-level groups](https://docs.gitlab.com/ee/user/group/manage.html#transfer-a-group).\n\nAfter you create a group, here are a few other things you can do with it:\n\n- Adjust user visibility level\n- Share projects with groups\n- Control project access\n- Transfer projects\n- Create personal projects\n\n## How to transfer an existing project into a group\n\nYou can transfer an existing project into a group you own from the project settings page.\nFirst scroll down to the 'Dangerous settings' and click 'Show them to me'.\nNow you can pick any of the groups you manage as the new namespace for the group.\n\n![Transfer a project to a new namespace](https://about.gitlab.com/images/feature_groups/transfer_project.png)\n\nGitLab administrators can use the admin interface to move any project to any namespace if needed.\n\nUpdate: For more info, check out tutorials in the docs on [moving a personal project to a group](https://docs.gitlab.com/ee/tutorials/move_personal_project_to_a_group.html) and [converting a personal namespace into a group](https://docs.gitlab.com/ee/tutorials/convert_personal_namespace_into_group.html).\n{: .alert .alert-info .text-center}\n\n## How to add users to a group\n\nOne of the benefits of putting multiple projects in one group is that you can give a user access to all projects in the group at the same time with one action.\n\nSuppose we have a group with two projects.\n\n![Group with two projects](https://about.gitlab.com/images/feature_groups/group_with_two_projects.png)\n\nOn the 'Group Members' page we can now add a new user Barry to the group.\n\n![Add user Barry to the group](https://about.gitlab.com/images/feature_groups/add_member_to_group.png)\n\nNow because Barry is a 'Developer' member of the 'Open Source' group, he automatically gets 'Developer' access to all projects in the 'Open Source' group.\n\n![Barry has 'Developer' access to GitLab CI](https://about.gitlab.com/images/feature_groups/project_members_via_group.png)\n\nIf necessary, you can increase the permissions or access level of an individual user for a specific project, by adding them as a Member to the project.\n\n![Barry effectively has 'Master' access to GitLab CI now](https://about.gitlab.com/images/feature_groups/override_access_level.png)\n\nTo see groups where users have a [direct or indirect membership](https://docs.gitlab.com/ee/user/group/manage.html), select \"Your groups.\"\n\n## How to manage group memberships via LDAP\n\nIn GitLab Enterprise Edition it is possible to manage GitLab group memberships using LDAP groups.\nSee [the documentation](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#manage-group-memberships-via-ldap) for more information.\n\n## How to allow only admins to create groups\n\nBy default, any GitLab user can create new groups.\nThis ability can be disabled for individual users from the admin panel.\nIt is also possible to configure GitLab so that new users default to not being able to create groups:\n\n```\n# For omnibus-gitlab, put the following in /etc/gitlab/gitlab.rb\ngitlab_rails['gitlab_default_can_create_group'] = false\n\n# For installations from source, uncomment the 'default_can_create_group'\n# line in /home/git/gitlab/config/gitlab.yml\n```\n\nUpdate: Check out [the documentation](https://docs.gitlab.com/ee/user/group/) for more info on GitLab's latest features for [managing groups](https://docs.gitlab.com/ee/user/group/manage.html), [access control for groups](https://docs.gitlab.com/ee/user/group/access_and_permissions.html), [migrating groups](https://docs.gitlab.com/ee/user/group/import/), [restricting access by domain or email](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-domain), [group file templates](https://docs.gitlab.com/ee/user/group/manage.html#group-file-templates), and more. \n{: .alert .alert-info .text-center}\n",{"slug":4919,"featured":6,"template":681},"feature-highlight-groups","content:en-us:blog:feature-highlight-groups.yml","Feature Highlight Groups","en-us/blog/feature-highlight-groups.yml","en-us/blog/feature-highlight-groups",{"_path":4925,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4926,"content":4931,"config":4935,"_id":4937,"_type":17,"title":4938,"_source":18,"_file":4939,"_stem":4940,"_extension":21},"/en-us/blog/gitlab-flow-screencast",{"title":4927,"description":4928,"ogTitle":4927,"ogDescription":4928,"noIndex":6,"ogImage":947,"ogUrl":4929,"ogSiteName":667,"ogType":668,"canonicalUrls":4929,"schema":4930},"Issues and Merge Requests in GitLab Screencast","We are excited to show you some of the possibilities in our new screencast.","https://about.gitlab.com/blog/gitlab-flow-screencast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Issues and Merge Requests in GitLab Screencast\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2014-03-04\",\n      }",{"title":4927,"description":4928,"authors":4932,"heroImage":947,"date":4933,"body":4934,"category":14},[4534],"2014-03-04","\nGitLab has a very powerful issue tracker that integrates completely with the GitLab workflow, allowing you to reference and even close issues with commits. On top of that, you can easily comment on someone's code line by line, integrate GitLab CI, reference colaborators, vote for or against merge requests and much more. \nWe are excited to show you some of the possibilities in our new screencast.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"//www.youtube.com/embed/raXvuwet78M\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n",{"slug":4936,"featured":6,"template":681},"gitlab-flow-screencast","content:en-us:blog:gitlab-flow-screencast.yml","Gitlab Flow Screencast","en-us/blog/gitlab-flow-screencast.yml","en-us/blog/gitlab-flow-screencast",25,[687,708,731,752,772,792,815,839,859],1751548582820]