Continuous Delivery = “Slow but steady improvements over time”
Jenkins creator Kohsuke Kawaguchi talks Continuous Delivery, Jenkins and why it makes all the difference being the first-mover in IT.
JAXenter: First of all, can you tell us a little bit about what kind of improvements CloudBees has brought to to Jenkins recently?
Kohsuke Kawaguchi: It’s kind of all over the map, but let me start with Jenkins Workflow. This is a whole new subsystem of Jenkins that expands the domain of Jenkins significantly. Put simply, it lets you describe a complete chain of automation as a script. It can handle parallelism, tasks that involve multiple computers, human approvals and external system interactions very easily. It is an ideal tool to describe your continuous delivery pipeline. I see it as a key enabler for the future of Jenkins.
Then there have been various UI/UX improvements in Jenkins core. We’ve refreshed CSS, made the UI responsive, made icons pluggable and created a mechanism to introduce themes. Doing these while still preserving backward compatibility with plugins has been a major achievement.
Improvements are also happening in places you don’t see. We’ve been steadily removing scalability bottlenecks and concurrency issues that we find from larger deployments that our customers run. As more and more users run Jenkins with elastic build slaves, the part of Jenkins that handles those have received a lot of improvements as well.
In the upcoming Jenkins User Conferences, we’ll be talking about many of those, and what we’d like to do in these areas in the coming days. And there are also some exciting new features that we will be presenting at JUC.
What would you say to CD and Jenkins fans out there working on projects that haven’t yet managed to switch to CD for organisational reasons?
Continuous delivery isn’t a binary thing, and it’s not like a car or a house that you buy and get in one shot. I think of it more as slow but steady improvements over time, or a series of baby steps. As an individual contributor frustrated to the slow pace of change, I think it’d be more productive and satisfying to take on one little problem at a time, by using the spare time here and there. I sometimes feel like that’s the fastest way to have people get the idea. The rabbit and the turtle, if you will.
“Continuous delivery isn’t a binary thing”
I think similar things apply to people who are responsible for driving change in the organization. Take one project initially, meet where they are, and go incrementally. Foster champions in teams, and give them the idea that they should retrospect and they can improve how they do things through automation. Tell yourself that it’s not the end of the world that everyone doesn’t do it the same way.
And the trick is that we can all use injection of ideas – different ways to look at problems, how other people solved similar problems, and looking for things that you can leverage. This is what interacting with the community gives you, and one of the major reasons people come to the Jenkins User Conferences.
What is it about Jenkins that you think has made it so successful in the community?
I think the critical part of it is that it gave people pieces that they can reassemble. It gave people something that they can use immediately and get some benefits, but unlike cars or houses, you can tinker with Jenkins a whole lot more easily and at a far deeper level. So as you get used to it, it’ll really adjust to your team’s unique style, instead of forcing your team into the mold. If you want a new door in a car, you have to buy a new car. But doing the same with Jenkins is just a matter of adding a plugin. In other words, extensibility is the key.
“Perhaps Jenkins was just at the right place at the right time”
It’s also just as probable that I was just lucky. There’s a broad sweeping drive toward more automation in software development, and perhaps Jenkins was just at the right place at the right time. There’s definitely a first-mover advantage in software.
I have heard devs in particular are using Jenkins to manage infrastructure as code – are you seeing much uptake in the community?
Yes, managing infrastructure as code is a major driving force nowadays. When we say “infrastructure as code” you might narrowly think of chef, puppet, etc., but the same idea is getting applied to more things. For example, we use roadworker and it is convergence-based DNS as code. We also use Terraform and that’s cloud server provisioning as code.
I think a part of the reasons for a drive to “X as code” is that it lets us apply the same set of tools, idioms and processes to these domains, in this case the ops domain. One of such tools is Git, because as soon as you do “X as code,” you are putting them under version control, do code reviews, branches, that sort of thing. I think Jenkins is another such tool, because the code has to be compiled, statically analyzed, tested, integrated, etc. It’s Jenkins that drives those processes.
I understand the Jenkins community is growing in Europe. What’s happening and how can people get involved?
I think the community is growing everywhere. It’s just that in Europe I see a big concentration of Jenkins developers, who are active in the community. Maybe a part of it is that companies or people there are more willing to share and openly talk about what they do in and around Jenkins. Years ago, I did a meet-up at Nokia in Copenhagen, and people from Sony Ericsson came over, shared their Jenkins experiences and plugins that they have built. These are competing companies, but people knew each other. Compared to that, I feel like Asian companies and American companies are a little more secretive, and tend to keep stuff to themselves.
It also probably helps that they are geographically closer. For example, when I did meet-ups in Hamburg, people from Berlin and Cologne came. When I did meet-ups in Brussels, people from Sweden came over. Whereas when we do meet-ups in San Francisco, it’s hard for people from Chicago to come by.