Upcoming Webinar “Mastering Jenkins Security”

I’ll be doing another Jenkins webinar titled “Mastering Jenkins Security” in the next Thursday 10am Pacific Time. It’s a free event, so please register.

After the first webinar, I got a number of feedbacks about the future webinar topics. So when we thought about doing the next one, this came fairly naturally. Unlike the first one, this time the idea is to pick one topic and go do some in-depth discussions. It’s harder to do in a conference, and so I think it’s better suited for webinars.

By default, no security is enabled in Jenkins, so in an environment where a stricter access control is more benefitial, an administrator needs to set this up to suit their needs, and there’s just a lot of different ways people want to configure it. So in this webinar, I’ll start by outlining the basic design of the security system in Jenkins — authentication and authorization — so that you can build a sufficient mental model of how it works, how they interact, and how it can be made to fit your needs.

We’ll then go through the major implementations of those two pluggability points, so that you can pick the right implementation for your needs. There are some plugins, like Active Directory plugin or OpenID plugin, that tightly integrates with respective systems that provide great integration experience. Then there are other plugins, like script security realm, which provides a general purpose mechanism that can be used to integrate Jenkins with arbitrary systems with little effort. Then there’s an entirely different approach of delegating authentication outside Jenkins to the front end reverse proxy. On the authorization side, there are lesser but still a number of options that you can choose from.

Aside from the authentication/authorization, I’ll discuss the security implications of running builds in Jenkins and other standard webapp security considerations, such as cross-site scripting problems, cross-site request forgery issues, and other attack vectors. I think it’d be useful for those who run Jenkins for a larger team.

So once again, please register if you are interested in attending, and if you have future topic suggestions, please let me know!

The Silicon Valley Continuous Integration Summit

I’ll be speaking about the status of the Jenkins project in the upcoming free event “Silicon Valley CI Summit” at the in LinkedIn Mountain View office on April 7th. See the outline of the event, and please RSVP. Hans Dockter from Gradle, Yoav Landman from JFrog, and Ivalyo from LinkedIn will be talking about their respective areas, so it should be interesting.

Normally I do talks that focus on using Jenkins, but for this event I plan on mostly talking about the project itself and what’s happening there (partly because I’ll be spending a whole day talking about the “using Jenkins” aspect on another occasion around the same time, and partly because the 30 minutes time slot is just right for that kind of content.) I hope people are interested in hearing that.

Jenkins hits 1.400

Jenkins is now at 1.400 (as of last Monday, yes, I know. But better late than never…). As with 1.300 and 1.200, this release doesn’t particularly signify any substantial major release, but nonetheless it is a milestone for those of us who are involved in the project — I think repeating something 400 times is something one can be proud of. It’s a bit like climbing a mountain. Left foot, right foot, left foot, right foot, … and when you look up, voila!

In 2 years since 1.300, which was April 2009, we’ve added a lot of features. We now have a CLI to manipulate the server, auto-installation of JDK/Ant/Maven to simplify cluster management, concurrent builds of the same job, community-contributed localizations to 20+ languages, boolean expression over the job/label assignment control, parallel initialization based on a dynamically built acyclic directed graph, console annotations to enrich the build output, far more extensible queue (that enabled a lot of plugins), Windows 7 / Vista support, improved master/slave communication stability, Maven 3 support, and then all around performance improvements, in memory footprint, in startup time, and in page rendering speed.

And of course, we had to change the name of the project. That was a real distraction, but now that the divorce is over, things have been moving well for Jenkins. I guess any organization (including any sizable OSS project) is really more than sum of all individuals. If you take a store of Target and replace all its workers by those of nearby Staples, it’ll probably not work out well. I think people understand that.

And on the positive side, I do think we came out stronger. We are now running governance meetings on IRC, we now have somewhat more formal governance structure. The core development is actually accelarating with the help of many new developers, such as Olivier Lamy, (scroll to the right), and plugin releases kept coming at amazing rate — we are now at 350+ plugins, more than doubled since 1.300.

Looking at future, we are working on a number of new initiatives in the community, too. For example, Arnaud Héritier is working on revisiting our JIRA project structure, Andrew Bayer is running a contest for new logo, Tyler is in process of getting additional hardwares at OSUOSL for the project. I’m also doing a lot of things, but for example, I’m going to write a proposal to start a stable patch releases of Jenkins that only consists of backported important bug fixes, in addition to the current weekly release model. Several large users maintain private branches of Jenkins, and so I think it makes a lot of sense for those folks to align their efforts around this release line. I’m also thinking that we could launch a community acceptance testing (CAT) effort around this, much like NetBeans and GlassFish have done it. I think the first stable release line would branch off from 1.400, so if anything that’s another reason you should upgrade to 1.400.

When I reflect on the project, I’m surprised at just how much work there is to be done, after so much that has been achived. But I’m still excited at what we can do with this platform. I thank everyone for their continued patoronage of Jenkins, and I hope to see more of you in the mailing lists, in the chat rooms, and in the meet-up events. And here is to infinity and beyond!

White paper: “7 Ways to Optimize Jenkins”

Back in Janurary, I’ve done a webinar and discussed a check list for production Jenkins deployments. The main content of that webinar is now available in a whitepaper. Hopefully this makes it easier for more people to get the deployment “right”!

After the first webinar, people gave me various ideas about what they wanted to hear in the future webinars. So I’m looking forward to doing more webinars in the future. (And if you have suggestions about what you’d like to hear, please let me know!)