I’m leaving San Jose tomorrow to head to Germany. My first stop is Hamburg, where Nils Hofmeister kindly organized a Jenkins developer hackathon on Sunday. (Also thanks to Christoph Kutzinski for making connections.) If the past San Francisco Hackathons are of any indication, this should be a fun event for existing Jenkins developers and those who are interested in writing plugins, so if you are nearby, please join us. I’ll then be speaking in Hamburg JUG, thanks to Björn Jensen from Hamburg JUG, Monday evening about Jenkins. It’ll be a bit of the current state of the project, then more about various advanced features of Jenkins.
On Wednesday, I’ll be speaking in JAX 2011. If you are attending in JAX 2011 and interested in seeing me, please drop by and say hello! I’ll be then back to San Jose on Thursday.
This is the first time I visit Germany, so I’m really excited for a week-long trip. It’s a real shame I won’t get much time sight-seeing around.
A few weeks back, I’ve presented the current state of the Jenkins project in the Silicon Valley CI Summit. This wednesday, I’ll be doing a re-run of this talk as a webinar.
The talk focuses on concrete numbers that illustrate the progress of the Jenkins project, and while any numbers need to be taken with a grain of salt, I think it helps convince those who are interested in switching to Jenkins. This is also your chance to ask questions!
Looking forward to seeing you this Wednesday 10am PDT / 1pm EDT / 5pm GMT. Please RSVP.
Since I’ve talked about Jenkins in the CI summit event with Yoav from JFrog/Artifactory and Hans from Gradle, I thought I’d highlight some of the integrations between Jenkins, Artifactory, and Gradle.
First, Artifactory. Artifactory integration for Jenkins have been available for quite some time now, and it is rather mature. One of the nice things about it is that it got something for everyone — not just for Maven users, which seems to be their recent theme. For Maven, the Artifactory plugin takes over the default deployment mechanism. For Ivy users it does something similar, and takes over the deployment. (And for me, I like that it’s choosing Jenkins!)
There are a number of benefits in letting Jenkins take over the repository deployment. One of it is that you can postpone a deployment until after you are sure that the build is successful in its entirety. In contrast, if you deploy it during a build you normally deploy one module at a time after that module is built, which results in a partial deployment if later modules fail to build. If you fancy, you can further combine this with promoted builds plugin and delay the deployment until you run a series of tests with that binary, or combined with static analysis plugins, you can prevent a deployment if the build doesn’t meet certain quality criteria.
Another benefit of letting Jenkins take over the deployment is a credential management. With Jenkins, you only need to enter a credential once and have everyone uses it (and without revealing the password.) This is much better than ensuring that the credential is available on every machine in a cluster, or baking it inside the build script.
Gradle integration with Jenkins also goes back, and it provides a nice GUI binding for invoking Gradle from Jenkins. On top of this, I recently added an automatic installer, which lets Jenkins install Gradle on your build slaves automatically on demand. There’s a lot of potential to this plugin, for more deeply understanding the execution like Jenkins do with Maven, so stay tuned for updates.
The event was well attended, and I believe the recording will be made available soon.