How one programmer's efforts to stop checking in buggy code changed the DevOps world
Father of Jenkins, Kohsuke Kawaguchi, talks Sun, software and secret sauce
Interview The father of popular code pipeline Jenkins has big plans for its future while admitting that it owes its existence to his habit of introducing bugs to code.
After delivering a keynote to a crowd of excitable DevOps fans, creator of the Jenkins project (and now chief technology officer at CloudBees) Kohsuke Kawaguchi took some time to chat about how the pipeline came to be, the plans he has for the future and if he actually gets any time to cut code any more.
For the latter point, the answer is not much. Which is probably not a bad thing, since as Kawaguchi confessed to El Reg he had a habit of leaving a trail of bugs. While working as a Java programmer at Sun Microsystems in 2004 he would regularly get phone calls from his colleagues.
"They noticed that suddenly the stuff doesn't even build or whatever. They call[ed] me up on the phone, and they're like: 'OK, I think you touched this the last time. Can you look into it?' Usually, it's because of my fault."
Like any good programmer, Kawaguchi decided to try to solve the problem with code. "I felt, a bit, there were one too many times of those. I felt like I had to write a program."
This program is what would become Hudson, a continuous integration tool, and would go up against the likes of more established frameworks, such as the Java-based CruiseControl.
Competition was, however, not on Kawaguchi's mind. He just wanted to make life easier for his colleagues. With Hudson, he reckoned he'd be taking away build and integration from the list of things programmers have to worry about and observed: "The more we can offload into the rest of the surrounding system, the automation, the computers, the better."
Around him, however, he'd noted that things at Sun had started to go downhill. "A lot of good people had left," he said, but thanks in part to Hudson, incoming staff could be trained up faster. "I just see this as one more way of offloading something from people's minds," he explained, "[a] way of making juniors more productive by learning the programs on things that really matter."
Going open source
Inspired by the open-source ethos of certain parts of Sun at the time, and also because his creation had already become way too large for one person to manage in his spare time, Kawaguchi made the project open source.
"Well, for me, it was very automatic. In fact, I don't think it [would] have gotten to this point if it weren't open source... Also, [at] Sun Micro Systems at around the same time, we were also trying to do everything in open source."
Kawaguchi is very satisfied with how that part of the project turned out: "I felt like that created a very big tent that everyone can enjoy. Ideas get better when they're exchanged. The best way to get the idea exchanged is actually having the code more out there."
The demise of Sun Microsystems is well documented. The company was snapped up by Oracle, which claimed a trademark on the Hudson name in 2010. However, the code was forked and the project continued in 2011 under the name of Jenkins. Hudson, alas, foundered under the control of Oracle and was handed over to the Eclipse Foundation before eventually being declared obsolete in 2017.
Unimpressed by Oracle, Kawaguchi set up his own support operation for Hudson in the form of InfraDNA in 2011. Later that year, CloudBees snapped up the outfit and Kawaguchi was eventually named Chief Technology Officer (CTO) of the Jenkins specialists.
Being CTO has been an interesting experience for Kawaguchi. "CTO is the strangest role. It's not very well defined... I find my role keeps changing over the eight or ten years that the company has been here... I had to figure that out as I go. It used to make me very nervous, but now I've embraced that."
What's next for Jenkins and CloudBees
As CTO, Kawaguchi admits to being spoiled for choice. While he is less "hands on" these days with the Jenkins project, he remarked that "every possible thing I could pick up is all fun. Like talking to customers is great fun, writing code is also very fun. Incubating new products has been great fun."
Looking ahead, Kawaguchi is excited about the upcoming compliance and governance model due to make an appearance in 2019, which will allow administrators to stop a pipeline dead if certain criteria are not met. Something that will be of great interest to the enterprises in the regulated space.
Addressing this, he said: "The compliance and governance is actually very close to my heart. I see it as a major struggle for, especially the larger enterprise, to go faster.
"So, I feel like when we can help them get better at software development, like we are making the bigger impact in the world."
Testing is another area Kawaguchi describes himself as passionate about, and something in which the CI/CD approach has taken great strides (in terms of motivating people to write more tests at least). However, he worries that while there is "good software development hygiene where people are writing lots of tests... there's usually not a lot of thought put into how effective these tests are.
"It's usually the testing that dominates the time it takes for the change to get validated, and then put into production."
Automating the generation of decent tests remains a challenge. Kawaguchi is aware of efforts to use machine learning to spot errors, but reckons such an approach currently lies at the fringes of automation. Instead he is most interested in looking at the vast data sets generated by the successes and failures of past executions to work out which subset of the test suite to run first.
And, of course, end users could form part of the equation. Kawaguchi observed that some of the companies he's visited take the approach of diverting some small portion of production traffic as a final testing stage but is keen to emphasise that such an approach must be taken with care "so it doesn't impact the customer".
A final dash of secret sauce
The impact of Kawaguchi's work on the development community is undeniable. While the father of Jenkins is less involved nowadays, he remains amazed that "this power to evolve itself, it's still within this Jenkins community after 10 year[s]".
The constant development and reinvention by the community continues to have him enthused about the framework. "I feel like that's what the whole secret sauce of this Jenkins project is. It can redefine itself over and over." ®
Sponsored: Becoming a Pragmatic Security Leader