kohsuke-kawaguchi_2-2With the slow march towards Continuous Integration (CI) and Continuous Delivery (CD), open source CI  server Jenkins is riding a wave that, for the moment, shows little sign of breaking. On the back of this momentum, former PaaS specialists CloudBees have pivoted to focus their efforts on the technology. Having invested strategically in both CI and CD compatible public and private cloud infrastructure, the company is now on a mission to educate the enterprise on the benefits of aligning around the principles of CI and CD. Of course, it does help help that Jenkins inventor Kohsuke Kawaguchi holds the position of CloudBees resident CTO.

In this interview, we grill Kawaguchi about his favourite Jenkins hacks, and discuss why the world is waking up to the need to automate all of the things. We also talk about what makes Jenkins an intuitive tool for developers, and how the software is evolving.

Voxxed: Jenkins has seen explosive growth in the last couple of years – what are the key factors pushing this?

Kawaguchi: In this world, we are always driven to do more things more efficiently with less resources, faster, and that means we are forced to automate more and more, whether we like it or not. That force of economics has been pushing more and more automation into software development and Jenkins is a platform that helps people do that. So that helped Jenkins. Also, software is eating the world — it is becoming more and more important in every industry, from manufacturing to retail, transportation to agriculture. In the last few years, I’ve been seeing Jenkins hit Main Street, not just technology companies. These are the users that are driving the growth of the installation base.

I also think the extensibility of Jenkins has a particular appeal to developers. The software development scene is incredibly diverse, because different people need to do things slightly differently. The plugin architecture in Jenkins lets it morph itself to any shape and form. Developers by nature like useful building blocks that they can combine and extend. Jenkins is built on that notion of extensibility from the early days.

Where do you see people going wrong with Continuous Delivery?

I’m not sure I see anything going “wrong.” Some people have preferences, for example I know some people who insist on a specific code coverage percentage, and I’m not a big fan of that. The same with coding conventions — I’m not a big fan of draconian rules that control whitespace placements, # of lines in functions, etc.  But those are relatively local confined issues.

Much of the struggle in continuous delivery that I see is around the difficulty of automating things (middleware, mobile, etc), dealing with non-elastic systems, such as databases, and so on. These hurdles just have to be overcome one-by-one, over time. Aside from technology, in any large organization, changing how people work is a slow and difficult process. Cultural change can be the biggest obstacle to adopting continuous delivery. But none of them are “doing things wrong.”

CloudBees recently announced a $23.5m round of funding – congratulations! This was largely thanks to Jenkins CI’s position as the global ‘hub’ for CD. Do you see any other technologies in this space that could emerge as a rival?

I think the main challenge for Jenkins is with itself; for example, we’ve been saying for years that we need to improve the experience for new users, but those things tend to get neglected because we tend to focus on problems that each of us see,  and those who develop Jenkins tend to be beyond that initial ramp-up experience. Similar things can be said about making it easier for people to find plugins and improve testing between different versions of plugins and the Jenkins core. Making these things happen in an open-source project where everyone scratches their own specific itches is tricky.

In a statement, CloudBees announced that they will be launching products to help serve a broader range of customers – can you tell us about this?

Over time, our thinking has evolved, and now we are focusing on two things around Jenkins. One is “above Jenkins”, as in features and functionalities that help users who are using Jenkins. We’ve released a number of features around open-source Jenkins Workflow to help people define continuous delivery pipelines more effectively. We’ve put a feature that lets people use Jenkins as a gate-keeper of a commit before it lands on the version control repositories. We have analytics features that help you analyze the metrics of your CI/CD processes.

The other is “below Jenkins”, as in features and functionalities that help administrators who are running Jenkins. For example, you can connect multiple Jenkins instances and have them work together. You can centrally manage upgrades and plugin installations of many masters.

This spectrum of functionalities are provided as different editions of CloudBees Jenkins Platform, which includes CloudBees Jenkins Enterprise, CloudBees Jenkins Operations Center, and so on.

What have been the biggest changes in the Jenkins world over the past year?

The fundamental structure of Jenkins and its community hasn’t really changed.  It’s still the same Jenkins core and all the plugins. There’s just more of them.

In terms of the functionalities, I think Jenkins Workflow is definitely one of the biggest changes. It’s a single mechanism that can be used to describe everything from the simplest build job to a complicated continuous delivery pipeline. It lets you do it as code, so that you can manage changes, see diffs, and clone and reuse them across different projects. It is a DSL on Groovy, so the rich abstraction mechanisms can be used to create reusable pieces of the pipeline or even higher-level organization-level DSLs where most users will be unaware that they are writing workflow.

Have you seen an increase in use of Jenkins outside its original niche as it has grown?

Jenkins started as a place to run builds and tests, but thanks to the extensibility, it was pretty clear to me that it’s a general automation platform, from the very early days. To that point, when I explain Jenkins to new people, I sometimes explain it as glorified distributed Cron. So it wasn’t a surprise to me that people are using it to do code analysis, release, deployment, and just about any other scripted tasks that belong to the team, not just individuals. We have people using it to run ad-hoc operations scripts, execute batch processing,  generate documentation, and so on.

Jenkins has been also used outside software development, too. For example, book publishing and hardware design have a lot of commonality with software development. In both cases, there’s the source files that people edit, and there’s the equivalent of “build” (PDF, circuit placement, etc), “test” (simulation and timing analysis), and so on. Jenkins has been successfully used in these fields, thanks to the extensibility.

What are your three favourite Jenkins hacks?

Jenkins has a several mechanisms to let administrators run Groovy scripts to inspect the state of the system or perform bulk operations. I think this is a really cool feature that some users take advantage of. Whenever there’s a talk about this in a Jenkins User Conference, it is always well attended by people who are trying to pick up a nice trick or two.

The HTTP API and CLI of Jenkins are also really useful for building programs that interact with Jenkins. Depending on what plugins you have, the exact APIs and commands you can use are different, so Jenkins contains self-documentation of these features. You should take a look.

Those two features are more for people who are administering Jenkins, so as the last one, let me talk about fingerprints. When you start seriously using Jenkins, you get into the “I have too many artifacts flying around and I can’t keep track of them” problem. This is especially so if different parts of your automation are owned by different teams that are working together. Fingerprints allow you to track artifacts as they are built, tested, integrated, and deployed.

Every time you use an artifact, you tell Jenkins to record its checksum, and by comparing this checksum against what Jenkins already knows about it, it can create a life log of that particular artifact. This fits well with the “survival” view of continuous delivery, where binaries are built once in the beginning and get filtered out / killed off through a series of tests and approvals applied over time.

What issues do you expect to dominate at this summer’s Jenkins/CD Summits?

I’m looking forward to talking about improvements in Jenkins Workflow, and trying to convince more people to write plugins on top of it, or modify existing plugins to work better with it. We are seeing great adoption of Workflow, but we’ve got a lot more work to do, and we can get there faster if we can convince more people that that’s where the future is.

I also expect there to be a lot of mention of Docker. There are a handful of new plugins that help those who are building/deploying containers on Jenkins. I’ve also seen a lot of JUC session submissions around how to use containers to run Jenkins. And there’ll be – as always – more user story sharing, where people show and tell the software delivery challenges they faced and how they have overcome those challenges with Jenkins.

It’s always interesting to learn what issues they faced, which specific functionality within Jenkins was useful to them and what they wrote to develop any new functionality needed to meet their specific requirements. The new functionality they developed will almost assuredly be in the form of another plugin!


Kohsuke Kawaguchi: “The main challenge for Jenkins is with itself”

About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>