[{"data":1,"prerenderedAt":1499},["ShallowReactive",2],{"/en-us/blog/tags/developer-survey/":3,"navigation-en-us":20,"banner-en-us":450,"footer-en-us":467,"developer survey-tag-page-en-us":677},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/developer-survey","tags",false,"",{"tag":9,"tagSlug":10},"developer survey","developer-survey",{"template":12},"BlogTag","content:en-us:blog:tags:developer-survey.yml","yaml","Developer Survey","content","en-us/blog/tags/developer-survey.yml","en-us/blog/tags/developer-survey","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":446,"_type":14,"title":447,"_source":16,"_file":448,"_stem":449,"_extension":19},"/shared/en-us/main-navigation","en-us",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":408,"duo":427,"pricingDeployment":436},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/","gitlab logo","header",{"text":30,"config":31},"Get free trial",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Talk to sales",{"href":37,"dataGaName":38,"dataGaLocation":28},"/sales/","sales",{"text":40,"config":41},"Sign in",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,187,192,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Platform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"The most comprehensive AI-powered DevSecOps Platform",{"text":53,"config":54},"Explore our Platform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":60,"config":61},"Meet GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":68,"config":69},"Learn more",{"href":70,"dataGaName":71,"dataGaLocation":28},"/why-gitlab/","why gitlab",{"title":73,"items":74},"Get started with",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Developer Experience",{"href":83,"dataGaName":84,"dataGaLocation":28},"/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":169},"Product",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/solutions/",[99,124,148],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/solutions/continuous-integration/",{"text":113,"config":114},"AI-Assisted Development",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Source Code Management",{"href":119,"dataGaLocation":28,"dataGaName":117},"/solutions/source-code-management/",{"text":121,"config":122},"Automated Software Delivery",{"href":105,"dataGaLocation":28,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Security","Deliver code faster without compromising security",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":28,"icon":131},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"Software Supply Chain Security",{"href":141,"dataGaLocation":28,"dataGaName":142},"/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":147,"dataGaLocation":28},"/solutions/software-compliance/","software compliance",{"title":149,"link":150,"items":155},"Measurement",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[156,160,164],{"text":157,"config":158},"Visibility & Measurement",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Value Stream Management",{"href":163,"dataGaLocation":28,"dataGaName":161},"/solutions/value-stream-management/",{"text":165,"config":166},"Analytics & Insights",{"href":167,"dataGaLocation":28,"dataGaName":168},"/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab for",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":28,"dataGaName":176},"/enterprise/","enterprise",{"text":178,"config":179},"Small Business",{"href":180,"dataGaLocation":28,"dataGaName":181},"/small-business/","small business",{"text":183,"config":184},"Public Sector",{"href":185,"dataGaLocation":28,"dataGaName":186},"/solutions/public-sector/","public sector",{"text":188,"config":189},"Pricing",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"Resources",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"View all resources",{"href":199,"dataGaName":195,"dataGaLocation":28},"/resources/",[201,234,257],{"title":202,"items":203},"Getting started",[204,209,214,219,224,229],{"text":205,"config":206},"Install",{"href":207,"dataGaName":208,"dataGaLocation":28},"/install/","install",{"text":210,"config":211},"Quick start guides",{"href":212,"dataGaName":213,"dataGaLocation":28},"/get-started/","quick setup checklists",{"text":215,"config":216},"Learn",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Product documentation",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best practice videos",{"href":227,"dataGaName":228,"dataGaLocation":28},"/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrations",{"href":232,"dataGaName":233,"dataGaLocation":28},"/integrations/","integrations",{"title":235,"items":236},"Discover",[237,242,247,252],{"text":238,"config":239},"Customer success stories",{"href":240,"dataGaName":241,"dataGaLocation":28},"/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":28},"/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/teamops/","teamops",{"title":258,"items":259},"Connect",[260,265,270,275,280],{"text":261,"config":262},"GitLab Services",{"href":263,"dataGaName":264,"dataGaLocation":28},"/services/","services",{"text":266,"config":267},"Community",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Events",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partners",{"href":283,"dataGaName":284,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","Insights for the future of software development",{"altText":290,"config":291},"the source promo card",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"Read the latest",{"href":296,"dataGaName":297,"dataGaLocation":28},"/the-source/","the source",{"text":299,"config":300,"lists":302},"Company",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"About",{"href":308,"dataGaName":309,"dataGaLocation":28},"/company/","about",{"text":311,"config":312,"footerGa":315},"Jobs",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Leadership",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Team",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Handbook",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Investor relations",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Trust Center",{"href":341,"dataGaName":342,"dataGaLocation":28},"/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Press",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Contact us",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Get help",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Customer portal",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Close",{"text":380,"link":381},"To search repositories and projects, login to",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Suggestions",[389,391,395,397,401,405],{"text":57,"config":390},{"href":62,"dataGaName":57,"dataGaLocation":385},{"text":392,"config":393},"Code Suggestions (AI)",{"href":394,"dataGaName":392,"dataGaLocation":385},"/solutions/code-suggestions/",{"text":109,"config":396},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":398,"config":399},"GitLab on AWS",{"href":400,"dataGaName":398,"dataGaLocation":385},"/partners/technology-partners/aws/",{"text":402,"config":403},"GitLab on Google Cloud",{"href":404,"dataGaName":402,"dataGaLocation":385},"/partners/technology-partners/google-cloud-platform/",{"text":406,"config":407},"Why GitLab?",{"href":70,"dataGaName":406,"dataGaLocation":385},{"freeTrial":409,"mobileIcon":414,"desktopIcon":419,"secondaryButton":422},{"text":410,"config":411},"Start free trial",{"href":412,"dataGaName":33,"dataGaLocation":413},"https://gitlab.com/-/trials/new/","nav",{"altText":415,"config":416},"Gitlab Icon",{"src":417,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":415,"config":420},{"src":421,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":423,"config":424},"Get Started",{"href":425,"dataGaName":426,"dataGaLocation":413},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Learn more about GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":413},"gitlab duo",{"altText":415,"config":433},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":435},{"src":421,"dataGaName":418,"dataGaLocation":413},{"freeTrial":437,"mobileIcon":442,"desktopIcon":444},{"text":438,"config":439},"Back to pricing",{"href":190,"dataGaName":440,"dataGaLocation":413,"icon":441},"back to pricing","GoBack",{"altText":415,"config":443},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":445},{"src":421,"dataGaName":418,"dataGaLocation":413},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":451,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":452,"button":453,"image":458,"config":462,"_id":464,"_type":14,"_source":16,"_file":465,"_stem":466,"_extension":19},"/shared/en-us/banner","is now in public beta!",{"text":454,"config":455},"Try the Beta",{"href":456,"dataGaName":457,"dataGaLocation":28},"/gitlab-duo/agent-platform/","duo banner",{"altText":459,"config":460},"GitLab Duo Agent Platform",{"src":461},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":463},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":468,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":469,"_id":673,"_type":14,"title":674,"_source":16,"_file":675,"_stem":676,"_extension":19},"/shared/en-us/main-footer",{"text":470,"source":471,"edit":477,"contribute":482,"config":487,"items":492,"minimal":665},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":472,"config":473},"View page source",{"href":474,"dataGaName":475,"dataGaLocation":476},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":478,"config":479},"Edit this page",{"href":480,"dataGaName":481,"dataGaLocation":476},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":483,"config":484},"Please contribute",{"href":485,"dataGaName":486,"dataGaLocation":476},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":488,"facebook":489,"youtube":490,"linkedin":491},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[493,516,572,601,635],{"title":46,"links":494,"subMenu":499},[495],{"text":496,"config":497},"DevSecOps platform",{"href":55,"dataGaName":498,"dataGaLocation":476},"devsecops platform",[500],{"title":188,"links":501},[502,506,511],{"text":503,"config":504},"View plans",{"href":190,"dataGaName":505,"dataGaLocation":476},"view plans",{"text":507,"config":508},"Why Premium?",{"href":509,"dataGaName":510,"dataGaLocation":476},"/pricing/premium/","why premium",{"text":512,"config":513},"Why Ultimate?",{"href":514,"dataGaName":515,"dataGaLocation":476},"/pricing/ultimate/","why ultimate",{"title":517,"links":518},"Solutions",[519,524,526,528,533,538,542,545,549,554,556,559,562,567],{"text":520,"config":521},"Digital transformation",{"href":522,"dataGaName":523,"dataGaLocation":476},"/topics/digital-transformation/","digital transformation",{"text":134,"config":525},{"href":136,"dataGaName":134,"dataGaLocation":476},{"text":123,"config":527},{"href":105,"dataGaName":106,"dataGaLocation":476},{"text":529,"config":530},"Agile development",{"href":531,"dataGaName":532,"dataGaLocation":476},"/solutions/agile-delivery/","agile delivery",{"text":534,"config":535},"Cloud transformation",{"href":536,"dataGaName":537,"dataGaLocation":476},"/topics/cloud-native/","cloud transformation",{"text":539,"config":540},"SCM",{"href":119,"dataGaName":541,"dataGaLocation":476},"source code management",{"text":109,"config":543},{"href":111,"dataGaName":544,"dataGaLocation":476},"continuous integration & delivery",{"text":546,"config":547},"Value stream management",{"href":163,"dataGaName":548,"dataGaLocation":476},"value stream management",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":476},"/solutions/gitops/","gitops",{"text":173,"config":555},{"href":175,"dataGaName":176,"dataGaLocation":476},{"text":557,"config":558},"Small business",{"href":180,"dataGaName":181,"dataGaLocation":476},{"text":560,"config":561},"Public sector",{"href":185,"dataGaName":186,"dataGaLocation":476},{"text":563,"config":564},"Education",{"href":565,"dataGaName":566,"dataGaLocation":476},"/solutions/education/","education",{"text":568,"config":569},"Financial services",{"href":570,"dataGaName":571,"dataGaLocation":476},"/solutions/finance/","financial services",{"title":193,"links":573},[574,576,578,580,583,585,587,589,591,593,595,597,599],{"text":205,"config":575},{"href":207,"dataGaName":208,"dataGaLocation":476},{"text":210,"config":577},{"href":212,"dataGaName":213,"dataGaLocation":476},{"text":215,"config":579},{"href":217,"dataGaName":218,"dataGaLocation":476},{"text":220,"config":581},{"href":222,"dataGaName":582,"dataGaLocation":476},"docs",{"text":243,"config":584},{"href":245,"dataGaName":246,"dataGaLocation":476},{"text":238,"config":586},{"href":240,"dataGaName":241,"dataGaLocation":476},{"text":248,"config":588},{"href":250,"dataGaName":251,"dataGaLocation":476},{"text":261,"config":590},{"href":263,"dataGaName":264,"dataGaLocation":476},{"text":253,"config":592},{"href":255,"dataGaName":256,"dataGaLocation":476},{"text":266,"config":594},{"href":268,"dataGaName":269,"dataGaLocation":476},{"text":271,"config":596},{"href":273,"dataGaName":274,"dataGaLocation":476},{"text":276,"config":598},{"href":278,"dataGaName":279,"dataGaLocation":476},{"text":281,"config":600},{"href":283,"dataGaName":284,"dataGaLocation":476},{"title":299,"links":602},[603,605,607,609,611,613,615,619,624,626,628,630],{"text":306,"config":604},{"href":308,"dataGaName":301,"dataGaLocation":476},{"text":311,"config":606},{"href":313,"dataGaName":314,"dataGaLocation":476},{"text":319,"config":608},{"href":321,"dataGaName":322,"dataGaLocation":476},{"text":324,"config":610},{"href":326,"dataGaName":327,"dataGaLocation":476},{"text":329,"config":612},{"href":331,"dataGaName":332,"dataGaLocation":476},{"text":334,"config":614},{"href":336,"dataGaName":337,"dataGaLocation":476},{"text":616,"config":617},"Sustainability",{"href":618,"dataGaName":616,"dataGaLocation":476},"/sustainability/",{"text":620,"config":621},"Diversity, inclusion and belonging (DIB)",{"href":622,"dataGaName":623,"dataGaLocation":476},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":625},{"href":341,"dataGaName":342,"dataGaLocation":476},{"text":349,"config":627},{"href":351,"dataGaName":352,"dataGaLocation":476},{"text":354,"config":629},{"href":356,"dataGaName":357,"dataGaLocation":476},{"text":631,"config":632},"Modern Slavery Transparency Statement",{"href":633,"dataGaName":634,"dataGaLocation":476},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":636,"links":637},"Contact Us",[638,641,643,645,650,655,660],{"text":639,"config":640},"Contact an expert",{"href":37,"dataGaName":38,"dataGaLocation":476},{"text":368,"config":642},{"href":370,"dataGaName":371,"dataGaLocation":476},{"text":373,"config":644},{"href":375,"dataGaName":376,"dataGaLocation":476},{"text":646,"config":647},"Status",{"href":648,"dataGaName":649,"dataGaLocation":476},"https://status.gitlab.com/","status",{"text":651,"config":652},"Terms of use",{"href":653,"dataGaName":654,"dataGaLocation":476},"/terms/","terms of use",{"text":656,"config":657},"Privacy statement",{"href":658,"dataGaName":659,"dataGaLocation":476},"/privacy/","privacy statement",{"text":661,"config":662},"Cookie preferences",{"dataGaName":663,"dataGaLocation":476,"id":664,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":666},[667,669,671],{"text":651,"config":668},{"href":653,"dataGaName":654,"dataGaLocation":476},{"text":656,"config":670},{"href":658,"dataGaName":659,"dataGaLocation":476},{"text":661,"config":672},{"dataGaName":663,"dataGaLocation":476,"id":664,"isOneTrustButton":91},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":678,"featuredPost":1476,"totalPagesCount":1497,"initialPosts":1498},[679,704,726,748,769,790,812,832,852,871,891,910,932,951,970,990,1010,1029,1053,1073,1094,1112,1133,1153,1173,1192,1210,1228,1248,1266,1285,1304,1326,1346,1365,1383,1401,1420,1438,1458],{"_path":680,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":681,"content":689,"config":697,"_id":700,"_type":14,"title":701,"_source":16,"_file":702,"_stem":703,"_extension":19},"/en-us/blog/2018-global-developer-survey",{"title":682,"description":683,"ogTitle":682,"ogDescription":683,"noIndex":6,"ogImage":684,"ogUrl":685,"ogSiteName":686,"ogType":687,"canonicalUrls":685,"schema":688},"2018 Developer Survey: Uncovering needs & preferences","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","https://about.gitlab.com","article","\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":690,"description":683,"authors":691,"heroImage":684,"date":693,"body":694,"category":695,"tags":696},"2018 Global Developer Survey aims to uncover developer needs and preferences at work",[692],"Erica Lindberg","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","insights",[9],{"slug":698,"featured":6,"template":699},"2018-global-developer-survey","BlogPost","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":705,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":706,"content":712,"config":720,"_id":722,"_type":14,"title":723,"_source":16,"_file":724,"_stem":725,"_extension":19},"/en-us/blog/2019-developer-survey-announcement",{"title":707,"description":708,"ogTitle":707,"ogDescription":708,"noIndex":6,"ogImage":709,"ogUrl":710,"ogSiteName":686,"ogType":687,"canonicalUrls":710,"schema":711},"The 2019 developer survey: Help 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":713,"description":708,"authors":714,"heroImage":709,"date":716,"body":717,"category":695,"tags":718},"The 2019 Global Developer Survey is now open! Share your thoughts to shape the industry.",[715],"Suri Patel","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",[9,719,269],"DevOps",{"slug":721,"featured":6,"template":699},"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":727,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":728,"content":734,"config":742,"_id":744,"_type":14,"title":745,"_source":16,"_file":746,"_stem":747,"_extension":19},"/en-us/blog/2021-devsecops-survey-the-great-shift-left-continues",{"title":729,"description":730,"ogTitle":729,"ogDescription":730,"noIndex":6,"ogImage":731,"ogUrl":732,"ogSiteName":686,"ogType":687,"canonicalUrls":732,"schema":733},"DevSecOps maturity insights from 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":735,"description":730,"authors":736,"heroImage":731,"date":738,"body":739,"category":695,"tags":740},"Looking for a DevSecOps maturity model that works? Start with our 2021 Global Survey",[737],"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",[9,741],"security",{"slug":743,"featured":6,"template":699},"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":749,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":750,"content":756,"config":763,"_id":765,"_type":14,"title":766,"_source":16,"_file":767,"_stem":768,"_extension":19},"/en-us/blog/a-3-step-plan-for-devops-platform-migration",{"title":751,"description":752,"ogTitle":751,"ogDescription":752,"noIndex":6,"ogImage":753,"ogUrl":754,"ogSiteName":686,"ogType":687,"canonicalUrls":754,"schema":755},"A 3-step plan for DevOps platform migration","Too many tools = too much time wasted. Use our 3-step plan and detailed checklist to jumpstart a DevOps platform migration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668319/Blog/Hero%20Images/more-robust-task-lists.jpg","https://about.gitlab.com/blog/a-3-step-plan-for-devops-platform-migration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A 3-step plan for DevOps platform migration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lauren Minning\"}],\n        \"datePublished\": \"2022-08-25\",\n      }",{"title":751,"description":752,"authors":757,"heroImage":753,"date":759,"body":760,"category":761,"tags":762},[758],"Lauren Minning","2022-08-25","\n\nWhen making your DevOps platform migration plan, less really is more, at least when it comes to tools.\n\nOur [2022 Global DevSecOps Survey](/developer-survey/) found that not only do teams have _lots_ of tools, they spend a significant amount of time managing them. All told 40% of developers spend between one quarter and one half of their time on toolchain maintenance and integration, and another 33% spend between 50% and **all** of their time on this task. So it’s hardly a surprise that 69% of survey takers said they want to consolidate their toolchains.\n\nOne obvious way to consolidate is migrating to a DevOps platform. DevOps platform migration does take some planning and teamwork, but it can be done. Here’s a 3-step plan (and a self-evaluation checklist) to get teams started.\n\n## Choose the right path\n\nThe most important thing to know about migrating to an end-to-end DevOps platform is that everyone's needs are different so there isn’t one “right way” to carry out your migration.\n\nA company that has 1,000 users will have completely different DevOps needs than a company that has 5,000 users. What your specific DevOps platform migration plan requires will depend on the types of projects you migrate, the file types within those projects, and a whole host of other parameters. Because of this, there is not a “one size fits all” migration process for everyone to follow. \n\nHere’s a basic 3-step guide for migrating to a DevOps platform:\n\n**Begin by identifying** the strategic goals and be clear about why they are a priority for future business plans.\n\n**Evaluate tools** currently in use that no longer serve future goals. Ultimately the goal should be to operate entirely out of a single application for maximum efficiency. But it may make sense to migrate some things now and others down the line. \n\nThis is the time to become a historian and discern which tools have been problematic in the past. Consider what to migrate right away or later on and why (i.e., instability or costly maintenance and licensing) and really use that to inform the migration process. \n\n_An important note: Take into consideration the business disruption that migration has on a company. Replacing existing tools with a new DevOps platform in one step could mean sweeping changes across the organization, and the fallout might not be worth it. Instead, start with the things taking time, effort and money to maintain. And continue to keep it as simple and streamlined as possible._\n\n**Have everyone** on the team complete a self-evaluation so there are no surprises.\n\n## Do a self-evaluation \n\nHere are key questions to ask:\n\n- What’s the timeline? Discuss with all involved parties – existing team members and a representative of the new DevOps platform – how much time to allot for a completed migration. Migrations can take anywhere from 2 weeks for the initial migration to 3-6 months for monitoring. \n\n- What are the costs? This kind of platform adoption can ultimately save a LOT of money. However, the adoption of a new DevOps platform and the associated migration will no doubt have costs. Consider all costs and make sure they align with budgetary goals and requirements.\n\n- What about assistance? Are other parts of the company prepared to support a migration? How much of this will require work from the existing team and how much support will the DevOps platform provider offer? \n\n- Who are the primary and other platform users? What teams of people will migrate to this new platform? Will everyone have the same level or different levels of permissions? What needs to be done so that these teams are prepared to learn and teach the ins and outs of the new platform to other team members? \n\n- What data is migrating? Make sure to have a 360 view of the data involved in a migration including, projects, issues, and file types. What changes can happen with data when moving to a brand new DevOps platform? When evaluating the projects planned for migration, explore which applications teams spend the most time and energy working with, and what will set them up for success in the new platform.\n\n- How will automation fit in? Ensure teams understand the technology underpinnings of automation, like Kubernetes, CI/CD and more.\nHow should it be customized? Not every tool on a DevOps platform will be right for every team, and some tools might be a better fit at a later date. It makes sense to address any technology “outliers” right from the start. \n\n- Should the process be documented? Every step of the migration process should be documented and shared across teams. This level of transparency and an iterative, easy-to-search knowledge base can help problem-solve and refer back to stages already completed. Much like a single source for DevOps, a single source of truth for DevOps migration info helps everyone involved. \n\n- What about security? Security is never a “one and done,” but this is a good time to consider processes and levels of protection.\nWhat are good results?: What will a successful migration look like – when data is moved, or when teams are comfortable in their knowledge and use of the new system? Map out what the goals that will be critical to a successful migration.\n\nCheck out our _[Migrating to a DevOps platform](https://page.gitlab.com/migrate-to-devops-guide.html)_ eBook  for even more useful information about how to complete a successful DevOps platform migration.\n","devsecops",[719,9,741],{"slug":764,"featured":6,"template":699},"a-3-step-plan-for-devops-platform-migration","content:en-us:blog:a-3-step-plan-for-devops-platform-migration.yml","A 3 Step Plan For Devops Platform Migration","en-us/blog/a-3-step-plan-for-devops-platform-migration.yml","en-us/blog/a-3-step-plan-for-devops-platform-migration",{"_path":770,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":771,"content":777,"config":784,"_id":786,"_type":14,"title":787,"_source":16,"_file":788,"_stem":789,"_extension":19},"/en-us/blog/a-snapshot-of-modern-devops-practices-today",{"title":772,"description":773,"ogTitle":772,"ogDescription":773,"noIndex":6,"ogImage":774,"ogUrl":775,"ogSiteName":686,"ogType":687,"canonicalUrls":775,"schema":776},"A snapshot of modern DevOps practices today","We consulted three market research firms for their take on DevOps today and in the future. Here's what they said about modern DevOps practices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668495/Blog/Hero%20Images/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab.jpg","https://about.gitlab.com/blog/a-snapshot-of-modern-devops-practices-today","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A snapshot of modern DevOps practices today\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-10-31\",\n      }",{"title":772,"description":773,"authors":778,"heroImage":774,"date":780,"body":781,"category":761,"tags":782},[779],"Valerie Silverthorne","2022-10-31","At almost 15 years old, DevOps has been around long enough to settle in and take shape at organizations around the world. But what do “modern” DevOps practices look like today, and how are they likely to change? Three market research firms gave us their take on the current generation of DevOps, and what’s coming next. \n\n## BizDevOps anyone?\n\nIf there’s one clear sign of DevOps maturity, it’s the fact that the business side has seamlessly inserted itself into what was forever a bastion of technologies and tech-driven practices. With some of the [bigger DevOps battles well in hand](/developer-survey/) (broader adoption of automation, more frequent deployments, and increased software testing), teams are able to bring in new metrics, including user experience, customer satisfaction, and other business drivers. 451 Research found business objectives and outcomes are the leading priority (51%) for enterprises as they refine, improve, and expand their DevOps implementations. In fact, 451 said business metrics are now almost as important a measure of DevOps success as technical achievements like application performance and quality.(1)\n\nFurther underscoring the way modern DevOps practices have broadened their focus is the increasing interest in value stream management, which looks at the software development lifecycle from idea generation to customer delivery and satisfaction level. Research firm IDC, in its \"Accelerated App Delivery Survey 2021\" (U.S. Results)(3), published January 2022, said value stream management is going to be one of the top investment priorities for DevOps teams this year. \n\n## DevOps and security\n\nBut the focus on business objectives doesn’t mean that work on the tech side of DevOps is done; in fact, DevSecOps and security in DevOps in general continue to be a tricky balance for many teams. IDC, also in its \"Accelerated App Delivery Survey 2021\" (referenced above), notes the cognitive dissonance of DevOps teams saying security is a top priority and feeling confident about their security posture while at the same time acknowledging DevSecOps is only in use for 25% or less of application development on average. \n\nForrester Research, in its \"State of Application Security, 2022\" (May 9, 2022), said: “Savvy security professionals know that to drive application security tool adoption, they must engage developers in the technology decision-making process. With both tooling\ndecision-making and budget moving to development, security pros must redefine\ntheir role in application security and take advantage of the opportunity to become\nmore strategic.”\n\n## The role of DevOps platforms\n\nSecurity is an ongoing substantive issue on DevOps teams but there are also a number of smaller, but still significant, problems teams need to solve, including [toolchain debt](/blog/battling-toolchain-technical-debt/), the challenge of scaling, and the need for a product and platform structure. DevOps platforms can help with all of those challenges.\n\nFor starters, it’s nearly impossible to scale DevOps throughout an enterprise without a DevOps platform supporting the effort. A platform provides a single source of truth for all teams, eliminates handoffs, and allows visibility into every stage of the process. A DevOps platform also helps eliminate the inefficiencies caused by too many tools and toolchains. Our [2022 Global DevSecOps Survey](/developer-survey/) found 69% of teams want to streamline their toolchains to reduce time spent on maintenance/integration and improve developer quality of life.\n\nWhat does a DevOps platform look like in 2022? Forrester Research, in \"The Forrester Guide to DevOps 2022\" (September 14, 2022) said modern DevOps platforms are “integrated and automated; create a software automation abstraction layer; use SLAs to drive continuous improvement; and have cloud platforms as deployment targets of choice.”\n\n## Culture (still) matters\n\nIn the early days of DevOps the talk was **all** about the culture challenge of bringing the vastly different dev and ops teams together. Somewhat surprisingly, market research firms are still talking about culture today, perhaps because the definition of DevOps has expanded to include more than just dev, ops, and even sec: BizDevSecUXTestPlatformLowCodeOps... ad infinitum, apparently.\n\nOrganizations wanting DevOps success must continue to push the importance of culture, collaboration, and communication, IDC reported in its \"Accelerated App Delivery Survey 2021.\" Forrester Research offered a stark assessment in \"The State of DevOps, 2022\" (June 27, 2022): “Never underestimate the importance of cultural transformation. Laggard organizations punish the bearers of bad tidings and don’t understand failure as a learning opportunity. Exorcizing these toxic attitudes is far easier said than done.”\n\n## Modern DevOps means modern technologies\n\nModern DevOps teams continue to incorporate new technologies into their practices. Two standouts: [AI/ML](/blog/why-ai-in-devops-is-here-to-stay/) and [GitOps](/blog/the-ultimate-guide-to-gitops-with-gitlab/). 451 points to rising interest in AIOps specifically to address the “too much information” problem with logs and metrics.(2) \n\n## Looking forward\n\nChange is of course a given and it’s safe to say that DevOps teams will face new organizational structures, new teammates, and complicated technology adoption challenges.\n\n### Cross-functional teams organized around products\n\nAfter years of bringing dev and ops together, some believe it’s time to reach out further. Forrester, in \"The Future of DevOps\" (June 8, 2022), said: “In the future, cross-functional teams, from business stakeholders to operational site reliability engineers (SREs), will organize around products, delivering business value via DevOps platforms.”\n\n### Wider and deeper platforms\n\nAnd those DevOps platforms “will consolidate, extend and deepen,” Forrester predicts in \"The Future of DevOps,\" cited above.\n\n### Introducing new teammates\n\nRoughly 66% of our 2022 DevSecOps Survey respondents told us their DevOps practices include a low code/no code tool. And that’s going to spread to all teams in the coming years. “Citizen development is a logical evolution of how enterprises deliver apps and enable digital business,” Forrester Research said in \"The Future of DevOps.\"\n\n### DevOps on the edge\t\n\nWith the Internet of Things and 5G becoming larger on the horizon, it’s not much of a stretch to predict modern DevOps teams will need to be able to support products with data literally [“on the edge.”](https://www.techtarget.com/searchdatacenter/definition/edge-computing) \n\n- [1] 451 Research, a part of S&P Global Market Intelligence, Mature DevOps Means Business, Jay Lyman, Senior Research Analyst, June 2022\n- [2] 451 Research, a part of S&P Global Market Intelligence, Business Objectives and Benefits Become Top Priority - Highlights from VotE DevOps, Jay Lyman, Senior Research Analyst, April 2022\n- [3] IDC, U.S. Accelerated Application Delivery Survey, Doc #US47924622, Jan 2022\n",[9,783,719],"collaboration",{"slug":785,"featured":6,"template":699},"a-snapshot-of-modern-devops-practices-today","content:en-us:blog:a-snapshot-of-modern-devops-practices-today.yml","A Snapshot Of Modern Devops Practices Today","en-us/blog/a-snapshot-of-modern-devops-practices-today.yml","en-us/blog/a-snapshot-of-modern-devops-practices-today",{"_path":791,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":792,"content":798,"config":806,"_id":808,"_type":14,"title":809,"_source":16,"_file":810,"_stem":811,"_extension":19},"/en-us/blog/best-practices-leading-orgs-to-release-software-faster",{"title":793,"description":794,"ogTitle":793,"ogDescription":794,"noIndex":6,"ogImage":795,"ogUrl":796,"ogSiteName":686,"ogType":687,"canonicalUrls":796,"schema":797},"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":793,"description":794,"authors":799,"heroImage":795,"date":801,"body":802,"category":695,"tags":803},[800],"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/) 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",[9,109,804,805],"cloud native","DevSecOps",{"slug":807,"featured":6,"template":699},"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":813,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":814,"content":820,"config":826,"_id":828,"_type":14,"title":829,"_source":16,"_file":830,"_stem":831,"_extension":19},"/en-us/blog/challenges-of-code-reviews",{"title":815,"description":816,"ogTitle":815,"ogDescription":816,"noIndex":6,"ogImage":817,"ogUrl":818,"ogSiteName":686,"ogType":687,"canonicalUrls":818,"schema":819},"The challenges of code reviews","The 2020 DevSecOps Report discovers that developers are bogged down by code reviews. Are they worth the trouble?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663975/Blog/Hero%20Images/devsecopssurvey.png","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":815,"description":816,"authors":821,"heroImage":817,"date":822,"body":823,"category":695,"tags":824},[715],"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",[825,9,719],"code review",{"slug":827,"featured":6,"template":699},"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":833,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":834,"content":840,"config":846,"_id":848,"_type":14,"title":849,"_source":16,"_file":850,"_stem":851,"_extension":19},"/en-us/blog/checkmarx-integration",{"title":835,"description":836,"ogTitle":835,"ogDescription":836,"noIndex":6,"ogImage":837,"ogUrl":838,"ogSiteName":686,"ogType":687,"canonicalUrls":838,"schema":839},"Get the most out of the Checkmarx integration with GitLab","Make it easier for developers to find bugs and for dev and sec to get along. Here’s what you need to know about the GitLab/Checkmarx integration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681659/Blog/Hero%20Images/checkmarx.jpg","https://about.gitlab.com/blog/checkmarx-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get the most out of the Checkmarx integration with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-10-12\",\n      }",{"title":835,"description":836,"authors":841,"heroImage":837,"date":842,"body":843,"category":844,"tags":845},[779],"2020-10-12","\n\nIn our 2020 Global DevSecOps survey, 65% of respondents said their organizations were shifting security left. Shifting left is the holy grail of [DevOps](/topics/devops/), certainly, but there’s reason to believe most organizations actually aren’t quite *left* enough: Less than 20% of respondents said developers were able to access either SAST or DAST scans from within their pipelines or IDEs.\n\nIt’s perhaps not surprising that, in the [same survey](/developer-survey/), security pros complained rather bitterly about developers finding too few bugs too late in the process.\n\nOne solution to this problem is to [integrate application security testing](/topics/devsecops/) earlier and actually within a development tool. During [our 2020 virtual user conference](/events/commit/), Commit, [James Brotsos](https://www.linkedin.com/in/jbrotsos/), a senior solutions engineer with [Checkmarx](https://www.checkmarx.com), walked attendees through the process of integrating his company’s security testing platform with GitLab.\n\n“(Integrating app security testing) really does free up time to focus on things that actually matter to developers, which is writing code,” James said during his presentation. “With this methodology, we are shifting far left into the software development life cycle. We still are providing governance and gating capabilities, constantly scanning the latest code and this replaces the need to scan it in the IDE.”\n\n## Getting started\n\nTo get the most out of an integrated security testing platform, James said companies should start by making a series of decisions: \n\nWhat do you want to scan? Commits or merge requests?\nWhen do you want to scan? Nightly, weekly, more often?\nHow do you want the data? Via the Checkmarx platform, emails, Slack messages, inside GitLab or through auto ticket creation?\n\n“We have an interactive security testing platform which is an agent that runs on a test server,” James explained. “It’s running your code, it monitors traffic driven from functional tests and it could run security types of queries on top of that. We provide… all these types of vulnerabilities and we train you how to fix them.”\n\nAt the heart of the GitLab integration with Checkmarx is CxFlow, a spring boot application that initiates scans and pursues results, James said. Scanning is initiated by integrating with [GitLab’s CI/CD](/topics/ci-cd/), or through a merge request or pushed code, triggering an already existing pipeline. That pipeline needs just a single edit to include the stage to execute a security scan.\n\nThe integration is completely customizable and developers can get what they need when they need it. CxFlow drives a result feedback loop so no manual intervention is required and developers can filter the types of defects created based on any filtering criteria. “The results are easy to consume in a way that developers want to consume them… and the results are actionable,” James said.\n\nWhen it comes to defect tracking, CxFlow solves the problem of having the same vulnerability type in the same file by creating just a single issue where the ticket automatically closes once its been dealt with. And developers can choose how they receive feedback: through GitLab’s security dashboard or issues, or through Jira, email, ServiceNow and Rally.\n\n## The nuts and bolts\n\nTo tie security scanning into GitLab, start by setting up the global variables that will allow access to the Checkmarx server. After that the CI/CD pipeline can kick off. Separate the Checkmarx stages from the GitLab CI file – you don’t want to “pollute” any existing YAML file set up by your DevOps team. Just include another YAML file with this stage or extension and that will allow you to have the Checkmarx-specific information which will kick off the CxFlow CLI.\n\nSo once the CxFlow starts to run inside that container, it will initiate a scan inside Checkmarx. The results will be sent back to CxFlow. “Depending on how you want to consume those results, we can update the security dashboard, we can update the issues, we can update the merge request, or we can update all three of them at the same time,” James said.\n\nCxFlow can also create issues automatically that can then be triaged to an epic or assigned to a specific user. “This way you can treat all security vulnerabilities as you would any other defect or any other kind of issue,” James said.\n\n“This is a pretty effortless option for the development teams to scan projects quickly,” James said. “There is no overhead when configuring and managing these builds. You can quickly automate the scan of multiple repositories and there's no overhead in configuring and managing all of these different repos that you might have.”\n\n## A deeper dive\n\nA more detailed look at this project can be found [on the Checkmarx website](https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1929937052/GitLab+Integration) or watch the entire Commit presentation:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/W1Wk3PN0o1M\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [JJ Ying](https://unsplash.com/@jjying) on [Unsplash](https://unsplash.com)\n{: .note}\n","engineering",[741,825,9],{"slug":847,"featured":6,"template":699},"checkmarx-integration","content:en-us:blog:checkmarx-integration.yml","Checkmarx Integration","en-us/blog/checkmarx-integration.yml","en-us/blog/checkmarx-integration",{"_path":853,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":854,"content":860,"config":865,"_id":867,"_type":14,"title":868,"_source":16,"_file":869,"_stem":870,"_extension":19},"/en-us/blog/ci-cd-changing-roles",{"title":855,"description":856,"ogTitle":855,"ogDescription":856,"noIndex":6,"ogImage":857,"ogUrl":858,"ogSiteName":686,"ogType":687,"canonicalUrls":858,"schema":859},"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":855,"description":856,"authors":861,"heroImage":857,"date":862,"body":863,"category":695,"tags":864},[779],"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",[109,719,9],{"slug":866,"featured":6,"template":699},"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":872,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":873,"content":879,"config":885,"_id":887,"_type":14,"title":888,"_source":16,"_file":889,"_stem":890,"_extension":19},"/en-us/blog/developer-security-divide",{"title":874,"description":875,"ogTitle":874,"ogDescription":875,"noIndex":6,"ogImage":876,"ogUrl":877,"ogSiteName":686,"ogType":687,"canonicalUrls":877,"schema":878},"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":874,"description":875,"authors":880,"heroImage":876,"date":882,"body":883,"category":695,"tags":884},[881],"Brendan O'Leary","2020-08-13","\n\n_We have to start by saying that at GitLab, there really is no developer-security divide. Dev and sec *do* get along – extraordinarily well, as a matter of fact. But there’s no denying that friction between developers and security pros does exist and we wanted to take this opportunity to acknowledge the elephant in the room._\n\n_In our [2020 Global DevSecOps Survey](/developer-survey/previous/2020/), 65% of security pros said their organizations had successfully shifted security left. Thanks to DevOps, developers, security experts, operations professionals, and testers all reported being increasingly part of cross-functional teams dedicated to getting safe code out the door more quickly._\n\n_But look a bit more closely into that rosy picture and the cracks start to appear. Security team members said developers didn’t find enough bugs early in the process and were slow to fix them when they were found. Not enough security testing happens and if the tests are run, they occur too late in the process. Very few devs said they run standard security tests like SAST or DAST. And there is even confusion over exactly who is responsible for security: 32% of sec pros told us they were solely responsible but more than 29% told us *everyone* was responsible._\n\n_To see if we could shed some clarity on these critical-to-get-right DevOps topics [Brendan O’Leary](/company/team/#brendan), senior developer evangelist, and [Ethan Strike](/company/team/#estrike), security manager, [Application Security](/topics/devsecops/), had a virtual sit down to hash out the differences between devs and sec._\n\n![Headshots of Brendan O’Leary and Ethan Strike](https://about.gitlab.com/images/blogimages/brendanethan.png){: .shadow.small.center}\nBrendan O’Leary and Ethan Strike\n{: .note.text-center}\n\n## Who is primarily responsible for security?\n\n*Ethan*: Overall, for secure development to be successful there has to be a culture of security shared between all of the stakeholders, including development, product, and security. That means that both development and security need to feel trusted and supported throughout the organization, not just in their particular vertical. Here at GitLab, our E-group has done an excellent job of building that culture, which has allowed us to tackle problems collaboratively across teams.\n\nSpecific to the question, in order to be successful, I believe the team writing the code is ultimately responsible for security. They are the owners of the code they write, and know it best, so they are in the best position to ensure its security. But that does not mean that the security team is off the hook for product vulnerabilities. They have the important responsibility of ensuring the development team has tools and knowledge available to them to write secure code. They might even contribute to the code base themselves.\n\n> For secure development to be successful there has to be a culture of security shared between all of the stakeholders. – Ethan Strike\n\nThe security team also has the important role of assessing risk and communicating that risk effectively for the development teams to act upon. It is unrealistic for both sides to expect the other to shoulder the entire security work load, and there must be a balance between security requirements and functionality based upon business requirements.\n\n*Brendan*: There are two ways to look at this. If we said who is _directly_ responsible for security, then sure it’s easy to say that the folks with \"security\" in their title are the answer to that.\n\nBut the reality, especially in a modern organization centered around software delivery and excellence, is that everyone has to be responsible for security and have it at the forefront of their minds.\n\nThe thing customers want is better software faster, but one security incident can make that irrelevant. Security thus is a *key* component of quality software, and has to be a team effort. Just as there are different folks on a car assembly line that are _primarily_ responsible for different parts of the car, the only way for a high-quality vehicle to roll off the end of the line is for everyone to work together, back each other up, and help to check each other's specialized work.\n\n## Devs aren’t running enough SAST/DAST/container or compliance scans. Why?\n\n*Brendan*: The bar is far too high to even get started running [SAST](https://www.gartner.com/en/information-technology/glossary/static-application-security-testing-sast) or [DAST](https://www.gartner.com/en/information-technology/glossary/dynamic-application-security-testing-dast) scans. Let’s take a look at them separately as they are worlds apart.\n\n> So running the code in production is hard enough, why would I spend time to try and run it _before_ production? – Brendan O’Leary\n\nFor SAST (or container or compliance) scans: To run that as a developer in a \"traditional\" organization, I would need help from the ops team to have the right tooling installed. To determine what the \"right\" tooling is, I’d probably need a security review of existing tools as they are varied and their efficacy can depend on what languages and frameworks we are specifically using to write our application. And all of that work is before the first SAST check even runs - and after they are running it’s even worse. As a developer, I don’t have a great way to understand at the end of a release cycle what changes caused which security issues, so the \"noise\" of security tests (if we have them) is too loud to find the signal inside. It’s easier to just not deal with that whole cycle.\n\nFor DAST the bar is *much* higher than even SAST. While I have all the same issues that we mentioned about SAST in terms of coronation and signal-to-noise ratios, now add that complexity to the fact that I will need an entire running \"prod-like\" environment to even think about running DAST. That means recreating a proxy for the network and architecture decisions that are made by the ops team about the production environment. And if you get the wrong thing wrong, it makes all of the DAST test invalid. So running the code in production is hard enough, why would I spend time to try and run it _before_ production?\n\n*Ethan*: In my experience this is because out of the box the tools can create a lot of noise. Common causes of noise are false positives, or a high number of low-impact findings. When you’re trying to get a feature out the door, this can understandably be frustrating. A lot of the noise comes from the generic nature of the tools, as they are meant to be applicable to every code base. Each code base is of course different.\n\nHere again though, some cooperation can go a long way. The efficacy of the tools comes with some tuning, and the goal is to get to that happy medium. For example, at GitLab, the results of the SAST tools are presented in an MR and developers are first in line for validating the findings, as they know the code the best. The application security team also looks at the results in the dashboard, and is looking to assess larger trends, identifying areas that are being overlooked/dismissed incorrectly, or simply providing additional context on the findings. That information can then be shared with the development teams. Each side has to trust that the other is working to find the right balance.\n\n## Why aren’t devs finding enough bugs?\n\n*Ethan*: This is difficult to answer, as it is driven by the circumstances. It could be a matter of security education, a feeling of lack of ownership, or just culture overall. I think that most developers, if given ownership of the code they write, would be incentivized to find as many bugs as possible. In the end, that means less time fixing things in the backlog and more time building features. In order to do that though, they need to be given resources in the form of knowledge and time to test effectively, and the security team can help them with that.\n\n*Brendan*: This is a direct result of the above. In fact, given how few developers are running SAST and DAST, it may honestly be generous to say they discover 25% of bugs. Without that infrastructure, there’s no way for me as a developer to find those issues.\n\nAnd worse than that they can all be \"out of sight, out of mind.\" If security has a walled garden around information about what security scans are important to our organization, or how to run those scans, then I’m just as happy as a developer to live in an \"ignorance is bliss\" world. That is of course until there’s a major security breach caused by poor coding practices.\n\n## How can bugs be found earlier in the process?\n\n*Brendan*: Again, the bar is too high to run the security scans. As a developer, I don’t have an easy way to do that or understand security’s requirements for those tests. Without that ability, I’m at a loss to find any bugs.\n\nAnd without any \"security\" in the pipeline, it leaves all detection of security issues to the end of a cycle when we want to actually put the code into production. And by that time, there have been dozens or hundreds of changes, so unwinding what changes caused which issues is next to impossible - much less understanding how to quickly fix them. So it’s back to the drawing board from an engineering perspective to fix issues we should have known about when we started walking down that path... of course this causes delays.\n\n> If security has a walled garden around information about what security scans are important to our organization, or how to run those scans, then I’m just as happy as a developer to live in an \"ignorance is bliss\" world. – Brendan\n\n*Ethan*: That is because testing in general comes late in the development process. I don’t think this is always security specific. This stems historically from the waterfall software development process. With agile, quality testing has become more prominent with unit testing and CI, but security is still working its way into that workflow. For example, at GitLab, we have security focused unit tests and automated SAST and dependency scanners, but we still have manual security testing, and a bug bounty program in operation after major development is complete. I think that all security teams are always looking to find ways to identify a risk when the code is written. This can be in the form of threat modeling, embedded security engineers looking at code, and the development of security-focused libraries.\n\n## Is it true that devs apparently don’t want to fix bugs?\n\n*Ethan*: I do not think that is true. I think that there can be difficulty scheduling fixes in with feature requirements. Also, if I remember correctly, [in the survey](/developer-survey/previous/2020/), some developers said that they do not always know how to fix a bug. I think that the fixing of security bugs needs to be a cultural practice within the company. All teams involved in development, including product, developers and the security team have to be committed to fixing security bugs within established time frames. That also has to be balanced with features and non-security bugs. That is where an agreed upon [SLA](https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html) for fixing security vulnerabilities is helpful.\n\n*Brendan*: I love to fix bugs - when they are easy to identify and debug and small enough to make the \"blast radius\" of a fix not too large. The best time to do that is when I’m in \"flow\" - right when I’m writing the code and have a mental model of all of the things and how they are interconnected. So that’s basically the same day or same week as when I wrote it.\n\n> With agile, quality testing has become more prominent with unit testing and CI, but security is still working its way into that workflow. – Ethan\n\nAfter that, if I find out about a bug weeks later or that is only reproducible in production, then it is extremely frustrating if not impossible to fix. Without an environment that looks like prod, or a clear understanding of *why* security sees something as a bug that I see as a nuance, it makes it much harder to fix.\n\nIf I was given the feedback I get at the end of a release cycle on the day I write the code, bugs would get fixed immediately.\n\n## Are security pros seen as too \"top down\" and \"out of touch\" with programming?\n\n*Brendan*: Oftentimes security and developers seem at odds. In many traditional organizations, this is both cultural AND related to misaligned incentives. If we only incentivize developers by the speed at which they are able to release new features while also incentivizing security professionals by number of incidents then the two are constantly at odds.\n\nThis is the same dichotomy of relationship that existed (and still does in some places) between developers and operators. If the only goal is fast feature shipping, you move fast and break things. If the only goal is a stable operating environment, then you’ll make sure no one is able to easily change or add anything.\n\nThat’s why the term \"DevOps\" was invented - to try and align incentives. Many organizations still struggle with that, but the [DORA research](https://www.devops-research.com/research.html) has shown us that the two can actually _complement_ each other if we focus on the metrics that really matter (frequency of deploys, time to fix an incident if one starts, etc.). What are those same metrics that will bring security and development together? They are probably very similar, but until organizations accept that and focus on cultural change to make sure that the teams incentives are truly aligned, it will continue to be a struggle.\n\n*Ethan*: This has not been my experience at GitLab. It really depends on how the security team was built. At GitLab, we like to believe that we’ve built a balanced team that covers the range of security skills, from lots of development experience and deep knowledge of secure coding techniques, to more dynamic security testing-oriented engineers who are working on building up their development skill set. Each of them are important to building a security program that enables and supports developers in building secure products.\n\n## Finally, will dev and sec *ever* get on the same page?\n\n*Ethan*: We need a realignment of expectations and support at all levels for developing a secure product. On the security side, the team has to realize that there will always be vulnerabilities that get to production. There is no way to catch them all. This is not only because of the fast nature of software development, but also because new attack vectors are discovered, and some things, like newly identified vulnerabilities in dependencies, are only identified after deployment. With that in mind, they should work towards providing developers the tools and data needed to identify them as early as possible, especially those vulnerabilities that are seen repeatedly. Also, there should be a well-known policy for handling vulnerabilities that are identified. That way, everyone knows what to do, and expectations are clearly defined.\n\n> If we only incentivize developers by the speed at which they are able to release new features while also incentivizing security professionals by number of incidents then the two are constantly at odds. – Brendan\n\nFrom the engineering side, it’s important to accept security as part of your development flow. It’s not glamorous, but the reason security is important is that it builds trust with customers and other stakeholders in your product. It also protects the company. Help the security team. This can be done by identifying areas of concern, asking questions, and helping security team members understand the code being written. For both teams, it’s important to have constructive communication and collaboration. There should be regular communication about what each team considers important and how that can be attained. Above all, there must be trust that the other team is doing what is best for the product.\n\n*Brendan*: Much like the last 10 years has seen businesses make themselves successful (or fail) based on their ability to deploy changes quickly and create a stable service, the next 10 years will see a similar transformation around security. The import of things like security, privacy, and data protection will require it of businesses, and those who are not able to adapt their culture will fade away. Those who have a radically different view of the world will thrive.\n\nIn the end, this is how dev and sec will \"have\" to get along.\n\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\n*Read more about development and security*:\n\n- How [secure](/blog/soc2-compliance/) is GitLab?\n\n- How we think about [security and open source software](/blog/open-source-security/)\n\n- GitLab's guide to [safe deployment practices](/blog/safe-deploys/)\n\nCover image by [Marcus Winkler](https://unsplash.com/@markuswinkler) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[9,741,783],{"slug":886,"featured":6,"template":699},"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":892,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":893,"content":898,"config":904,"_id":906,"_type":14,"title":907,"_source":16,"_file":908,"_stem":909,"_extension":19},"/en-us/blog/devsecops-survey-released",{"title":894,"description":895,"ogTitle":894,"ogDescription":895,"noIndex":6,"ogImage":817,"ogUrl":896,"ogSiteName":686,"ogType":687,"canonicalUrls":896,"schema":897},"Our 2020 DevSecOps Survey found faster releases and changing roles","Nearly 3700 software pros shared their DevOps successes, failures and thoughts on the future. Here’s what you need to know.","https://about.gitlab.com/blog/devsecops-survey-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our 2020 DevSecOps Survey found faster releases and changing roles\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-05-18\",\n      }",{"title":894,"description":895,"authors":899,"heroImage":817,"date":900,"body":901,"category":902,"tags":903},[779],"2020-05-18","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nIn February 2020, nearly 3700 DevOps practitioners from 21 countries shared, often in their own words, the reality of their software development journeys. They told us DevOps works for them: Nearly 83% said they’re releasing code faster and about 60% are deploying code either multiple times a day, daily, or every other day. But they also offered details of a less obvious but perhaps more important shift – their roles are changing, in some cases dramatically, because of DevOps.\n\nAlthough this survey was completed before today’s unprecedented economic upheaval, we think the insights in our [2020 Global DevSecOps Survey](/developer-survey/) may help you get a greater understanding of real world DevOps and the way job responsibilities are changing for developers, security pros, operations team members, and testers.\n\n## Dev + Ops\n\nWhy are developers releasing code more quickly with DevOps? For starters, they’re adding some of the key DevOps components including CI, SCM, automated testing, and CD.\n\n_\"Pre-deployment tests have provided more confidence that the product is ready to be released, also delivery frequency has increased.\"_\n\nBut the technology changes only tell part of the story. Traditional operations-type duties like provisioning or maintaining environments are increasingly part of development responsibilities. Over 34% of developers say they define and/or create the infrastructure their app runs on.\n\n_\"Deployment has become a non-task. Bootstrapping new projects is 10x faster because of the reusable infrastructure.\"_\n\nDevelopers say they’re no longer doing lots of hands-on tasks – like manual testing, deployments or merging – but they are increasingly responsible for security. In fact 28% say they’re now solely responsible for security in their organizations, a clear sign that security is beginning to \"shift left\" in a material way.\n\n_\"Security varies project to project. DevOps is usually tasked with 'protecting' our environments. We devs try to follow industry standards code-wise.\"_\n\n## An uneasy alliance\n\nAlthough security remains a work in progress at many if not most organizations, there are a few signs that [DevSecOps](/solutions/security-compliance/) is actually happening. Security professionals report that they are (finally) part of cross-functional teams and are working more closely with developers than ever before.\n\n_\"(Security) is becoming less focused into silo positions and more of a jack of all trades role.\"_\n\nIn fact 65% of security teams say their organizations have \"shifted left\" though, when we drilled down to find out what that actually meant, the details became much less clear. Fewer than 19% put SAST scan results into a pipeline report a developer can access and dynamic application security testing (DAST) fares even worse – less than 14% of companies give developers access to those reports.\n\nAt the same time, security teams continue to report that developers don't find enough bugs early enough in the process and/or that they’re reluctant to fix them when they are discovered.\n\nTo add to the confusion, 33% of security pros say they’re solely responsible for security in their organizations. But nearly the same percentage – 29% – say *everyone* is responsible. The ideal, of course, is what was shared by one survey taker:\n\n_\"We don’t have separate security, developers and operations; we are DevSecOps (and more).\"_\n\n## In the clouds\n\nOperations is often the place where the proverbial rubber hits the road and that’s particularly true with DevOps. In fact over 60% of operations team members report their roles are changing thanks to DevOps.\n\nWhat do these new roles look like?\n\n_\"Ops is 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_\"We keep the lights on.\"_\n\n_\"(Ops today is) anything between dev and ops. From planning to deployment but not monitoring and maintaining apps in production.\"_\n\nToday 42% of operations team members see their role as primarily managing hardware and infrastructure, while 52% say their first priority is managing cloud services.\n\n## The trouble with test\n\nFor the second year in a row our survey takers have pointed squarely to testing as the number one reason releases are delayed. Last year 49% said test was at fault; this year it was 47%.\n\nBut there are small signs of change. Almost three-quarters of organizations report they have shifted testing left, meaning they’ve moved it earlier into the development process. What does that actually mean? Approximately 31% said developers test some of their code and 25% said automated testing happens as code is being written. About 17% said dev and test work as a team to test \"as close to real time as possible,\" and about 9% said they practice test-driven development (TDD).\n\n_\"We do TDD. QA and dev act as a team. We have automated tests running parallel with developing code.\"_\n\nLike security, testers say they are now much more involved in the development process. Nearly 30% said they’re working more closely with developers, and 16% said they have \"a more visible seat at the table.\" And just over 15% said that thanks to DevOps, they’re much more likely to be able to \"test what matters.\"\n\n_\"We have to write less paper and tickets and have faster reaction times.\"_\n\n_\"We’re all the same – dev team is the ops team.\"_\n\n_\"We’re starting to see light at the end of the tunnel.\"_\n\n## Looking forward\n\nOur respondents had a big list of areas they hope to focus on for the future from automation to CI/CD and even going more deeply into DevOps. DevOps and lifelong learning clearly go hand in hand.\nBut let’s end on a high note. We asked developers how prepared they are for the future: 71% said prepared or very prepared, while less than 25% said \"not very prepared.\" But we like this comment left from one developer, who has the lifelong learning baked in:\n\n_\"I’m only prepared because I constantly keep tinkering on the side.\"_\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","news",[719,9,109],{"slug":905,"featured":6,"template":699},"devsecops-survey-released","content:en-us:blog:devsecops-survey-released.yml","Devsecops Survey Released","en-us/blog/devsecops-survey-released.yml","en-us/blog/devsecops-survey-released",{"_path":911,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":912,"content":917,"config":926,"_id":928,"_type":14,"title":929,"_source":16,"_file":930,"_stem":931,"_extension":19},"/en-us/blog/gitlab-global-devsecops-ai-report",{"title":913,"description":914,"ogTitle":913,"ogDescription":914,"noIndex":6,"ogImage":795,"ogUrl":915,"ogSiteName":686,"ogType":687,"canonicalUrls":915,"schema":916},"GitLab DevSecOps AI Report: A new software development era","Our survey found that DevSecOps teams are optimistic about AI, but privacy, security, and training emerged as key challenges to successful AI adoption.","https://about.gitlab.com/blog/gitlab-global-devsecops-ai-report","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Global DevSecOps AI Report: Ushering in a new era of software development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2023-09-12\",\n      }",{"title":918,"description":914,"authors":919,"heroImage":795,"date":921,"body":922,"category":923,"tags":924},"GitLab Global DevSecOps AI Report: Ushering in a new era of software development",[920],"Ashley Kramer","2023-09-12","\nAI has taken the world by storm, creating a tectonic shift across industries and society as a whole. With it, important discussions have emerged about its beneficial applications and the potential for negative repercussions, especially in the field of software development. AI is already changing how software is designed, built, secured, and deployed. With all of the industry buzz around the technology, it’s more important than ever to separate the hype from reality. \n\nThat’s why I’m pleased to share that GitLab has recently released its [Global DevSecOps Report: The State of AI in Software Development](https://about.gitlab.com/developer-survey/#ai). With this survey, we had one goal in mind: to uncover whether AI is living up to its promise. We surveyed more than 1,000 global senior technology executives, developers, and security and operations professionals to understand how organizations use AI in software development today, and what they hope to achieve with it in the future.\n\nMany of the sentiments reflected in the report echo what I hear firsthand from customers across industries and across the world: An eagerness to harness the benefits of AI for business innovation, while remaining cautious of potential risks. \n\nPerhaps unsurprisingly, privacy and security, productivity, and training emerged as key challenges to successful AI adoption. Organizations recognize that the policies and strategies put into place now, and the ways in which we shift our workflows to incorporate AI, will shape the future of software development. \n\nLet’s dive into a few of the key findings.\n\n> Download the full [Global DevSecOps Report: The State of AI in Software Development](https://about.gitlab.com/developer-survey/#ai).\n\n## As the excitement around AI increases, so do security concerns\nSecurity and privacy are top concerns, but they don’t detract from the urgency to implement AI. While 83% of those surveyed said that implementing AI in their software development processes is essential to avoid falling behind, 79% noted that they are concerned about AI tools having access to private information or intellectual property.\n\nThe top concern, by far, is the potential for sensitive information such as customer data being exposed (72%), and nearly half of respondents (48%) said they were concerned that trade secrets may be exposed. \n\nSimilarly, when it comes to the biggest concerns around introducing AI into the software development lifecycle, 48% said that AI-generated code may not be subject to the same copyright protection as human-generated code.\n\nGiven these results, it’s not surprising that 95% of senior technology executives said they prioritize privacy and protection of intellectual property when selecting an AI tool.\n\nTo safely benefit from AI, organizations can avoid pitfalls, including data leakage and security vulnerabilities, by first deploying it in a low-risk environment in their organization. This enables teams to learn by trial and error and build best practices before allowing additional teams to adopt AI, ensuring it scales safely and sustainably. \n\n## AI is poised to increase the productivity of some teams — and increase the workload of others\nDifferent business functions have different goals and use cases for AI, highlighting conflicting areas of opportunity and concern. \n\nOur survey findings show that 40% of security practitioners are worried that AI-powered code generation will increase their workload. However, code generation is just one of many areas where AI can add value. In our survey, developers told us that they spend only 25% of their total time writing code. The rest is spent improving existing code, understanding code, testing and maintaining code, and identifying and mitigating security vulnerabilities. Organizations stand to see major productivity and collaboration benefits by applying AI across the software development lifecycle.\n\t\t\t\nApproximately 50% of respondents expressed interest in AI-powered use cases across the software development lifecycle beyond code generation. In other words, there’s a strong appetite for more — and more integrated — AI spanning the breadth of the software development lifecycle. \n\n## Companies and employees are at odds over how to bridge the AI skills gap \nWhile organizations reported optimism about their company’s use of AI, our survey shows a discrepancy between organizations’ and practitioners’ satisfaction with AI training resources. \n\nDespite 75% of respondents saying their organization provides training and resources for using AI, a roughly equal proportion also said they are finding resources on their own, suggesting that the available resources and training within organizations may be insufficient. \n\nWith AI introducing a new set of skills to learn, 34% of respondents said they need training to use or interpret AI, and developers were significantly more likely to lack confidence in AI-generated output than either security or operations respondents (38% compared to 28% and 28%, respectively). \n\nOrganizations should focus on providing AI training and resources to all job roles and functional areas that will be using AI, and it is especially important to ensure that the resources for development teams are relevant, up to date, and cover the latest AI technologies and applications.\n\n## But wait, there’s more\nThese findings reinforce that for organizations to benefit from AI, it needs to be secure and delivered in a single application that is embedded across the entire software development lifecycle. \n\nThese core tenets guide our vision for the future of the GitLab AI-powered DevSecOps platform and [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our suite of AI capabilities that enables organizations to boost efficiency, productivity, and collaboration. Only by adopting a privacy-first, integrated approach to implementing AI can organizations be confident that their intellectual property is safe while empowering everyone to deliver better, more secure software faster. \n\nTo explore the full report, [download the Global DevSecOps Report: The State of AI in Software Development](https://about.gitlab.com/developer-survey/#ai).\n","ai-ml",[805,925,9],"AI/ML",{"slug":927,"featured":6,"template":699},"gitlab-global-devsecops-ai-report","content:en-us:blog:gitlab-global-devsecops-ai-report.yml","Gitlab Global Devsecops Ai Report","en-us/blog/gitlab-global-devsecops-ai-report.yml","en-us/blog/gitlab-global-devsecops-ai-report",{"_path":933,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":934,"content":939,"config":945,"_id":947,"_type":14,"title":948,"_source":16,"_file":949,"_stem":950,"_extension":19},"/en-us/blog/gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops",{"title":935,"description":936,"ogTitle":935,"ogDescription":936,"noIndex":6,"ogImage":795,"ogUrl":937,"ogSiteName":686,"ogType":687,"canonicalUrls":937,"schema":938},"GitLab survey highlights wins, challenges as orgs adopt DevSecOps","This year’s survey findings show that DevSecOps principles, together with a DevSecOps platform, help organizations ship more secure software, faster.","https://about.gitlab.com/blog/gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab survey highlights wins, challenges as orgs adopt DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2023-04-20\",\n      }",{"title":935,"description":936,"authors":940,"heroImage":795,"date":942,"body":943,"category":761,"tags":944},[941],"David DeSanto, Chief Product Officer, GitLab","2023-04-20","\nSecurity is everyone’s responsibility. And when everyone works together and has access to the same tools, you don’t have to sacrifice performance, efficiency, or security. That's the message from the respondents of our recent survey of software developers, IT operations, and IT security professionals worldwide. Where there is unity among Development, Security, and Operations in the common goal of securing the software supply chain, there is success.\n\nOur first report from the survey, [Security Without Sacrifices](https://about.gitlab.com/developer-survey/), focuses on this throughline and illuminates where [DevSecOps](/topics/devsecops/) professionals feel positive about their efforts to secure the software development lifecycle and where they feel work still needs to be done. While the results are not surprising — they align with what I hear from customers every day — they reinforce GitLab’s belief that DevSecOps principles, coupled with a DevSecOps platform, help organizations ship more secure software, faster.\n\nFor instance, in last year’s report, a majority of development, security, and operations professionals said they felt individually responsible for security. This year, 53% of respondents said they are responsible for application security *as part of a larger team*. And 71% of security professionals said at least a quarter of all security vulnerabilities are being spotted by developers, up from 53% in 2022.\n\nWhat this tells us is that security is indeed making its way deep into the software development lifecycle and as more innovation is introduced into the daily workflow, including AI-assisted capabilities, the benefits are tangible.\n\nHere’s what the report findings suggest organizations should keep in mind so they can get the most out of DevSecOps.\n\n## AI is now inseparable from DevSecOps\nFor the past several years, we’ve seen AI become more and more established in software development workflows. In this year’s report, nearly two-thirds (65%) of developers said they are using AI in testing efforts or will be in the next three years. We also saw an uptick this year in the number of developers who are using AI to check code.\n\nAI represents a tectonic shift in the market that will have profound effects on how organizations deliver value to customers. To take full advantage of AI, it will be critical for organizations to apply AI-assisted workflows across the entire software development lifecycle and make them available to all personas — not just developers but everyone involved in the delivery of software value, from security and compliance teams to product development and marketing.\n\n## Security toolchain expansion is unsustainable\nThis year’s report showed that toolchain sprawl may be a bigger concern for security professionals than for the rest of the team; 57% of security respondents said they use six or more tools, compared to 48% of developers and 50% of operations professionals. We’re also seeing signs that security professionals are using _more_ tools than in past years. This is in line with what security practitioners tell me: They use different tools for each security function, including composition analysis, fuzzing, DAST, and dependency scanning.\n\nThe rise of DevOps and DevSecOps is making it easier for software development teams to consolidate tools, but the increased pressure around software supply chain security means this trend is not holding for security as it is for other roles. Security practitioners select the tools that get the job done and the tools they’re most comfortable with, but as security budgets tighten, that’s no longer going to be a sustainable strategy. We should expect to see a bigger push to consolidate security toolchains over the next several years.\n\n## Efficiency and security cannot be mutually exclusive\nThe first wave of budget tightening seems to be here already — 85% of the security professionals we surveyed told us they have the same or less budget this year than they did in 2022, and security professionals were also more likely than both developers and operations professionals to cite macroeconomic forces as a primary factor driving DevOps/DevSecOps to scale at their organizations. In this environment, organizations (and security teams) need to do more with less.\n\nFor many of the organizations I’ve talked to, tighter budgets mean more than just cutting costs. Organizations need to ensure they’re getting a swifter return on their DevSecOps investments. That return on investment could look like increased efficiency, translating into accelerated value delivery for customers, faster innovation, and more revenue. Or it could mean incorporating security and compliance tools earlier in the development lifecycle, reducing risk. Ideally, it’s all of the above. As organizations seek ways to stay ahead of the competition, security and efficiency are both non-negotiable.\n\n## A platform approach: The winning formula for DevSecOps\nHow can organizations foster collaboration, reduce toolchain friction, and boost efficiency without sacrificing security? A platform that puts DevSecOps methodologies into practice. This year’s respondents identified security and efficiency as the top two benefits of adopting a DevSecOps platform, ahead of automation, cost savings, and collaboration.\n\nA DevSecOps platform enables teams to collaborate in a single application, shortening cycle times, reducing risks, and accelerating everyone’s workflows. We see proof points in this year’s data: Security professionals who use a DevSecOps platform were significantly more likely than those who don’t use a platform to say developers catch more security vulnerabilities and had a higher opinion of their organization’s security efforts.\n\nIt has become important for organizations to foster collaboration and engagement to keep development, security, and operations teams happy.\n\n## Explore this year’s report\nRead the first report in our 2023 Global DevSecOps Report Series, [Security Without Sacrifices](https://about.gitlab.com/developer-survey/), and stay tuned for more reports on the data in the coming months.\n",[9,805,741,925],{"slug":946,"featured":6,"template":699},"gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops","content:en-us:blog:gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops.yml","Gitlab Survey Highlights Wins Challenges As Orgs Adopt Devsecops","en-us/blog/gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops.yml","en-us/blog/gitlab-survey-highlights-wins-challenges-as-orgs-adopt-devsecops",{"_path":952,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":953,"content":959,"config":964,"_id":966,"_type":14,"title":967,"_source":16,"_file":968,"_stem":969,"_extension":19},"/en-us/blog/gitlabs-2021-survey-uncovers-a-new-devops-maturity-model",{"title":954,"description":955,"ogTitle":954,"ogDescription":955,"noIndex":6,"ogImage":956,"ogUrl":957,"ogSiteName":686,"ogType":687,"canonicalUrls":957,"schema":958},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749664041/Blog/Hero%20Images/open-devops.png","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":954,"description":955,"authors":960,"heroImage":956,"date":961,"body":962,"category":695,"tags":963},[779],"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",[9,719,741],{"slug":965,"featured":6,"template":699},"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":971,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":972,"content":978,"config":984,"_id":986,"_type":14,"title":987,"_source":16,"_file":988,"_stem":989,"_extension":19},"/en-us/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment",{"title":973,"description":974,"ogTitle":973,"ogDescription":974,"noIndex":6,"ogImage":975,"ogUrl":976,"ogSiteName":686,"ogType":687,"canonicalUrls":976,"schema":977},"DevSecOps Survey 2022: Security leads concern and investment","Find out if your successes and concerns about security and more match those of your peers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663982/Blog/Hero%20Images/2022-devsecops-survey-blog-header.png","https://about.gitlab.com/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's 2022 Global DevSecOps Survey: Security is the top concern, investment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-08-23\",\n      }",{"title":979,"description":974,"authors":980,"heroImage":975,"date":981,"body":982,"category":761,"tags":983},"GitLab's 2022 Global DevSecOps Survey: Security is the top concern, investment",[779],"2022-08-23","\nThe days of security as a “nice to have” are officially over as we enter the era of [DevSecOps](/topics/devsecops/). In our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) of more than 5,000 practitioners, security was the driving force behind technology choices, team structure, DevOps platform use, and more.\n\nThe findings from our [sixth annual survey](/developer-survey/) represent a dramatic shift from past years, when security teams – and security concerns – were often siloed and silenced in the push to get software out the door faster.\n\nNothing could be further from the truth today:\n\n- The number one reason to implement a DevOps platform? Security. (And 75% of DevOps teams use a [DevOps platform](/topics/devops-platform/) currently or plan to this year.)\n\n- The number one benefit of a DevOps platform? Security.\n\n- The number one investment priority for 2022? Security.\n\nThe attention to security in DevOps teams doesn’t stop there. As our surveys have shown since 2020, [DevOps roles continue to shift](/blog/software-developer-changing-role/), and this year, many of those shifts were laser-focused on security.\n\n- 53% of developers told us they’re “fully responsible” for security in their organizations, a 14 point increase from 2021.\n\n- Over one-third of security pros report being “hands on” and involved on a daily basis with dev and ops, an 11% increase from last year (and a massive cultural shift from groups not always known to get along).\n\n- Almost 50% of ops pros say they’re fully responsible for security in their organizations, up 20% from last year.\n\nAnd when we asked developers about the most difficult parts of their jobs, thousands pointed to security and security-related concerns. Three developers summed it up:\n\n_“Cyber security attacks are the biggest concerns facing us today.”_\n\n_“Data security, data security, I repeat, data security.”_\n\n_“Trying to build applications that are secure and stable.”_\n\n## More work to do\n\nSecurity clearly has a seat at the DevOps table today, but areas of friction remain.\n\nFor starters, security testing requires a balance that’s difficult to achieve. Static application security testing [(SAST)](/direction/secure/static-analysis/sast/), dynamic application security testing [(DAST)](/direction/secure/dynamic-analysis/dast/), and container and dependency scans are increasing, which is good news, but the percentage of devs able to easily access those results in their workflows remains stubbornly low (30% or less).\n\nAnd sec and dev [may never see eye to eye](/blog/developer-security-divide/) on finding and fixing bugs. For the third year in a row, sec pros said devs don’t find enough bugs early enough in the process, meaning they are stuck finding and fixing them much later (when it’s more difficult). And, as we’ve heard repeatedly over the last years, security’s focus and development’s focus aren’t usually the same:\n\n**57% of sec pros said finding bugs was a developer performance metric in their organizations, but 56% said it was difficult to get developers to actually prioritize bug remediation.**\n\n## Facing the future\n\nWhile security pros feel good about their organizations’ security postures (71% rated them as “good” or “very good”), they’re not feeling particularly optimistic about the future. A full 43% said they feel “somewhat” or “very” unprepared for the future; to look at it from another way, the percentage of sec pros who are confident, 56%, is 20 points *lower* than either their ops or dev colleagues.\n\nWhat can help power security professionals into the future? Surprisingly, the top answer (54%) is AI, which was a 33% increase from last year. Since 2020, sec respondents have said soft skills like communication and collaboration were most important but this year soft skills came in second place.\n\nSecurity is just one of many themes – automation, AI, information overload, real world challenges, compliance, and faster releases, to name just a few – our survey uncovered. So download and share the entire report, [“The 2022 DevSecOps Survey: Thriving in an Insecure World”](/developer-survey/), to dig deeper into them.\n\n## Read the previous surveys!\n\n[GitLab 2021 DevSecOps Survey](/developer-survey/previous/2021)\n\n[GitLab 2020 Global Developer Report: DevSecOps](/developer-survey/previous/2020/)\n\n[GitLab 2019 Global Developer Report: DevSecOps](/developer-survey/previous/2019/)\n",[9,719,741],{"slug":985,"featured":6,"template":699},"gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment","content:en-us:blog:gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment.yml","Gitlabs 2022 Global Devsecops Survey Security Is The Top Concern Investment","en-us/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment.yml","en-us/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment",{"_path":991,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":992,"content":998,"config":1004,"_id":1006,"_type":14,"title":1007,"_source":16,"_file":1008,"_stem":1009,"_extension":19},"/en-us/blog/global-developer-report",{"title":993,"description":994,"ogTitle":993,"ogDescription":994,"noIndex":6,"ogImage":995,"ogUrl":996,"ogSiteName":686,"ogType":687,"canonicalUrls":996,"schema":997},"2019 Global Developer Report: security roadblocks hit 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":999,"description":994,"authors":1000,"heroImage":995,"date":1001,"body":1002,"category":695,"tags":1003},"2019 Global Developer Report: DevSecOps finds security roadblocks divide teams",[715],"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",[9,719,902],{"slug":1005,"featured":6,"template":699},"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":1011,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1012,"content":1017,"config":1023,"_id":1025,"_type":14,"title":1026,"_source":16,"_file":1027,"_stem":1028,"_extension":19},"/en-us/blog/how-modern-devops-practices-are-changing-the-operations-role",{"title":1013,"description":1014,"ogTitle":1013,"ogDescription":1014,"noIndex":6,"ogImage":975,"ogUrl":1015,"ogSiteName":686,"ogType":687,"canonicalUrls":1015,"schema":1016},"How modern DevOps practices are changing the operations role","Today, the ops role is about far more than just keeping the lights on. Here's how modern DevOps practices are expanding ops' responsibilities.","https://about.gitlab.com/blog/how-modern-devops-practices-are-changing-the-operations-role","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How modern DevOps practices are changing the operations role\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-10-19\",\n      }",{"title":1013,"description":1014,"authors":1018,"heroImage":975,"date":1019,"body":1020,"category":761,"tags":1021},[779],"2022-10-19","\nRemember NoOps, the idea that automation would eliminate the operations role completely? Fast forward a few years and the idea of NoOps today seems almost laughable. In today’s modern DevOps teams it’s safe to say it’s really _“AlltheOps_,” at least based on the results of our [2022 Global DevSecOps Survey](/developer-survey/).\n\n## An expanding role\n\n[No DevOps job is static](/blog/the-changing-roles-in-devsecops/), but ops pros are experiencing truly dramatic changes to their work lives. In fact, ops pros reported seven areas of responsibility now added to their plates thanks to modern DevOps practices:\n\n- Managing the cloud\n- Managing the hardware/infrastructure\n- Maintaining the toolchain\n- DevOps coaching\n- Responsibility for automation\n- Overseeing all compliance and audits\n- Platform engineering\n\nManaging the cloud and hardware/infrastructure were the two tasks most frequently named, and they were split nearly evenly down the middle, with roughly 50% of ops pros focusing on one or the other task primarily. Another area – [maintaining the toolchain](/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer/) – is apparently now a job shared with developers, as devs also told us they were spending more time on toolchain maintenance and integration than ever before. That’s not surprising: 44% of teams reported they use between two and five tools, while 41% use between six and 10 tools. That’s a lot of tools, which is clearly one reason for the added ops support. \n\nCompliance and audits are another “new to Ops” area of focus, and this added emphasis comes at a time when organizations everywhere are trying to avoid security breaches with [an increased focus on compliance](/blog/the-importance-of-compliance-in-devops/). It’s a time-consuming process: The majority of ops pros told us they spend between one-quarter and half their time [on audits and compliance](/blog/what-you-need-to-know-about-devops-audits/), a 15% increase since 2021. Almost 25% of ops pros spend between half and three-quarters of their time on these tasks. \n\n## Keeping the balls in the air\n\nThe rising use of [DevOps platforms](/topics/devops-platform/) (75% of our respondents said their organizations already use a DevOps platform or plan to add one this year) is driving operations team members toward [platform engineering](/topics/devops/what-is-a-devops-platform-engineer/). Operations pros are also doubling down on tasks that were likely more informal in the past: DevOps coaching and responsibility for automation. The focus on automation is clearly paying off: In 2022, just shy of 25% of ops pros said their modern DevOps practices were fully automated, up 5 points from 2021 and nearly 17 points from 2020. All told, 68% of ops pros said their DevOps teams were “completely” or “mostly” automated.\n\nAnd while ops is adding new responsibilities thanks to modern DevOps, developers are picking up tasks that have traditionally belonged to operations:\n\n- Nearly 77% of devs can provision their own environments.\n- Roughly 38% of developers instrument the code.\n- Another 38% monitor and respond to the infrastructure. \n- 36% of devs said they’re on-call for in-app production alerts.\n\nThe role-swapping doesn't stop there: Nearly 50% of ops pros said they're solely responsible for security on their DevOps teams, up 20% from last year. To put that into perspective, 53% of security respondents told us they felt security was *everyone's* responsiblity.\n\n## Ops, modern DevOps, and TMI\n\nOps pros’ new roles have created some surprising by-products, namely loads of data that teams aren’t necessarily set up to manage effectively. In fact, many of today’s operations teams have a “too much information” problem. A full 39% of ops pros said the DevOps data they need exists but accessing and managing it is difficult. Another 27% said they’re “overwhelmed” by the amount and scope of the data while 14% don’t know what data they need or say their organizations don’t track it. Less than 20% of ops pros say they have the data they need and it’s easy to work with.\n\nHow do you see the ops role changing in the modern DevOps world? Let us know in the comments.\n",[719,9,1022],"contributors",{"slug":1024,"featured":6,"template":699},"how-modern-devops-practices-are-changing-the-operations-role","content:en-us:blog:how-modern-devops-practices-are-changing-the-operations-role.yml","How Modern Devops Practices Are Changing The Operations Role","en-us/blog/how-modern-devops-practices-are-changing-the-operations-role.yml","en-us/blog/how-modern-devops-practices-are-changing-the-operations-role",{"_path":1030,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1031,"content":1037,"config":1048,"_id":1050,"_type":14,"title":1032,"_source":16,"_file":1051,"_stem":1052,"_extension":19},"/en-us/blog/jira-importer-research",{"title":1032,"description":1033,"ogTitle":1032,"ogDescription":1033,"noIndex":6,"ogImage":1034,"ogUrl":1035,"ogSiteName":686,"ogType":687,"canonicalUrls":1035,"schema":1036},"Jira Importer Research","Senior Product Designer Holly Reynolds is seeking participants for research surrounding importing Jira issues.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679490/Blog/Hero%20Images/jira-importer-blog-post.png","https://about.gitlab.com/blog/jira-importer-research","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jira Importer Research\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-04-08\",\n      }",{"title":1032,"description":1033,"authors":1038,"heroImage":1034,"date":1040,"body":1041,"category":1042,"tags":1043},[1039],"Holly Reynolds","2020-04-08","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nWorking with multiple DevOps applications including Jira and GitLab? Looking to consolidate to or test drive GitLab with your own existing Jira issues? We are researching ways to provide options for importing issues from Jira into GitLab and need your help!\n\n**Problem Overview**\nWe believe our [Project Management](https://about.gitlab.com/solutions/agile-delivery/) users need a way to easily transfer existing issues from Jira into GitLab beyond what's possible with CSV exports. We want to dive deeper into understanding what will provide the most value for these users in this import process from the start and what their expectations are for this experience.\n\n**Our recruiting Challenge**\nThis is a bit of a unique group we're seeking feedback from in that a specific persona may not always apply. For example, both a [Systems Admin](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) or a [DevOps Engineer](https://handbook.gitlab.com/handbook/product/personas/#devon-devops-engineer) could be responsible for helping their team transition from Jira to GitLab. We'd like to hear from anyone with issues currently in Jira that would like to import them into GitLab via an API.\n","unfiltered",[1044,1045,1046,9,1047],"features","design","UX","research",{"slug":1049,"featured":6,"template":699},"jira-importer-research","content:en-us:blog:jira-importer-research.yml","en-us/blog/jira-importer-research.yml","en-us/blog/jira-importer-research",{"_path":1054,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1055,"content":1061,"config":1067,"_id":1069,"_type":14,"title":1070,"_source":16,"_file":1071,"_stem":1072,"_extension":19},"/en-us/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say",{"title":1056,"description":1057,"ogTitle":1056,"ogDescription":1057,"noIndex":6,"ogImage":1058,"ogUrl":1059,"ogSiteName":686,"ogType":687,"canonicalUrls":1059,"schema":1060},"Making the case for a DevOps platform: What data and customers say","Don't just take our word for why a DevOps platform means better DevOps and faster, safer releases: here's what the latest data shows and how customers have benefitted.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Making the case for a DevOps platform: What data and customers say\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-09-08\",\n      }",{"title":1056,"description":1057,"authors":1062,"heroImage":1058,"date":1063,"body":1064,"category":761,"tags":1065},[779],"2021-09-08","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nIn the struggle to release safer software faster, development teams are increasingly choosing a DevOps platform to help them get there. In our [2021 Global DevSecOps Survey](/developer-survey/) we asked respondents what their DevOps practices included and a \"DevOps platform\" was among the top four choices, right next to CI/CD, test automation, and DevSecOps.\n\nWe're of course bullish on the idea of a DevOps platform, but we're far from alone. Here's a fresh look at how the data – and the customers – support the optimistic trajectory of a DevOps platform.\n\n## DevOps is hot\n\nThe DevOps market was worth $6 billion in 2020, according to Global Industry Analysts, and five-year growth forecasts range from $17 billion to as much as $23 billion, depending on the firm. \n\n**[Watch a [deep dive into GitLab's DevOps Platform](https://www.youtube.com/watch?v=wChaqniv3HI)]**\n\nThis probably doesn't need saying, but one reason the market is so strong is that DevOps works. In late 2020, Forrester Research conducted \"The State of Modern Technology Operations Q4 2020,\" and concluded [\"the DevOps hypothesis is sound\"](https://go.forrester.com/blogs/the-devops-hypothesis-is-sound-introducing-the-2020-state-of-modern-technology-operations-survey/). The report went further to say that companies successfully working in a DevOps/Agile model were able to release faster and thus have higher revenue growth. \n\n## A DevOps platform is the logical next step\n\nBut in order to do DevOps a team needs tools, and too many tools results in a toolchain, which is where things can get very messy quickly. Time consuming handoffs, integrations and maintenance lead to what Forrester calls the \"DevOps tax\" of roughly 10%, meaning teams have to spend that much of their time each month just trying to keep the toolchains running. (In [our 2021 Survey](/developer-survey/), the tax was even higher: 20% of survey takers said they spend between 11% and 20% of their time just on toolchain maintenance and integration).\n\n**[Use a DevOps platform to [avoid the DevOps tax](/topics/devops/use-devops-platform-to-avoid-devops-tax/)]**\n\nA DevOps platform with end-to-end visibility and everything in one place eliminates the tax and boosts DevOps performance. Nearly 12% of survey respondents told us that adding a DevOps platform has allowed them to release software faster. Overall, our survey takers said the use of a DevOps platform resulted in better DevOps, improved collaboration, easier automation and more comprehensive visibility/traceability. \n\nOne developer put it succinctly: \"[Using a DevOps platform] means reduced mean time to recovery (MTTR), quicker time to market, reduced lead time for fixes, and fewer change failures.\"\n\nAnd if all of that wasn't enough, a single DevOps platform gives *everyone* in the company the ability to see and participate in the process. In fact, 23% of our survey takers said everyone in their company – not just Dev and Ops – actually uses the DevOps platform. \n\n## DevOps platforms in the real world\n\nHow do teams really take advantage of a DevOps platform?\n\n[BI Worldwide](/customers/bi-worldwide/), a global engagement agency, found the ability to tie all the processes together made a difference. \"One tool for SCM+CI/CD was a big initial win,\" says Adam Dehnel, product architect at BI. \"Now wrapping security scans into that tool as well has already increased our visibility into security vulnerabilities. The integrated Docker registry has also been very helpful for us. Issue/Product management features let everyone operate in the same space regardless of role.\"\n\n**[How to [get the most out of your DevOps platform](/topics/devops/seven-tips-to-get-the-most-out-of-your-devops-platform/)]**\n\nLess turned out to be more at [Glympse](/customers/glympse/), a geo-location sharing service provider that consolidated close to 20 different tools into GitLab. \"Development can move much faster when engineers can stay on one page and click buttons to release auditable changes to production and have easy rollbacks; everything is much more streamlined,\" explains Zaq Wiedmann, lead software engineer at Glympse. \"Within one sprint, just 2 weeks, Glympse was able to implement security jobs across all of their repositories using GitLab's CI templates and their pre-existing Docker-based deployment scripts.\"\n\nWant a more detailed look at the role a DevOps platform can play in your organization? Explore our [comprehensive guide to DevOps platforms](/topics/devops-platform/).\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 the DevOps Platform:\n\n- [The journey to a DevOps Platform](/blog/the-journey-to-a-devops-platform/)\n\n- [How ten steps over ten years led to the DevOps Platform](/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform/)\n\n- [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",[719,9,1066],"user stories",{"slug":1068,"featured":6,"template":699},"making-the-case-for-a-devops-platform-what-data-and-customers-say","content:en-us:blog:making-the-case-for-a-devops-platform-what-data-and-customers-say.yml","Making The Case For A Devops Platform What Data And Customers Say","en-us/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say.yml","en-us/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say",{"_path":1074,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1075,"content":1081,"config":1088,"_id":1090,"_type":14,"title":1091,"_source":16,"_file":1092,"_stem":1093,"_extension":19},"/en-us/blog/managers-more-optimistic-than-developers",{"title":1076,"description":1077,"ogTitle":1076,"ogDescription":1077,"noIndex":6,"ogImage":1078,"ogUrl":1079,"ogSiteName":686,"ogType":687,"canonicalUrls":1079,"schema":1080},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749663753/Blog/Hero%20Images/managers-more-optimistic-than-developers.jpg","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":1076,"description":1077,"authors":1082,"heroImage":1078,"date":1084,"body":1085,"category":695,"tags":1086},[1083],"Emily von Hoffmann","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",[9,1087,719],"careers",{"slug":1089,"featured":6,"template":699},"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":1095,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1096,"content":1101,"config":1106,"_id":1108,"_type":14,"title":1109,"_source":16,"_file":1110,"_stem":1111,"_extension":19},"/en-us/blog/many-meanings-multicloud",{"title":1097,"description":1098,"ogTitle":1097,"ogDescription":1098,"noIndex":6,"ogImage":817,"ogUrl":1099,"ogSiteName":686,"ogType":687,"canonicalUrls":1099,"schema":1100},"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":1097,"description":1098,"authors":1102,"heroImage":817,"date":1103,"body":1104,"category":695,"tags":1105},[779],"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",[825,9,719],{"slug":1107,"featured":6,"template":699},"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":1113,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1114,"content":1120,"config":1127,"_id":1129,"_type":14,"title":1130,"_source":16,"_file":1131,"_stem":1132,"_extension":19},"/en-us/blog/new-to-devops-take-our-devops-for-beginners-quiz",{"title":1115,"description":1116,"ogTitle":1115,"ogDescription":1116,"noIndex":6,"ogImage":1117,"ogUrl":1118,"ogSiteName":686,"ogType":687,"canonicalUrls":1118,"schema":1119},"New to DevOps? Take our DevOps for beginners quiz","We asked nearly 1400 DevOps beginners about their priorities and challenges for 2022. See how you compare, and take our short DevOps for beginners quiz.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663743/Blog/Hero%20Images/three-things-i-learned-in-my-first-month-at-gitlab.jpg","https://about.gitlab.com/blog/new-to-devops-take-our-devops-for-beginners-quiz","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New to DevOps? Take our DevOps for beginners quiz\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-13\",\n      }",{"title":1115,"description":1116,"authors":1121,"heroImage":1117,"date":1123,"body":1124,"category":761,"tags":1125},[1122],"GitLab","2022-09-13","__Update: The quiz mentioned here has been closed.__\n\nOver the last 12 months, we’ve asked three [\"DevOps for beginners\"](https://about.gitlab.com/topics/devops/beginner-devops-platform/) questions of nearly 1400 people:\n\n- What’s the most important skill you hope to learn this year?\n- What continues to be your team’s biggest DevOps challenge?\n- What is your DevOps team’s top priority for 2022?\n\nA resounding majority (nearly 83%) told us they want to learn a new programming language and about 15% hope to get better at automation.\n\n(Learn the basics of Python with our [5-part series](/blog/learn-python-with-pj-part-1/), understand [Rust](/blog/secure-rust-development-with-gitlab/), or [get started with CI/CD](/blog/beginner-guide-ci-cd/).)\n\nWhat are they struggling with?\n\nJust over 70% said security was the biggest challenge for their DevOps team this year (a result that tracks with our just released [Global DevSecOps Survey](/developer-survey/)), while just shy of 24% said it was testing (again, that’s [a very common complaint](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/)).\n\nThe top priorities for 2022 were split between increasing automation (47%) and moving to a [DevOps platform](/topics/devops-platform/) (23%).\n\nAnd we have more DevOps for beginner resources here:\n\n[Beginner’s Guide to DevOps eBook](https://page.gitlab.com/resources-ebook-beginners-guide-devops.html)\n\nA [step-by-step](/blog/if-its-time-to-learn-devops-heres-where-to-begin/) look at how to get started with DevOps\n\nA [guide to Git for beginners](/blog/beginner-git-guide/)\n\n[Continuous integration](/blog/a-beginners-guide-to-continuous-integration/)for beginners\n",[719,9,1126],"production",{"slug":1128,"featured":6,"template":699},"new-to-devops-take-our-devops-for-beginners-quiz","content:en-us:blog:new-to-devops-take-our-devops-for-beginners-quiz.yml","New To Devops Take Our Devops For Beginners Quiz","en-us/blog/new-to-devops-take-our-devops-for-beginners-quiz.yml","en-us/blog/new-to-devops-take-our-devops-for-beginners-quiz",{"_path":1134,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1135,"content":1141,"config":1147,"_id":1149,"_type":14,"title":1150,"_source":16,"_file":1151,"_stem":1152,"_extension":19},"/en-us/blog/remote-work-facilitates-devops",{"title":1136,"description":1137,"ogTitle":1136,"ogDescription":1137,"noIndex":6,"ogImage":1138,"ogUrl":1139,"ogSiteName":686,"ogType":687,"canonicalUrls":1139,"schema":1140},"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":1136,"description":1137,"authors":1142,"heroImage":1138,"date":1143,"body":1144,"category":695,"tags":1145},[715],"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",[1146,719,9],"remote work",{"slug":1148,"featured":6,"template":699},"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":1154,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1155,"content":1161,"config":1167,"_id":1169,"_type":14,"title":1170,"_source":16,"_file":1171,"_stem":1172,"_extension":19},"/en-us/blog/software-developer-changing-role",{"title":1156,"description":1157,"ogTitle":1156,"ogDescription":1157,"noIndex":6,"ogImage":1158,"ogUrl":1159,"ogSiteName":686,"ogType":687,"canonicalUrls":1159,"schema":1160},"Software developer roles: How responsibilities are evolving","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":1162,"description":1157,"authors":1163,"heroImage":1158,"date":1164,"body":1165,"category":695,"tags":1166},"The software developer role and responsibilities are changing. Here's what to expect",[779],"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/) 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",[719,9,902],{"slug":1168,"featured":6,"template":699},"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":1174,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1175,"content":1181,"config":1186,"_id":1188,"_type":14,"title":1189,"_source":16,"_file":1190,"_stem":1191,"_extension":19},"/en-us/blog/the-changing-roles-in-devsecops",{"title":1176,"description":1177,"ogTitle":1176,"ogDescription":1177,"noIndex":6,"ogImage":1178,"ogUrl":1179,"ogSiteName":686,"ogType":687,"canonicalUrls":1179,"schema":1180},"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":1176,"description":1177,"authors":1182,"heroImage":1178,"date":1183,"body":1184,"category":695,"tags":1185},[779],"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/), 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",[9,719,1087,741],{"slug":1187,"featured":6,"template":699},"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":1193,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1194,"content":1199,"config":1204,"_id":1206,"_type":14,"title":1207,"_source":16,"_file":1208,"_stem":1209,"_extension":19},"/en-us/blog/the-code-review-struggle-is-real-heres-what-you-need-to-know",{"title":1195,"description":1196,"ogTitle":1195,"ogDescription":1196,"noIndex":6,"ogImage":817,"ogUrl":1197,"ogSiteName":686,"ogType":687,"canonicalUrls":1197,"schema":1198},"The code review struggle is real. Here's what you need to know","If it's time for a DevOps Platform, don't forget the role code review plays. Our 2021 Global DevSecOps Survey showed why it's both critical and tricky to get right.","https://about.gitlab.com/blog/the-code-review-struggle-is-real-heres-what-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The code review struggle is real. Here's what you need to know\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-09-03\",\n      }",{"title":1195,"description":1196,"authors":1200,"heroImage":817,"date":1201,"body":1202,"category":761,"tags":1203},[779],"2021-09-03","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nWhen making a list of the reasons to consider moving to a DevOps Platform, don't forget about code review, a critical piece of the process that's also an incredible source of frustration and delays to developers and their teams.\n\nIn our [2021 Global DevSecOps Survey](/developer-survey/), respondents told us code quality was the number one reason they chose DevOps. But, when asked what was most likely to delay a product release, code review – vital to code quality – was one of the top four culprits (the others were testing, planning and code development). \n\nThe fact that code review is a pain point is hardly surprising, given that it can often require context-switching, communication, collaboration, and of course subject matter expertise. At a time when it's never been more urgent to release secure code as quickly as possible, it's not a stretch to think code reviews can feel like a hard stop to some teams, particularly if the process is not integrated into an existing workflow.\n\n**[Here's everything you need to know about a [DevOps Platform](/topics/devops-platform/)]**\n\n## Why code review is painful\n\nIn fact, when we asked our survey respondents to tell us in their own words what they struggle with when it comes to code review, they had \\*a lot\\* to say on the subject.\n\n*\"Code reviews can take a long time due to the lack of reviewers.\"*\n\n*\"Many people find it a chore to review code.\"*\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 they achieved what they did.\"*\n\n*\"Developers are sometimes unaware they have to do code reviews. They aren't sure how to perform them and if they are effective. Sometimes they are skipped so the process can go through.\"*\n\n*\"Finding someone for code review can be hard (1-day average). After that, business tests take time to be completed (2-4 days on average).\"*\n\n[Code review is tricky](/blog/challenges-of-code-reviews/), but almost 60% of those surveyed said the reviews were \"very valuable\" in ensuring code quality and security. And it's not like teams aren't actually tackling code review: In 2021 close to 45% of respondents said they review code weekly, and 22% do it every other week – a 14% jump from 2020.\n\n**[Your organization needs a DevOps Platform team. [Here's why](/topics/devops/how-and-why-to-create-devops-platform-team/)]**\n\nBut anecdotal data tells a slightly different story, from developers saying their teams do no code review at all, to code reviews so comprehensive they include every merge request, ticket, or pull. Many developers said they review code daily, or even multiple times a day. Survey takers said code reviews were most likely conducted using online chat, with developers showing a strong preference for reviewing code in an IDE rather than a browser.\n\n## Better code reviews\n\nAt GitLab we pride ourselves in dogfooding our DevOps Platform, so of course we spend a lot of time thinking about how to [improve our code review process](/blog/better-code-reviews/). We've had a lot of success [using smaller merge requests](/blog/iteration-and-code-review/), as just one example.\n\nOur survey takers told us they were on the same continuous improvement journey – many spent the past year [evaluating how to make their code reviews and other DevOps stages more efficient](/blog/efficient-code-review-tips/). One respondent offered a detailed look:\n\n*\"We evaluated the team and did value stream mapping and finalized the desired state. In most of the cases we found the team needs an automated pipeline for faster delivery and immediate feedback so that they can act fast rather than later. We also moved security left so that developers can fix security issues fast. And we also made sure developers are doing code review in a collaborative way through pull requests.\"*\n\nAnother team focused exclusively on reducing its dependence on code review:\n\n*\"(We are no longer) relying on code review to have caught all the test scenarios. We now use a coverage scanning tool to tell us if we've got it all.\"*\n\n## More code reviews > less code reviews\n\nThe struggle is real, but so is the importance. Despite a lot of complaining about code review, developers remained adamant about its importance in DevOps. When we asked devs what they wish they could do more of, code review was at the top of the list, with more than 1000 survey takers indicating they wish they could do way more code reviews than they're doing at present.\n\nIn our next blog post, we'll outline five ways GitLab's DevOps Platform has made code reviews easier.\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",[825,719,9],{"slug":1205,"featured":6,"template":699},"the-code-review-struggle-is-real-heres-what-you-need-to-know","content:en-us:blog:the-code-review-struggle-is-real-heres-what-you-need-to-know.yml","The Code Review Struggle Is Real Heres What You Need To Know","en-us/blog/the-code-review-struggle-is-real-heres-what-you-need-to-know.yml","en-us/blog/the-code-review-struggle-is-real-heres-what-you-need-to-know",{"_path":1211,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1212,"content":1217,"config":1222,"_id":1224,"_type":14,"title":1225,"_source":16,"_file":1226,"_stem":1227,"_extension":19},"/en-us/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook",{"title":1213,"description":1214,"ogTitle":1213,"ogDescription":1214,"noIndex":6,"ogImage":956,"ogUrl":1215,"ogSiteName":686,"ogType":687,"canonicalUrls":1215,"schema":1216},"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://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":1213,"description":1214,"authors":1218,"heroImage":956,"date":1219,"body":1220,"category":695,"tags":1221},[779],"2021-05-06","\nOur [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) 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",[9,719,741],{"slug":1223,"featured":6,"template":699},"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":1229,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1230,"content":1236,"config":1242,"_id":1244,"_type":14,"title":1245,"_source":16,"_file":1246,"_stem":1247,"_extension":19},"/en-us/blog/the-top-skills-you-need-to-get-your-devops-dream-job",{"title":1231,"description":1232,"ogTitle":1231,"ogDescription":1232,"noIndex":6,"ogImage":1233,"ogUrl":1234,"ogSiteName":686,"ogType":687,"canonicalUrls":1234,"schema":1235},"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":1231,"description":1232,"authors":1237,"heroImage":1233,"date":1239,"body":1240,"category":695,"tags":1241},[1238],"Sharon Gaudin","2021-11-17","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) 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/secure-rust-development-with-gitlab/), 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",[1087,719,9],{"slug":1243,"featured":6,"template":699},"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":1249,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1250,"content":1255,"config":1260,"_id":1262,"_type":14,"title":1263,"_source":16,"_file":1264,"_stem":1265,"_extension":19},"/en-us/blog/the-top-software-developer-challenges-in-2022",{"title":1251,"description":1252,"ogTitle":1251,"ogDescription":1252,"noIndex":6,"ogImage":684,"ogUrl":1253,"ogSiteName":686,"ogType":687,"canonicalUrls":1253,"schema":1254},"The top software developer challenges in 2022","From AI to hiring, security breaches and Covid, our 2022 Global DevSecOps Survey uncovered the top software developer challenges.","https://about.gitlab.com/blog/the-top-software-developer-challenges-in-2022","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The top software developer challenges in 2022\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-10-05\",\n      }",{"title":1251,"description":1252,"authors":1256,"heroImage":684,"date":1257,"body":1258,"category":761,"tags":1259},[779],"2022-10-05","\nIn our 2022 Global DevSecOps Survey we asked developers about the most difficult parts of their jobs, a question that’s been answered in previous years with comments about tricky toolchain integrations, complex programming languages and business-side folks who \"just don’t get it.”\n\nBut apparently this year *we* didn’t get it: [More than 5,000 respondents](/developer-survey/) told us they were worried about the inability to hire and retain talent, the economy and the post-Covid world they’re expected to work in. They are also concerned about adoption of complex technologies such as artificial intelligence, 5G and edge computing, and the fear of/responsibility for security breaches and what that would mean to their organizations.\n\n(That sound you hear in the background is the shattering of the “devs are oblivious to business” stereotype.)\n\nObviously a tectonic shift in the developer role is underway.\n\n“Two massive waves are crashing against each other right now,” explains [Brendan O’Leary](/company/team/#brendan), staff developer evangelist at GitLab. “One wave is developers as kingmakers. We were ‘brought into the palace’ because every company needed to have software as its core competency and the pendulum swung toward developers. But the other wave is the massive correction in the market. These two things happening at the same time are putting a huge squeeze on businesses and developers.”\n\nA [longstanding shortage of software developers](https://www.forbes.com/sites/forbestechcouncil/2021/06/08/is-there-a-developer-shortage-yes-but-the-problem-is-more-complicated-than-it-looks/?sh=215d08f33b8e) has been made worse by macroeconomic conditions, but demand for software isn’t decreasing despite the market upheaval, O'Leary adds. The result is devs at the center of nearly all the most difficult challenges today, from [hiring](/blog/6-tips-to-make-software-developer-hiring-easier/) to [security breaches](/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment/) and new technologies. \n\nTo put it another way: “We can’t be flippant about any part of the job anymore,” he adds.\n\nHere’s a look at what is keeping developers up at night.\n\n### Security\n\nMore than 1,000 respondents said all of the issues around security make their jobs infinitely more difficult and complicated.\n\n- “(The hardest thing is to) keep it secure and keep it updated.”\n- “My challenge is keeping up with the latest tools and security for optimal performance and privacy.”\t\t\t\n- “I am trying to build applications that are secure and stable.”\n- “Cybersecurity attacks are the biggest challenge facing us today.”\n- “The hardest part of my job? Data security, data security, I repeat, data security.”\n\n### “The Covid effect”\n\nHundreds of survey takers pointed to the changes brought about by Covid, including remote/hybrid work, economic forces, \"The Great Resignation,” and a number of other things. One respondent called it “the Covid effect” and many stressed that this new way of working has made their fast-paced jobs harder.\n\n### Staffing\n\nHard to hire, hard to keep, hard to even find...that’s what survey takers said about the issue of staffing.\n\n- “The biggest challenge is finding sufficient coding staff.”\n- “The biggest challenge is to find people to fill the jobs.”\n- “We have experienced significant difficulty in finding and retaining qualified staff.”\n\n### New technologies\n\nWith all the other pressures on developers, even exciting new technologies can seem daunting. One respondent put it this way:\n\n_“4G, 5G, AI, Metaverse, virtual space - developers have to support all of this.”_\n\nMany, many others simply said: “Technology is rapidly changing.”\n\n## Bold new challenges\n\nThis is all a long way of saying there has perhaps never been more on developers’ plates. Two developer respondents summed it up well:\n\n_“We have a development capacity challenge, a recruiting challenge and a knowledge-sharing challenge.”_\n\n_“For me, these are the eight biggest challenges we are facing as software developers: 1) Keeping pace with innovation. 2) Cultural change. 3) Customer experience. 4) Data privacy. 5) Cybersecurity. 6) AI and automation. 7) Data literacy. 8) Cross-platform functionality.”_\n\nWhat do you see as the biggest challenges facing developers? Let us know in the comments field below.\n",[9,719,269],{"slug":1261,"featured":6,"template":699},"the-top-software-developer-challenges-in-2022","content:en-us:blog:the-top-software-developer-challenges-in-2022.yml","The Top Software Developer Challenges In 2022","en-us/blog/the-top-software-developer-challenges-in-2022.yml","en-us/blog/the-top-software-developer-challenges-in-2022",{"_path":1267,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1268,"content":1274,"config":1279,"_id":1281,"_type":14,"title":1282,"_source":16,"_file":1283,"_stem":1284,"_extension":19},"/en-us/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer",{"title":1269,"description":1270,"ogTitle":1269,"ogDescription":1270,"noIndex":6,"ogImage":1271,"ogUrl":1272,"ogSiteName":686,"ogType":687,"canonicalUrls":1272,"schema":1273},"Ditch toolchain problems with a DevOps platform","Migrating to a platform is the next step in the DevOps evolution.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667978/Blog/Hero%20Images/go-tools-and-gitlab.jpg","https://about.gitlab.com/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ditch toolchain problems with a DevOps platform\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2022-08-24\",\n      }",{"title":1269,"description":1270,"authors":1275,"heroImage":1271,"date":1276,"body":1277,"category":761,"tags":1278},[1238],"2022-08-24","\n\nBy adopting DevOps tools without an end-to-end platform, teams have been adding complexity, mounting costs, and headaches to their job. [Migrating to a true Devops platform](https://page.gitlab.com/migrate-to-devops-guide.html) is the way to get out from under all of that and gain control of projects, break down silos, and cultivate collaboration.\n\nCompanies are increasingly turning to DevOps to create software more efficiently and securely. However, not all of them have adopted a [single DevOps platform](/blog/welcome-to-the-devops-platform-era/), instead opting to cobble together a myriad of tools to handle everything in the software development lifecycle – from planning to delivery. Of course, DevOps tools are helpful, but there can be too much of a good thing.\n\nThis do-it-yourself, or DIY, effort creates a mish-mash of tools that force team members to continuously jump back and forth between multiple interfaces, passwords, and ways of working. It also creates a chaotic environment that needs to be endlessly updated and held together with digital duct tape. And by using a plethora of disparate tools, no one gets an overall view of the projects they’re working on.\n\nGoing DIY isn’t just affecting software development and deployment. It’s also weighing down the business that relies on those products.\n\nThe [problem solver here is the end-to-end platform](/blog/the-devops-platform-for-agile-business/). It’s the next step in DevOps, changing the way people work in a fundamental way.\n\nMigrating from a seat-of-your-pants, DIY system to a simpler, more powerful, single application brings a lot of benefits. Using an end-to-end platform eliminates the time-consuming and costly tangle of tools, breaks down silos, [builds security into every step](/blog/one-devops-platform-can-help-you-achieve-devsecops/) of the development process, and speeds strategic visions into actual working software. The platform enables tech teams to increase efficiency by focusing on delivering software, instead of updating, patching, and stitching together toolchains. \n\n## Eliminating the DevOps tax\n\nMigrating from a complex toolchain to a platform also will eliminate the DevOps tax. \n\nThat refers to the cost that organizations incur when they employ multiple tools and/or multiple toolchains instead of a single, continuous platform. Think about how much time workers spend stitching together and maintaining a toolchain rather than focusing on planning, developing, and deploying software.\n\nHow much are organizations wasting on the dreaded DevOps tax? Too much: our [2022 Global DevSecOps Survey](/developer-survey/) found nearly 40% of devs are spending between one-quarter and one-half of their time integrating and maintaining toolchains, while another 33% spend half to **all** of their time dealing with this issue. Thus it's no surprise that 69% of respondents want to consolidate their toolchains.\n\nA return on investment, or ROI, should come quickly for companies migrating to a DevOps platform, since they will be saving the money that would have been spent watering and feeding a large, complicated tangle of tools. \n\n##  Fostering collaboration\n\nAnother value add to using a DevOps platform is that it will [foster collaboration](/blog/5-ways-collaboration-boosts-productivity-and-your-career/) and shared responsibility. Team members will no longer be working in isolated silos, focused only on their own project – or even just a piece of a project. A DevOps platform enables communication and information sharing. It also adds transparency by giving everyone with a stake in the project a clear view of the progress being made and any challenges being encountered. It also allows for people to make suggestions to share ideas or help clear away obstacles. \n\nA [DevOps platform](/solutions/devops-platform/) will streamline every aspect of the software development lifecycle — from planning to development, testing, deployment, and monitoring. Check out the [Migrating to a DevOps platform playbook](https://page.gitlab.com/migrate-to-devops-guide.html) for more information on replacing your DIY DevOps toolchain with an end-to-end platform.\n",[719,9,741],{"slug":1280,"featured":6,"template":699},"too-many-toolchains-a-devops-platform-migration-is-the-answer","content:en-us:blog:too-many-toolchains-a-devops-platform-migration-is-the-answer.yml","Too Many Toolchains A Devops Platform Migration Is The Answer","en-us/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer.yml","en-us/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer",{"_path":1286,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1287,"content":1293,"config":1298,"_id":1300,"_type":14,"title":1301,"_source":16,"_file":1302,"_stem":1303,"_extension":19},"/en-us/blog/top-10-ways-machine-learning-may-help-devops",{"title":1288,"description":1289,"ogTitle":1288,"ogDescription":1289,"noIndex":6,"ogImage":1290,"ogUrl":1291,"ogSiteName":686,"ogType":687,"canonicalUrls":1291,"schema":1292},"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":1288,"description":1289,"authors":1294,"heroImage":1290,"date":1295,"body":1296,"category":695,"tags":1297},[1122],"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._",[719,825,9,925],{"slug":1299,"featured":6,"template":699},"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":1305,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1306,"content":1312,"config":1320,"_id":1322,"_type":14,"title":1323,"_source":16,"_file":1324,"_stem":1325,"_extension":19},"/en-us/blog/top-five-takeaways-from-the-developer-survey",{"title":1307,"description":1308,"ogTitle":1307,"ogDescription":1308,"noIndex":6,"ogImage":1309,"ogUrl":1310,"ogSiteName":686,"ogType":687,"canonicalUrls":1310,"schema":1311},"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":1307,"description":1308,"authors":1313,"heroImage":1309,"date":1315,"body":1316,"category":695,"tags":1317},[1314],"Aricka Flowers","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",[719,9,1318,1319,783],"webcast","workflow",{"slug":1321,"featured":6,"template":699},"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":1327,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1328,"content":1334,"config":1340,"_id":1342,"_type":14,"title":1343,"_source":16,"_file":1344,"_stem":1345,"_extension":19},"/en-us/blog/top-reasons-for-software-release-delays",{"title":1329,"description":1330,"ogTitle":1329,"ogDescription":1330,"noIndex":6,"ogImage":1331,"ogUrl":1332,"ogSiteName":686,"ogType":687,"canonicalUrls":1332,"schema":1333},"Top reasons for software release delays","In our 2022 Global DevSecOps survey, DevOps pros shared their frustrations with software releases, including security's shift left and complicated code reviews.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664070/Blog/Hero%20Images/cloudwatch-gitlab-incident-management-bg.jpg","https://about.gitlab.com/blog/top-reasons-for-software-release-delays","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top reasons for software release delays\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-08-30\",\n      }",{"title":1329,"description":1330,"authors":1335,"heroImage":1331,"date":1336,"body":1337,"category":761,"tags":1338},[779],"2022-08-30","\n_What’s the most likely reason for a software release delay?_\n\nFrom 2019 through 2021, respondents to our Global DevSecOps Surveys _always_ blamed software testing. This year, however, was dramatically different.\n\nMore than 5,000 DevOps practitioners took our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/), and, for the first time, they offered five equally valid reasons why releases might be tardy: code development, code review, security analysis, test data management, and, of course, testing.\n\nProcesses and priorities are clearly changing in DevOps teams today, and they’re affecting release delays. Here’s how to understand the forces at work.\n\n> Join us at [GitLab Commit 2022](/events/commit/) and connect with the ideas, technologies, and people that are driving DevOps and digital transformation.\n\n## Code development and code review\n\nOver the past three years, code development and code review were the second- and third-ranked culprits for release delays. That’s to be expected: No one ever said code development was easy and code reviews have always been problematic.\n\nDevelopers report [a myriad of challenges with code review](/blog/the-code-review-struggle-is-real-heres-what-you-need-to-know/): It’s too labor intensive, no one is available to do it, and the culture often doesn’t support the process. But in this year’s survey, 76% of developers said they find code reviews “very” or “somewhat” valuable, and a majority said code review was one of the key steps in DevOps they wish they could do more of. All told, 27% of developers review code weekly while another 21% review it daily or with every commit.\n\nClearly, code review is important but [it takes work](/blog/tips-for-better-code-review/) to make them happen more efficiently. One up-and-coming solution that could help make code reviews easier is artificial intelligence. Our survey found 31% of DevOps teams use AI for code review today, more than double the percentage in 2021. GitLab is also excited about the possibilities found in AI’s close cousin machine learning – we’re using it to [improve the code review process](/blog/the-road-to-smarter-code-reviewer-recommendations/).\n\n## Keeping software secure\n\nCreating safe code requires security testing and the frustration around this step is both real and longstanding. Security has nearly always [been seen as a “blocker”](/blog/developer-security-divide/) when it comes to software development in general and software releases in particular. In our 2022 survey, though, priorities have changed. Security is now the top area DevOps teams plan to invest in this year, and a majority of developers report that the most difficult part of their job is keeping software secure. Here’s just a sample of what developers had to say about the challenges of their roles today:\n\n_We are trying to keep up with the latest tools and security for optimal performance and privacy._\n\n_We are trying to build applications that are secure and stable._\n\n_It is challenging to keep it secure and keep it updated._\n\n_Cyber security attacks are the biggest challenge facing us today._\n\n_Data security, data security, I repeat, data security._\n\nThe focus on security isn’t just talk, either. More than 50% of DevOps teams are running SAST, DAST, and container scans, all dramatic increases from 2021. But at the same time, this is the fourth year security pros have continued to blame developers for finding too few bugs too late in the process. Security is a developer performance metric for many teams, but sec team members say it is still very hard to get devs to actually fix bugs, a trend we’ve seen reflected over and over.\n\nIn other words, it’s complicated enough to make the potential of delays unsurprising.\n\n## Managing the test data\n\nToo much test data is one of those good and bad problems to have: 47% of DevOps teams we surveyed report full test automation, nearly double the percentage from last year, and more security scans are being run too. More than half of survey takers (53%) are testing their code as it’s being written, up 21% from last year.\n\nAll those tests result in a data management problem most teams aren’t actually set up to handle. Here’s one example: Less than one-third of teams are able to put DAST and SAST results into a developer’s workflow/IDE and those percentages remain stubbornly low year after year.\n\nTesting momentum and automation are growing by leaps and bounds, but teams now need better ways to evaluate, communicate, and act on the data.\n\n## The tricky nature of software testing\n\nSoftware testing has often worn the “DevOps scapegoat” mantle, and perhaps for good reason. Getting testing just right is critical, but it’s also elusive. There are so many kinds of tests teams can run, test automation requires a big process and culture investment, and test results are often seen as “flaky,” “noisy,” and “late” by busy developers not enthused about context switching or inaccurate results.\n\nBut there are a couple of promising signs: As we saw in 2021, developer respondents told us again this year that testing is high on their list of tasks they would like to do more of. And artificial intelligence is also making inroads: About 37% of teams are using AI/ML to test their code (a 23-point jump from 2021) and 20% more are planning to add it to their DevOps practice this year.\n\nWant to understand more about software release delays and DevOps best practices? Read our [2022 Global DevSecOps Survey](/developer-survey/).\n",[9,825,1339,719],"releases",{"slug":1341,"featured":6,"template":699},"top-reasons-for-software-release-delays","content:en-us:blog:top-reasons-for-software-release-delays.yml","Top Reasons For Software Release Delays","en-us/blog/top-reasons-for-software-release-delays.yml","en-us/blog/top-reasons-for-software-release-delays",{"_path":1347,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1348,"content":1353,"config":1359,"_id":1361,"_type":14,"title":1362,"_source":16,"_file":1363,"_stem":1364,"_extension":19},"/en-us/blog/want-faster-releases-your-answer-lies-in-automated-software-testing",{"title":1349,"description":1350,"ogTitle":1349,"ogDescription":1350,"noIndex":6,"ogImage":1058,"ogUrl":1351,"ogSiteName":686,"ogType":687,"canonicalUrls":1351,"schema":1352},"Want faster releases? Your answer lies in automated software testing","The trouble with testing? Nearly everything! Here's why automated software testing is so hard to get right, and how a DevOps platform can help.","https://about.gitlab.com/blog/want-faster-releases-your-answer-lies-in-automated-software-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want faster releases? Your answer lies in automated software testing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2021-09-30\",\n      }",{"title":1349,"description":1350,"authors":1354,"heroImage":1058,"date":1355,"body":1356,"category":761,"tags":1357},[779],"2021-09-30","\n\nFor three years in a row, our Global DevSecOps Survey found testing was the number one reason (by large margins) for release delays. A lack of automated software testing, combined with too many manual tests conducted too late in the process, was a story told time after time, and it certainly was one without any kind of happy ending.\n\nDespite the undeniable progress DevOps has brought to software development, integrating automated software testing into the lifecycle has remained an elusive goal for many teams. Here’s a look at why testing is such a difficult step to get right, and how an integrated DevOps Platform can bring much-needed structure to the process.\n\n## The state of automated software testing\n\nAccording to our [2021 Survey](/developer-survey/), it’s safe to say respondents are _frustrated_ with software testing.\n\n_“Testing can be slow in both writing and running.”_\n\n_“Testing delays everything.”_\n\nWhile there is forward momentum (almost 25% of teams say they’re fully automated - more than double the number from 2020), the same percentage reported zero automation or that they’re just beginning to think about it. \n\n_“Automated testing is ignored ‘due to time constraints.’”_\n\nBut even teams that haven’t ignored automated software testing are hamstrung because the vast majority don’t give developers scan results **within their IDEs.** Fewer than 25% of teams enable [SAST](/blog/developer-intro-sast-dast/) lite scanners in a web IDE and only 20% put results in a web pipeline report for developers. The situation is even worse when it comes to DAST, dependency and container scans: just 16% make DAST/dependency scan data available, and 14% do the same for container scans. While the percentage of teams reporting full automated software testing increased from 2020 to 2021, the percentage giving devs access to key test data barely changed in the same time frame.\n\n## Context switching makes everything hard\n\nThe fact that developers can’t easily get access to test results is a huge productivity blocker. “The best time to (fix bugs) 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,” explained [Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab, in a blog post last year talking about [the developer-security divide](/blog/developer-security-divide/). “So that’s basically the same day or same week as when I wrote it.”\n\n**Elevating your DevOps skills? Join us at [Commit at KubeCon](/events/commit/) - Oct. 11!**\n\nSo while not getting results “in the flow” is a huge stumbling block, developers are adamant about the importance of testing. When we asked developer respondents in our 2021 Survey what they wished they could do more of, testing was, by far, the number one response. \n\nWhat’s the solution to this conundrum? More automation, [more AI/ML](/blog/ai-in-software-development/) and a [DevOps platform](/solutions/devops-platform/) to make everything seamlessly interconnected, visible and actionable.\n\nGeo-sharing company Glympse offers an object lesson on [the benefits of a DevOps platform](/customers/glympse/). The company was using approximately 20 tools to get its software out the door, but after moving to GitLab’s DevOps Platform, the process was dramatically streamlined. Deployments have dropped from four hours to  less than 30 minutes, and deployment fatigue, particularly around testing and code reviews, has vanished. \n\n## The struggle is real, but worth it\n\nFor teams who’ve tamed the automated software testing beast, and are humming along in their DevOps practices, the benefits are substantial. Here’s what they told us in our 2021 Survey:\n\n_“We are not relying on developers to have remembered to create and run tests for their code before deploying.”_\n\n_“We automate everything possible, to be able to test our product ‘like in real life’ without any downside. This increases confidence and simplifies tests for everything.”_\n\n_“Integration testing has been a big plus in how confident we are to release automatically and deliver a version. We are now able to deliver any day.”_\n\n_“It helps that devs don't need to keep track of test running; they just need to push and pipeline will check their code before merge to master.”_\n",[1358,719,9],"testing",{"slug":1360,"featured":6,"template":699},"want-faster-releases-your-answer-lies-in-automated-software-testing","content:en-us:blog:want-faster-releases-your-answer-lies-in-automated-software-testing.yml","Want Faster Releases Your Answer Lies In Automated Software Testing","en-us/blog/want-faster-releases-your-answer-lies-in-automated-software-testing.yml","en-us/blog/want-faster-releases-your-answer-lies-in-automated-software-testing",{"_path":1366,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1367,"content":1372,"config":1377,"_id":1379,"_type":14,"title":1380,"_source":16,"_file":1381,"_stem":1382,"_extension":19},"/en-us/blog/what-blocks-faster-code-release",{"title":1368,"description":1369,"ogTitle":1368,"ogDescription":1369,"noIndex":6,"ogImage":817,"ogUrl":1370,"ogSiteName":686,"ogType":687,"canonicalUrls":1370,"schema":1371},"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":1368,"description":1369,"authors":1373,"heroImage":817,"date":1374,"body":1375,"category":695,"tags":1376},[779],"2020-05-29","\nOur [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) 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",[825,9,719],{"slug":1378,"featured":6,"template":699},"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":1384,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1385,"content":1391,"config":1395,"_id":1397,"_type":14,"title":1398,"_source":16,"_file":1399,"_stem":1400,"_extension":19},"/en-us/blog/what-you-need-to-know-about-devops-audits",{"title":1386,"description":1387,"ogTitle":1386,"ogDescription":1387,"noIndex":6,"ogImage":1388,"ogUrl":1389,"ogSiteName":686,"ogType":687,"canonicalUrls":1389,"schema":1390},"What you need to know about DevOps audits","DevOps’s many steps can streamline the audit process. Here’s how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668339/Blog/Hero%20Images/a-tale-of-two-editors.jpg","https://about.gitlab.com/blog/what-you-need-to-know-about-devops-audits","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What you need to know about DevOps audits\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-08-31\",\n      }",{"title":1386,"description":1387,"authors":1392,"heroImage":1388,"date":1183,"body":1393,"category":761,"tags":1394},[779],"\nWhile presumably no one likes an audit, DevOps teams do have some built-in advantages when it comes to intense levels of internal and external scrutiny. Here’s a quick look at DevOps audits, why they matter, and how teams can set themselves up for audit success.\n\n## Looking under the hood\n\nIn most organizations, there are two types of audits: internal and external. At their most simplistic, internal audits are conducted by people within the existing organization, while external audits are conducted by third parties. Either way, audits look to ensure an organization is compliant, and that’s where things can get a bit complicated.\n\nBeing “compliant” can mean an organization is meeting standards set by the government (like [NIST frameworks](/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/) or HIPAA regulations), living up to its own governance rules regarding data, security policies and processes, and more, or it can mean some combination of the two. Also, depending on the type of organization and its vertical industry, compliance can have wildly different requirements.\n\nIn the end, it comes down to [being compliant](/blog/the-importance-of-compliance-in-devops/) means keeping track of any data and processes that can prove compliance is happening, and that’s what auditors need to be able to easily access.\n\nObviously, it’s a big job. Way back when, external auditors would literally set up shop in an empty office and spend weeks (or months) sifting through written records, interviewing employees, and even walking the factory floor if necessary. Today, technology, especially automation, have made audits easier to prepare for and carry out, but the plethora of standards bodies and [a growing focus on security risks](/blog/the-ultimate-guide-to-software-supply-chain-security/) mean more time spent auditing than ever before.\n\n## Enter DevOps\n\nThe largely seamless nature of DevOps not only makes it easier to get software out the door more quickly but it also streamlines the audit process. Why? Because automation tracks every step that happens, creating an auditable record, and the “continuous” nature of DevOps also naturally supports the idea of “continuous” or more frequent (and thus easier) audits.\n\n“DevOps is all about building: writing code, building code, testing code, and compiling it,” says [Sam White](/company/team/#sam.white), GitLab’s principal product manager, Protect. “And it's about getting that code built into a deliverable that's actually shipped out to the end user and runs in production. Compliance [in this sense] is all about what regulatory controls and processes have to be followed within the context of writing, building, and shipping software.”\n\n## Audits and DevOps\n\nDevOps processes naturally lend themselves to audits, White explains, because each of the steps can be traced and many, like merge requests, require signoffs. “Compliance regulations can vary across industries and geography. But, generally, what I hear from compliance teams is they need to make sure all of their commits are signed. You want to make sure you don't have a malicious actor putting in bad code. So finding the commits helps you verify who the person was who wrote the code,” he says.\n\nCode review is another obviously “auditable” step in the process, he says, because “it’s very common for organizations to require at least two people to review any code before it gets merged in.” Auditors want to follow the path and DevOps makes it simpler to look at the flow of commits/MRs and code reviews to make sure nothing untoward has happened.\n\n## Track everything\n\nWhile DevOps audit checklists [do exist](https://itrevolution.com/devops-audit-defense-toolkit/), industry compliance requirements vary so widely that a generic list is really only a starting point. But there are basic steps DevOps teams should follow:\n\n- Ensure all code commits have signoffs.\n- Review code on a regular cadence and require at least two signatures.\n- Logging tools are critical – are they widely used and is the data easy to access?\n- Make sure everyone on the team understands the concept of compliance as it relates to a particular industry.\n- Acknowledge that developers aren’t auditors 😀.\n- Check in on operations pros, who are increasingly being tasked with compliance but also report [suffering from information overload](/developer-survey/).\n\nLearn about GitLab’s vision for [compliance management](/direction/govern/compliance/compliance-management/).\n\n_Lauren Minning contributed to this blog post._\n",[719,9,741],{"slug":1396,"featured":6,"template":699},"what-you-need-to-know-about-devops-audits","content:en-us:blog:what-you-need-to-know-about-devops-audits.yml","What You Need To Know About Devops Audits","en-us/blog/what-you-need-to-know-about-devops-audits.yml","en-us/blog/what-you-need-to-know-about-devops-audits",{"_path":1402,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1403,"content":1409,"config":1414,"_id":1416,"_type":14,"title":1417,"_source":16,"_file":1418,"_stem":1419,"_extension":19},"/en-us/blog/why-ai-in-devops-is-here-to-stay",{"title":1404,"description":1405,"ogTitle":1404,"ogDescription":1405,"noIndex":6,"ogImage":1406,"ogUrl":1407,"ogSiteName":686,"ogType":687,"canonicalUrls":1407,"schema":1408},"Why AI in DevOps is here to stay","Two years ago artificial intelligence wasn't part of mainstream software development. Now AI in DevOps is seemingly everywhere. Here's why.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664015/Blog/Hero%20Images/laptop.jpg","https://about.gitlab.com/blog/why-ai-in-devops-is-here-to-stay","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why AI in DevOps is here to stay\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-09-15\",\n      }",{"title":1404,"description":1405,"authors":1410,"heroImage":1406,"date":1411,"body":1412,"category":761,"tags":1413},[779],"2022-09-15","\nIn 2020, respondents to our annual Global DevSecOps Survey started mentioning artificial intelligence and machine learning for the first time. In that survey, roughly 16% of respondents were using “bots” to test code, or were planning to, while 12% of devs said knowledge of AI/ML would be critical to their future.\n\nFast forward just two years and [AI in DevOps](/topics/devops/the-role-of-ai-in-devops/) is a reality in teams around the world, according to our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/).\n\n- 24% of respondents said their DevOps practices include AI/ML, more than double the 2021 percentage.\n\n- 31% of teams are using AI/ML for code review, 16 points higher than last year.\n\n- Today 37% of teams use AI/ML in software testing (up from 25% in 2021), and 20% plan to introduce it this year. Another 19% plan to roll out AI/ML-powered testing in the next two to three years.\n\n- Fully 62% of survey takers are practicing ModelOps.\n\n- 51% use AI/ML to check (not test) code.\n\nAll told, only 5% of teams said they had _no plans_ to incorporate AI in DevOps.\n\nHere's a snapshot of where AI in DevOps is today and why, despite some challenges, AI will likely play an increasingly important role.\n\n## Why AI in DevOps\n\nIn many ways, [DevOps and AI/ML](/blog/ai-in-software-development/) are the perfect marriage: DevOps requires automation to reach maximum efficiency and AI/ML are obvious choices to tackle repetitive tasks. Imagine adding team members entirely focused on a single job, with incredible attention to detail and no need for vacations or even a coffee break – that’s an ML “bot” in a nutshell.\n\nWhen we asked DevOps teams what the most common reasons were for [software release delays](/blog/top-reasons-for-software-release-delays/), the answers called out steps that are critical but manual, tedious, time-consuming, and potentially rife with errors: [software testing](/blog/the-gitlab-guide-to-modern-software-testing/), code review, security testing and code development. For many teams, AI/ML could be key in streamlining these processes.\n\n## Smarter software testing\n\nNo DevOps process is perhaps in more need of streamlining than software testing, which is no doubt why teams have been adding AI/ML into the mix for several years now. Testing is that process [everyone loves to hate](/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook/), but it is also the step that needs to happen more often in all the ways, or at least that’s what developers tell us year after year. But there are so many different kinds of tests, limited development time, and even more constrained QA teams. Machine learning bots can help bridge the manpower gap, freeing up resources to focus on tests best done by humans.\n\nAnd increased testing creates another issue – test data management – that could ideally be triaged and dealt with using AI.\n\n## The benefits of ModelOps\n\nAI/ML solutions have also made their way into other DevOps steps, specifically [ModelOps](/direction/modelops/). Not only is this an area GitLab is focusing on ([beginning with smarter code reviews](/blog/the-road-to-smarter-code-reviewer-recommendations/)), but more than half of DevOps teams report they’re exploring what’s involved in bringing data science and operations together.\n\n## Beware the learning curve\n\nArtificial intelligence and machine learning are not without their challenges, however. In our 2022 survey, developers expressed very real concerns about the steep learning curves involved in the technology adoption. “Technology is rapidly changing,” was a thought shared by many developers, alongside “implementing AI is an enormous challenge.”\n\nOne developer summed it up: “4G, 5G, AI, Metaverse, virtual space - developers have to support all of this.”\n\nBrendan O'Leary, [staff developer evangelist at GitLab](/company/team/#brendan), says AI naturally has a big learning curve because it requires experimentation. \"This is not just a programming language,\" he explains. \"We've got some data and a hypothesis around it and AI is what's going to help us prove it. This is a different kind of experiment than other kinds of coding... we've got to learn how to measure the impact, understand it, and iterate on it. It's a different kind of paradigm.\"\n",[719,9,233],{"slug":1415,"featured":6,"template":699},"why-ai-in-devops-is-here-to-stay","content:en-us:blog:why-ai-in-devops-is-here-to-stay.yml","Why Ai In Devops Is Here To Stay","en-us/blog/why-ai-in-devops-is-here-to-stay.yml","en-us/blog/why-ai-in-devops-is-here-to-stay",{"_path":1421,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1422,"content":1427,"config":1432,"_id":1434,"_type":14,"title":1435,"_source":16,"_file":1436,"_stem":1437,"_extension":19},"/en-us/blog/why-devops-collaboration-continues-to-be-important",{"title":1423,"description":1424,"ogTitle":1423,"ogDescription":1424,"noIndex":6,"ogImage":1058,"ogUrl":1425,"ogSiteName":686,"ogType":687,"canonicalUrls":1425,"schema":1426},"Why DevOps collaboration continues to be important","Modern DevOps isn't just about tech adoption and new processes. DevOps collaboration is going to play a key role. Here's why.","https://about.gitlab.com/blog/why-devops-collaboration-continues-to-be-important","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why DevOps collaboration continues to be important\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":1423,"description":1424,"authors":1428,"heroImage":1058,"date":1429,"body":1430,"category":761,"tags":1431},[779],"2022-10-25","\nIt’s tempting to think the concept of DevOps collaboration is something no one needs to talk about anymore. After all, the methodology has been around for nearly 15 years, is in widespread use, and has clearly proven to be successful at getting safer software out the door faster. Haven’t we figured out DevOps collaboration by now?\n\nThe answer is no, at least according to our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) and to industry experts looking at the future of DevOps.\n\nFor starters, dev and ops respondents to our survey told us programming languages and soft skills like collaboration are going to be most important for their careers going forward. DevOps collaboration was the second most important skill for sec pros surveyed. These results were far from a one-off: In our [2020 survey](/images/developer-survey/gitlab-devsecops-2021-survey-results.pdf), dev, sec, and ops were unanimous that “soft skills,” including DevOps collaboration, were the most critical for future careers. In [2021](/images/developer-survey/gitlab-devsecops-2021-survey-results.pdf), sec and ops continued to prioritize DevOps collaboration for the future, while devs opted for AI/ML.\n\nThis year, we asked over 5,000 survey takers what would be most important to their careers, but we didn’t ask *why* it would be so important. A look at some recent thought leadership around DevOps collaboration sheds some light.\n\nAccording to [an article in SDX Central](https://www.sdxcentral.com/articles/analysis/devops-its-about-the-people/2022/07/), pundits think collaboration is “critical for DevOps success” today and in the future. An [article in Tech Beacon](https://techbeacon.com/app-dev-testing/future-devops) goes further, suggesting DevOps will embrace business metrics as a measure of success going forward, and, as such, will require levels of cross-functional collaboration not seen before.\n\nIn other words, as DevOps expands beyond a technology goal (develop software) to a business goal (ensure customer satisfaction or business profitability), more teams will be seated at the table. The more people involved, the more DevOps collaboration will be critical to the future.\n\nWe’d like to know how DevOps collaboration works on _your_ team. Our 12-question survey will take you less than four minutes! [Take the survey!](/blog/take-our-survey-on-collaborative-software-development/)\n",[719,9,783],{"slug":1433,"featured":6,"template":699},"why-devops-collaboration-continues-to-be-important","content:en-us:blog:why-devops-collaboration-continues-to-be-important.yml","Why Devops Collaboration Continues To Be Important","en-us/blog/why-devops-collaboration-continues-to-be-important.yml","en-us/blog/why-devops-collaboration-continues-to-be-important",{"_path":1439,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1440,"content":1446,"config":1452,"_id":1454,"_type":14,"title":1455,"_source":16,"_file":1456,"_stem":1457,"_extension":19},"/en-us/blog/why-security-champions",{"title":1441,"description":1442,"ogTitle":1441,"ogDescription":1442,"noIndex":6,"ogImage":1443,"ogUrl":1444,"ogSiteName":686,"ogType":687,"canonicalUrls":1444,"schema":1445},"Why you need a security champions program","Faster releases, more open source code, and developers unlikely to have formal security training = at risk software apps. The solution? A security champions program.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664002/Blog/Hero%20Images/securitychampions.jpg","https://about.gitlab.com/blog/why-security-champions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why you need a security champions program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-10-14\",\n      }",{"title":1441,"description":1442,"authors":1447,"heroImage":1443,"date":1448,"body":1449,"category":741,"tags":1450},[779],"2020-10-14","\nIn a recent survey of security professionals, Forrester Research found 33% of them had suffered a security breach. That’s not great news, but what was even more concerning is that the breaches were actually in the applications themselves, either via software vulnerabilities or web application flaws, explained [Amy DeMartine](https://www.forrester.com/Amy-DeMartine), VP and research director with Forrester. “What we’re seeing here is a nasty trend where applications are actually where malicious attackers...are getting into our sacred data,” Amy said during a presentation at our 2020 [virtual user conference Commit](/events/commit/). “(When it comes to security,) applications are actually getting worse and everything else is getting slightly better. So this is where we really need to tighten up. We really need to make sure that our applications are secure.”\n\nDevelopers and security pros certainly agree that apps need to be more secure, but it’s safe to say that’s where the consensus ends. In [GitLab’s 2020 Global DevSecOps Survey](/developer-survey/) we found plenty of finger-pointing in both directions. Most developers weren’t running enough SAST, DAST, or IAST scans and fewer than 25% of them actually were able to get their results within their IDEs. Security pros said developers found too few bugs too late in the process, and neither side could come to any agreement on the question of security “ownership.”\n\nClearly there’s room for (major) improvement. To “fit the square peg of security into the round hole of DevOps” Amy said the solution was a security champions program, something that will help bridge the wide and pervasive gap between the two sides.\n\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\n## Begin at the beginning\n\nBefore a [DevOps team](/topics/devops/) can think about a security champion, Amy shed some light on the culture clash. Developers are measured on quality and customer feedback, two areas directly impacted by security, so that’s a good place to start, she said. Also developers want to release code more quickly, invest in more automation, and increase the use of open source code because they’re handy building blocks that make it easier to create code more quickly. But while open [source code](/solutions/source-code-management/) is handy, it’s often vulnerable; Forrester found 50% increases in open source code vulnerabilities in 2018 and 2019.\n\n“So we may not be doing the right kind of checks that we should be doing to release these open source components,” Amy said. “And the developers are going to need help with this. They're going to need to understand when not to include a common component, what common component to use? What's safe?”\n\nUnfortunately, devs may literally not know the answers to those questions because they may have had absolutely no professional training in security. Forrester examined the top 40 computer science programs in the US last year and found none of them taught secure coding practices. “So our developers, even the ones coming out of university today, do not know how to write secure code,” she said. “They don't understand that open source may have vulnerabilities, they don't know how to remediate weaknesses like SQL injection or cross-site scripting. And so as security pros, we really need to empathize with developers as they are trying to create good quality code that has great customer feedback, they don't know how to secure it, and that's where we come in.”\n\n## Enter the champion\n\nAmy doesn’t see the American universities changing their curriculum substantially in the near future, nor does she have a lot of faith in one-off “security training classes.” Her take: Developers need to learn about security right in the moment while guided by a champion. “The best way to do this is to stop them once we know they’ve got a security flaw and say, ‘Hey, you’ve got a SQL injection or you’ve got cross-site scripting.’ And hopefully the security tool is able to give them the remediation advice in the form of sample code. It’s all about about ‘How do I learn right in this moment?’”\n\nIn an ideal world, a security champion will be that person who can bridge the gap between development and security, up to and including speaking *both* languages, Amy stressed. “(A security champion)...can translate the fact that security flaws equal quality issues. And they're able to make it real for developers that oftentimes security pros aren't able to make it real for them. Plus they're part of the team, so they're automatically trusted.” Done right, the champion answers the questions in real time and speeds up the learning curve and the delivery cycle.\n\n## Make it happen\n\nTo get that obvious win-win in your organization, start by making the case, getting support, and finding funding, Amy said. “Even in this time of budget cuts it’s important to make sure you highlight the fact that what you’re trying to do is make your developers faster and have less flaws,” she said. Funding should come from both development and security.\n\nAfter that, it’s critical to pick the right security leaders; they’ll train the champions so they need to be empathetic to developers. The right candidates for champions will be those who ask a lot of questions about security, are naturally good at finding flaws, and are inclined to help others, Amy offered. Once they’re in place, the security leaders need to train them on the common issues and how to fix them.\n\nFrom there, it’s a matter of supporting, rewarding, and cheering them on, she stressed. Contests and friendly competitions “can go a long way to keeping developers interested and active as champions,” she said.\n\n## Pay attention to results\n\nThe final step in establishing a security champions program is measuring, monitoring, and continuously improving, Amy said. “If you see a huge uptick in SQL injection, it’s probably time to do some education either with a specific team or across the board.”\n\nIt will take some effort, she said, but it’s how companies are going to scale security successfully. “It’s not just automation (that leads to scale), but it’s also your security champions. (Focus on) those people who are embedded inside the developer teams.”\n\nWatch Amy’s full presentation:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/yX-uEkdpw2w\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Joel Filipe](https://unsplash.com/@joelfilip) on [Unsplash](https://unsplash.com)\n{: .note}\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",[741,1451,9],"security research",{"slug":1453,"featured":6,"template":699},"why-security-champions","content:en-us:blog:why-security-champions.yml","Why Security Champions","en-us/blog/why-security-champions.yml","en-us/blog/why-security-champions",{"_path":1459,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1460,"content":1465,"config":1470,"_id":1472,"_type":14,"title":1473,"_source":16,"_file":1474,"_stem":1475,"_extension":19},"/en-us/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen",{"title":1461,"description":1462,"ogTitle":1461,"ogDescription":1462,"noIndex":6,"ogImage":817,"ogUrl":1463,"ogSiteName":686,"ogType":687,"canonicalUrls":1463,"schema":1464},"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://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":1461,"description":1462,"authors":1466,"heroImage":817,"date":1467,"body":1468,"category":695,"tags":1469},[779],"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",[9,719,269],{"slug":1471,"featured":6,"template":699},"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":1477,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1478,"content":1484,"config":1491,"_id":1493,"_type":14,"title":1494,"_source":16,"_file":1495,"_stem":1496,"_extension":19},"/en-us/blog/2018-global-developer-report",{"title":1479,"description":1480,"ogTitle":1479,"ogDescription":1480,"noIndex":6,"ogImage":1481,"ogUrl":1482,"ogSiteName":686,"ogType":687,"canonicalUrls":1482,"schema":1483},"Global Developer Report - 2018 for Open Source & 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://res.cloudinary.com/about-gitlab-com/image/upload/v1749663993/Blog/Hero%20Images/2018-developer-report-cover.jpg","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":1485,"description":1480,"authors":1486,"heroImage":1481,"date":1487,"body":1488,"category":695,"tags":1489},"Global Developer Report confirms 2018 is the year for open source and DevOps",[692],"2018-03-07","\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) 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",[9,1490,719,1319],"open source",{"slug":1492,"featured":6,"template":699},"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",5,[679,704,726,748,769,790,812,832,852],1758326272482]