Kohsuke Kawaguchi était un des speakers de la conférence What's Next, en mai dernier, organisée par la société Zenika.
Sa présentation intitulée "Taking Continuous Integration to the next level with Jenkins" est disponible ici.
Il est le créateur de Jenkins (anciennement Hudson), un serveur d'intégration continue open-source.
Hello Kohsuke Kawagushi, you are the creator of the Jenkins continuous integration server, formerly known as Hudson.
So my first question is can you tell us about yourself: who are you?
It depends on how long you want the answer to be. I think i sort of started ... I had this little company with my friends while i was in college. He actually most
wrote of this microphone technology, he wrote C++ code in Visual Studio and so on and at the same time i did some XML stuff in Java because that was something that
was supposed the big thing at that time. We put it on a website as open source code. And then someone at Sun MicroSystems noticed that work and he contacted us to
see if i was interested in working with them to write something similar for them. And then i think it was one year after college, and then i thought i could work in
the US, that sounded like a very decent proposition, so i did that. And then I stayed in Stanford, like about 10 years, until it was acquired by Oracle and then
So the CI server started as one of those. It was just like one of those hundreds projects that i was doing and initially i did not expect that to become ???
but somehow it got ??? so i think i kept from doing that until it got too popular. And I also use it at this company and at some point it just stopped being just a hobby,
it just had such demand both inside and outside the company and it made more sense for me to spend more time on it.
And ... in 2008 and then Oracle bought Sun, i stayed for a while and then it did not fit me ??? so i left and then i guess that's where i am, with Cloudbees.
So i suppose that's like a bit about myself.
Alright. Second question, what is your goal for this session ?
So most of the time when i do presentations i talk about things we've already done, that people should start using today. But this conference is actually interesting,
it's like what's next, which is a bit more future looking, right ? So i thought it would be interesting to talk about things a bit higher level instead of talking
of the actual features and more gory details and there are some of that but i wanted sort of us take us ... and then so to explain how i see the underlying forces
that are driving things like CI and other things that we actually work on. It's like a full ad of that. So that's my intent of my talk. I want to show some
higher level review stuff and the interesting trends in the industry, why CI is more reliable ???
So it's like what's next in CI ? Yeah, exactly.
Can you describe the benefits of Continuous Integration ?
So it depends, different people benefit from it in different ways but for example, nowadays, even for a single person project it makes sense to have a CI server
and in that kind of environment the point is, you know when you make some changes in your code, if you just commit the changes and move on to Oracle or something else
right away and in the mean i guess the CI server would be building the changes. And most of the time it would be ok but if you have some problems, you meet them and you
get notified and so you come back later to work on it which is much better than like you run the test locally and wait for them to come back and complete. Before you
commit and move on. For a single person project another benefit is that you can come back to that set up later and the server still remembers how things need to run.
In a large extreme, the manager find it very useful to have additional visibility to the current state of the project so people can see things running from like :
are new tests being written, how often tests are failing, what about the code metrics (like are the bugs going up or going down.
And you can see ... And it's not just for managers, it's also for people ... They get some information about the stability of the components that they are depending on.
How does Jenkins compare with other build and continuous integration tools like Apache Continuum, Cruise Control, JetBrains Teamcity, Atlassian Bamboo, etc ?
I don't spend as much time as i want to look at other tools. I feel like now we have enough users and they give us earful of what we need to do or what we are not doing very well.
There are many users who use other tools so they often tell us about things they miss or don't miss from their old tools so that becomes a part of the inputs to Jenkins.
I suppose that one of the key differences are that some of the tools listed are not open source.
If it's a commercial software it's kind of hard to be introduced in that kind of environment because ...
Some of the tools listed are not extensible. So one of the things that makes Jenkins great in many people's eyes is a large number of plugins that are being developed by the community. For example i do not think that Apache Continuum has any plugin system or any reasonable plugin system so that it makes it difficult to use in most of the environments.
And i suppose the commercial tools also tend to lag behind the plugins because ...
Which functionalities of other continuous integration servers (such as Team City) would you like to add to Jenkins (and, if possible, when)?
I think that one of the things that we have to do in Jenkins is to have some real UI expert to tell us how we could improve the user experience. You know, it does what it does
but currently none of us, core developpers, are UI designers. So that's one thing i'd appreciate to get some feedback on.
I suppose more interactivity in the UI would be useful.
TeamCity's pre-tested commit feature allows you to remotely verify your changes BEFORE committing them to the VCS. When will Jenkins support such feature?
The answer is we already do that. I think there are a couple of different ways that this is done. There is a code review tool called Gerrit that takes advantage of the
distributed nature of Git, the distributed version control system and so there is a very good integration between Gerrit and Jenkins that allows you to do the pre-testing commit
i guess as a mean of code review.
The point of pre-tested commit is you have this code change and you want to run it through a set of tests before you put that back into the repository. It is really like a code review, the only difference is instead of having a human looking at the differences, you want Jenkins to look any change modifications by actually building them.
What you will be doing is you will make a commit and then instead of pushing them to the central repository you push that to this Gerrit code review tool and then Jenkins
acts as a reviewer and it finds out that someone pushed this change for the review and then they run ...
Another way we could do it is in Jenkins the build can be parameterized so the bundle parametre could be defile ??
This needs more work.
I think this process of getting diffs and also creating the commit at then end is highly dependent on version control systems so it's kind of hard to replicate that.
JetBrains also has an IDE that could integrate this.
Gerrit is only for Git. For other VCS, there is this diff / path space ???
When will Jenkins offer a tighter integration with IDEs like Eclipse, IntelliJ IDEA, etc.?
I think we already have plugins for every major IDEs. I'm not up to date with the current state of these plugins but if people come with ideas to improve them, we'd love
to hear them. I dont have any features plans or what things get done but they do exist.
II. About CloudBees and Oracle
Has the acquisition by CloudBees, a Java PaaS provider, of InfraDNA, the company you created and which originally provided support for Hudson, changed your vision of the continuous integration?
I see the advancement of cloud / ??? / high providers and so on very fundamental to the CI. When I think of these virtualized servers, the CI in my mind is like a very much prior
use case of it, for various reasons. So i guess that's part of the reasons i thought that CloudBees makes a lot of sense in terms of what i'm trying to do.
You can use virtual servers to create for example a clean test environment for every execution of the build.
I understand that Hudson was forked into a new community and so Hudson was renamed into Jenkins. What I did not understand is who exactly decided to fork it: was it you and CloudBees or was it Oracle?
The initial thing that triggered the issue when Oracle claimed they own the trademark and therefore things need to be done in the way they dictate. Things like how changes
are made to the core. So several people in the community and me, the only player of CloudBees, we talked about how to avoid this kind of "super power". We seeked some advice from
Sacha because he has more experience.
Recently, Oracle has donated the Hudson project to the Eclipse foundation. What do you think of this donation?
III. Jenkins Continuous Integration (2)
I have installed Hudson and Jenkins on my machine and Jenkins asks me to update it by installing the latest version of … Hudson. So, will the 2 projects remain separated or will they merge? And if they merge, what will be the name?
I think that there are now almost 400 plugins for Jenkins. Can you tell us about 2 or 3 plugins that have particularly impressed you and why?
I did not find many books about continuous integration. Have you got any plan to write a book about continuous integration in general or Jenkins in particular? If not, can you recommend one eventually?
Is there something else you want to say?
How big is the developers community ?
It's kind of hard to track. There's maybe like 5 to 10 people who are contributing to the core and much larger number people working on plugins. It could be 1500.
There are a lot more people who contribute to small changes. They experience some particular problem and they give us a change to fix that and they move on.
That's fine. These small contributions really make a difference. If you look at the total number of people who ever made changes to the Jenkins core i think it's probably
400 or 500.