Jenkins and continuous delivery: Handing developers more power
Instead of being kept in the dark and well away from business decisions, developers stand to be among the main beneficiaries if the adoption of a continuous-delivery approach to software continues to gather pace.
Continuous delivery is a software-development technique designed to automate and improve quality and ensure code is ready for production more quickly.
Sacha Labourey, CEO and founder at CloudBees, the firm behind leading continuous-delivery tool Jenkins, said a lot of boring and low-value activities will be dropped because they can be automated, which will give developers an important career boost.
"For once, they're able to work closely with business to make sure what they're building is exactly what business wants," Labourey said.
"This dialogue between business and developers is largely going to increase the role that developers have in organisations and make their lives much more interesting."
Continuous delivery not only involves high-frequency iterations to improve the way software works, but also allows real-time checks to measure whether code changes are achieving specific business objectives.
"Developers will have a way to provide feedback themselves to the business. A lot of developers sometimes feel that they are not impacting their company as much as they'd like. They're being asked to do things they might or might not like but they don't necessarily think they can impact the direction and success of the company," Labourey said.
Read this
"With continuous delivery, we're getting to a place where every actor will have a seat at the table, a vote and a way to impact the decisions and success of the company. So it's an exciting time for developers."
CloudBees this week dropped its PaaS operations to focus purely on Jenkins, for which its on-premise products add enterprise functionality. The company is heavily involved in developing Jenkins, with CTO Kohsuke Kawaguchi the founder and community lead for the open-source project.
CloudBees reckons the open-source Jenkins platform leads in continuous delivery, with more than 85,000 active installations worldwide — many of which are being used as a hub for continuous delivery and the DevOps development methodology.
The Jenkins community has developed about 1,000 plugins, enabling the software to integrate with many popular technologies. Active Jenkins installations increased by 160 percent in 2013 and by more than 300 percent in the three years up to the end of last year.
However, shifting to continuous delivery is not just about tools and processes. It also involves significant changes to corporate culture.
"Even those people who'll tell you it's not the case, factually, you perceive that people in business do not think they share the same DNA with the people in development, who don't think they share the same DNA as the people in ops," Labourey said.
"So the first thing to be successful is to make sure those types of individuals are able to collaborate together, find a common language to do things so that trust can be established among those peers and so everybody is going to be important as part of the pipeline that leads to production.
"Sometimes that's just not how companies are wired. Some companies business is king and developers are the slaves who are doing the dirty jobs."
Equally, there are cases where people in engineering think they know better, Labourey said. "They'll do what they think is best, not what the business asked them to do," he said. "You find a lot of that behaviour, and breaking it takes time, takes trust, takes work — it's a long road. But it's totally worth it."
The goal is to move away from traditional patterns of software development, involving little or no interaction between the various protagonists.
"I don't want to simplify things too much, but you clearly see sometimes that business has what they think is the next big idea. They ship it to IT. Developers work on it and 18 months afterwards they ship it back to business and hope it's going to be fine," Labourey said.
"It's also pretty comfortable for the business to take 18 months to make a big plan, ship that to IT and then wait. What we're talking about here is not making big plans — it's fine that they have a vision — but to make short plans and be able in the evening, when they go to bed, to challenge the assumptions they've made in the morning and sit down and discuss with the team why it was wrong and what went fine."
Unfortunately, there are also examples of businesses that think they have moved to continuous delivery in some measure, whereas in reality they have fallen short.
"A lot of companies are still doing what I would call blind continuous delivery, which is kind of DevOps on steroids. Developers and IT are working in a continuous delivery fashion but it's really just a way they happen to build software," he said.
Tech Pro Research
"That's great. That's an amazing step but you're not going to get anywhere close to the value of continuous delivery as long as you do not involve business because it's going to change the way business operates as well, right?
"In too many companies we're talking about a limited form of continuous delivery that's still restricted to IT."
Labourey said he sees DevOps and continuous delivery as fundamentally different. "You can do DevOps without ever doing continuous delivery and you can do continuous delivery without ever doing any DevOps. DevOps is really the way to link the processes between developers and operations and streamline that work, while continuous delivery is another whole process that makes this feedback loop happen in small iterations," he said.
"What we do see, however, for new types of applications, especially as you add cloud to the mix, is DevOps and continuous delivery are done in a congruous manner so DevOps becomes a way that you implement continuous delivery when it comes to dev and ops."
The best place to start with continuous delivery is with a single project with a good team behind it that's willing to try new things, Labourey said.
"Don't take maybe the most strategic product in the company. Then get help from third parties that know how to do continuous delivery. You need to have somebody help you rewire your brain pretty much and that help comes from third parties," he said.
"Once you've been successful with one project, you'll quickly see other parts of the company will want to jump on board as well. So no big-bang approach and get help — that would be my advice.
"Jenkins is a great tool; it's a great way to implement the processes. But here we're talking about changing the way people operate, changing the way the relationships, how the power between people is going to take place."
Read more on software development
- Red Hat Software Collections 1.2 beta: New software for Linux developers
- Microsoft takes its developer outreach beyond the traditional hackathon
- Why APIs are eating the world
- Most popular open-source cloud projects of 2014
- Twitter cultivating mobile developer base with new Flight conference
- Enterprise developers slow to embrace mobile, despite all the hoopla
- Apple to developers: Your apps will scale on iPhone 6, iPhone 6 Plus screens
- Survey finds widespread reliance on non-developer developers