First, the good news: do DevOps right and you’ll release code faster. In fact, 83% of our 2020 Global DevSecOps Survey respondents said code heads out the door more quickly thanks to a successful DevOps practice.
But 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.
At 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.
The trouble with testing
Let’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 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.
"We are slow and do not test very well. We do Big Bang deployments."
The 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.
"Not enough tests (or none) and then the code doesn’t work in production. Some collaborators have poor IT skills."
"Too little testing done too late."
"We need more test cases to cover 100% of everything."
Just 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.
There are a few glimmers of hope. For starters, teams that have cracked the test automation code told us about the concrete benefits.
"We do TDD (test driven development). QA and dev act as a team. We have automated tests running parallel with developing code."
And 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.
The truth about planning
Testing 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.
One 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.
"Planning is in the form of some teams doing waterfall and others doing 'wagile.''"
"Planning is somewhat heavyweight and a little less than agile."
For many of our survey takers, there was just overall frustration with the planning process.
"Poor planning leads to a lot of doubling back."
The paradox of code reviews
There 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."
"We have a strict code review process and it often takes several days for the reviewer to respond to requests for review."
"Code review takes time and every developer has to explain how he achieved what he did."
"Code reviews can take a long time due to the lack of reviewers."
Code 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."