To paraphrase Kent Beck: software delivers no value apart from runtime. Ideas take physical form in hardware, virtualized 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 math into socially constructive math 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 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.

Here Are the Demographics of This Survey:

• Developers (42%) and Development Leads (25%) were the most common roles.
• 63% of respondents come from large organizations (100 or more employees) and 37% come from small organizations (under 100 employees).
• The majority of respondents are headquartered in Europe (44%) or the US (32%).
• Over half of the respondents (61%) have over 10 years of experience as IT professionals.

We only surveyed developers who use Java in their organization. Other language ecosystems for these organizations include C# (31%), C/C++ (29%), Universal JavaScript (28%), PHP (26%), Python (26%), and Groovy (23%).

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 organization 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%), we found that only 18% 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% smaller from last year's survey, the 18% 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 Is 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% of respondents are currently using containers in their organization, and a majority (56%) are either considering or evaluating container technology. However, of those who are using containers, over half (53%) 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 More Easily Than Others
Of the barriers to adopting Continuous Delivery, three were singled out as the most prominent: lack of a collaborative corporate culture (57%); lack of time to implement Continuous Delivery practices (51%); and lack of relevant skill sets (49%). Some respondents' answers differed largely based on the size of the organization they worked in. As shown in the graph below, on average, corporate culture was cited as a barrier by only 23% of users who worked at startups (less than 10 people). From there, a clear trend is present that indicates that more respondents recognized the lack of a supportive culture as a barrier if they worked at larger companies. On the other hand, results are more normalized 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% and 60%, respectively), and only very small companies (1-4 employees) did not consider the lack of engineering skills to be a significant barrier (39%). 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% more than last year's survey respondents reported (37% compared to 21%). We also discovered that specific DevOps teams could improve collaboration. Of the 32% of respondents who have a DevOps team in their organization, 57% identified that collaboration and breaking down silos was a major focus of that team. When a DevOps-focused team is in place, 41% of development and operations teams deploy code together, compared to 35% when there is no designated DevOps team. This signifies that specialized 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 organization, 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 organizations working to achieve Continuous Delivery were focused on. Of those organizations, 66% have adopted builds broken up into stages, 62% include manual checks to proceed, and 53% include automated checks to proceed. This indicates that organizations 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.

Organizations whose development and operations teams deploy code to production use these processes 15% more than organizations where only development deploys changes, and 15% more than organizations where only operations deploys changes to software. Within collaborative organizations, the two most used processes were visibility available to all stakeholders (53%) and automated feature validation (51%). 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.

For more information about this research and its findings, visit: https://dzone.com/guides/continuous-delivery-3.

• Delivering Software as a Service to Manufacturing Companies (Strategic Focus) is Available Now
• Coleman Research Group Acquires Endowment Capital Group's Clio Research Management Software
• Is DevOps Changing Enterprise IT?