Sergey Nivens - Fotolia
Speeding application delivery through continuous software delivery gets updates out faster, but that is no guarantee of a better user experience.
CloudBees Inc., a provider of application delivery technology based on the Jenkins continuous integration and continuous delivery platform, believes delivery, fast or not, means little if the software being delivered isn't improving. The rise of DevOps to move with agility and speed, and the opposing force of application development occurring outside of IT, heighten the need for delivering high-quality software and doing it quickly. Sacha Labourey, CEO of the San Jose, Calif., company, spoke about new developments in application delivery, along with his concerns, in an exclusive interview with SearchCloudApplications.
How are cloud and mobile changing the rules of continuous software delivery?
Sacha Labourey: We are going through interesting times. CloudBees believes in the need to accelerate the development and delivery cycle to achieve a faster velocity. Mobile applications [are] a place where you benefit from DevOps, the discovery process and the fail-fast approach. Cloud is the same thing. It enables the discovery process and the ability to leverage resources for accelerating delivery.
Do you believe DevOps plays a central role?
Labourey: What we see happening in organizations is that many were not pushed to do DevOps or continuous integration. What happened was the need to do mobile and the pressure to do cloud. Companies had to figure out how to do these competitively and simultaneously establish best practices. They discover that they should be doing things differently than in the past. We've had discussions with many development teams and DevOps teams looking for help. The discussion has changed; it's no longer just about how to make the IT engine more efficient, but about how to wrap where the business wants to go into the app development and delivery process. Many businesses are still blind to these changes, but the transformation is underway. It is inevitable.
Sacha LaboureyCEO, CloudBees
You are describing what many are calling BizDevOps, bringing the needs of the business directly into the DevOps initiative and understanding IT's impact on business operations.
Labourey: I don't know if BizDevOps is the right term. The interesting part is when you get the business involved. Up to now, they have been screaming for more, faster, sooner. But, at the same time, you have to realize that when you want to truly involve the business, it requires a change in how the business operates. It's asking much more from the business. Both sides end up needing to change to be more agile. One thing the business has to do is stop providing IT with a list of requirements for the next 24 to 36 months. Cycles are down to weeks, not years.
What is the most common mistake that DevOps teams make with continuous software delivery?
Labourey: Not investing in solving the hard problems is the most common mistake. Even with a new project, you still have hard problems to solve. It's easy to use automation for code building, but one part that is difficult is doing proper testing with proper staging and deployment. To do this in an intelligent fashion requires an investment from the DevOps team. When you don't make that investment in the hard work of testing, what you end up with is a process where you get very efficient at publishing bugs.
Aren't continuous software delivery products like CloudBees simply making it easier to publish bugs faster?
Labourey: Small, frequent updates are good. We talk about faster, but that is not always meaningful. Changing the pace of iteration does not mean that you can suddenly code faster. A better word might be sooner. Let's do a new version sooner, see what works, see what doesn't and then iterate from there.
Sacha LaboureyCEO, CloudBees
How does continuous software delivery mesh with and reflect on the DevOps movement in general?
Labourey: DevOps is on a good path. The original DevOps and Agile people should be proud. It reminds me of the 1990s with open source. These were idealists who did not understand the concept of corporate production. With Linux, and even Microsoft today, it is a victory for open source. The same thing is taking place with development methodologies. We used to have long release cycle -- often years. The Agile guys in early 2000s didn't understand what critical software meant to operating critical apps in production. Today, if you're not doing Agile and DevOps, you're late. Every company has been good at producing business value from software.
What do want developers to know about continuous software delivery that they don't know today?
Labourey: The obvious thing is if you don't have a continuous software delivery process for mobile, you are doing something wrong. It's that simple. When it comes to the cloud, it's better. You have elastic resources, the ability to do smooth software updates and to dispatch workloads. You have sophisticated ways to automate software delivery in the cloud. Not doing it is just plain stupid. A lot of companies go to the cloud thinking it is just like their data centers. But that is completely missing out.
Is Jenkins 2.0 good enough for continuous delivery?
What are the benefits of continuous delivery?
Does continuous delivery equate to continuous improvement?