Research: Delivering software continuously

To paraphrase Kent Beck: software delivers no value apart from runtime. Ideas take physical form in hardware, virtualised only part of the way down, and someone other than the developers makes the ideas manifest. So then: ops folks are the crop’s caretakers; developers design the seeds.

Well, of course this isn’t true. Developers don’t turn pie-in-the-sky maths into socially constructive maths that sysadmins then make useful. No: developers write code that makes things happen. We care about runtime just as much as ops, so we need to know how our software is helping people in reality — and how it can do a better job — in order for us to refine both the ideas and the implementation.

So cycle-time shortening — the metric of continuous delivery, and one of the Twelve Principles of Agile Software — is equally about users and makers. Working software delivered sooner is better for users than equally working software delivered later. And informative feedback gleaned more quickly from real-world use is better for developers than equally informative feedback gathered more slowly. Your customers’ problem space measures your software’s value better than your requirements specification ever could. Calibrate against that space as often as you can.

But not all defects appear immediately (sometimes not even for years), and the real-world harm caused by certain defects far outweighs the benefits of quicker delivery. So doing DevOps right involves tradeoffs, risk management, and decisions about the future, all made in uncertainty. And real-world experience in Continuous Delivery matters a lot.

To help deliver this hard-won experience, below I’ve included some of the key research findings from a group of nearly 600 IT professionals that responded to a recent Continuous Delivery Survey. You might be surprised to learn about some of the findings that relate to the modern challenges (iterative roadmapping, security) and solutions (containers, microservices) for DevOps professionals striving for the CD ideal.

The survey demographics

  • Developers (42 per cent) and Development Leads (25 per cent) were the most common roles.
  • 63 per cent of respondents come from large organisations (100 or more employees) and 37 per cent come from small organisations (under 100 employees).
  • The majority of respondents are headquartered in Europe (44 per cent) or the US (32 per cent).
  • Over half of the respondents (61 per cent) have over 10 years of experience as IT professionals.
  • We only surveyed developers who use Java in their organisation. Other language ecosystems for these organisations include C# (31 per cent), C/C++ (29 per cent), Universal JavaScript (28 per cent), PHP (26 per cent), Python (26 per cent), and Groovy (23 per cent).

The textbook definition of Continuous Delivery

Jez Humble and Dave Farley, the authors of the book Continuous Delivery, defined three key traits to determine when an organisation has achieved Continuous Delivery. We asked our audience whether they were confident that code was in a shippable state after changes were made and any tests were completed; whether their teams perform pushbutton or fully automated deployments of code changes to any environment; and if all stakeholders have visibility into the software delivery environment.

Of those who believe they’ve achieved CD for some or all projects (41 per cent), we found that only 18 per cent feel confident in their code’s readiness, can perform deployments of code changes on-demand, and offer visibility into their entire production process. Though the sample of respondents who believed they achieved Continuous Delivery was 9 per cent smaller from last year’s survey, the 18 per cent of respondents who reported having all three of these CD traits was the same percentage as in last year’s survey.

We believe the smaller number in those who believe they have implemented Continuous Delivery for some or all of their projects is a result of the increased knowledge that has been circulating as DevOps becomes a more accepted and understood term in the IT industry.

Containers are hot, but there's a learning curve

Though container technology, like JVM containers, has existed for a long time, technologies like Docker have recently made headlines as an easier way to spin up environments by allowing the kernel of an operating system to host multiple environments.

As far as overall container usage goes, 17 per cent of respondents are currently using containers in their organisation, and a majority (56 per cent) are either considering or evaluating container technology. However, of those who are using containers, over half (53 per cent) still have issues with configuring and setting up environments, even though this is commonly cited as a key benefit of using Docker. As the technology is still new and not yet mature, it seems there is a learning curve to using container technology.

Some companies overcome barriers easier than others

Of the barriers to adopting Continuous Delivery, three were singled out as the most prominent: lack of a collaborative corporate culture (57 per cent); lack of time to implement Continuous Delivery practices (51 per cent); and lack of relevant skill sets (49 per cent). Some respondents’ answers differed largely based on the size of the organisation they worked in.

Corporate culture was cited as a barrier by only 23 per cent of users who worked at startups (less than 10 people). From there, a clear trend is present that indicates that more respondents recognised the lack of a supportive culture as a barrier if they worked at larger companies. On the other hand, results are more normalised for the other two barriers.

However, respondents at companies that were either very small (1-4 employees) or mid-sized (20-99 employees) were more likely to cite lack of time as a major barrier (62 per cent and 60 per cent, respectively), and only very small companies (1-4 employees) did not consider the lack of engineering skills to be a significant barrier (39 per cent). We can reasonably conclude that smaller companies and startups are more likely to have issues related to time when they start implementing Continuous Delivery, if they did not begin life that way, and that as companies grow, a more silo-focused culture grows with it, making DevOps practices more difficult to adopt.

Dev and Ops collaboration is improving

While the lack of a collaborative culture is still a significant barrier for many companies, there has been a greater effort to work between development and operations. This year, both departments deployed code together 16 per cent more than last year’s survey respondents reported (37 per cent compared to 21 per cent). We also discovered that specific DevOps teams could improve collaboration. Of the 32 per cent of respondents who have a DevOps team in their organisation, 57 per cent identified that collaboration and breaking down silos was a major focus of that team.

When a DevOps-focused team is in place, 41 per cent of development and operations teams deploy code together, compared to 35 per cent when there is no designated DevOps team. This signifies that specialised DevOps teams can be effective at driving collaboration between different departments. While company culture can still be a limiting factor when adopting Continuous Delivery, improvements are being made.

What processes impact collaboration

For this year’s survey, we asked our users if their software delivery process included any of the following processes: builds broken up into stages, performance issue detection, security issue detection, usability issue detection, visibility to all stakeholders in the organisation, a thorough audit trail, automatic checks to proceed, manual checks to proceed, automated performance testing, and automated feature validation.

This was to gauge if using these techniques lead to any improvements in DevOps collaboration, and what organisations working to achieve Continuous Delivery were focused on. Of those organisations, 66 per cent have adopted builds broken up into stages, 62 per cent include manual checks to proceed, and 53 per cent include automated checks to proceed. This indicates that organisations moving towards Continuous Delivery are making changes to their pipeline that will make it easier and faster to deploy changes to software in production, while maintaining high quality.

Organisations whose development and operations teams deploy code to production use these processes 15 per cent more than organisations where only development deploys changes, and 15 per cent more than organisations where only operations deploys changes to software. Within collaborative organisations, the two most used processes were visibility available to all stakeholders (53 per cent) and automated feature validation (51 per cent). This indicates that (1) automated testing and validation is gaining significant traction within teams who are trying to collaborate more; and (2) that allowing all stakeholders visibility into the process suggests that when management is more invested in creating a DevOps culture, development and operations are more likely to work together and adopt new technologies.

John Esposito at DZone