After receiving my master’s in electrical and electronic engineering from Manchester University, I moved to Sweden and started life as a research engineer at a university. I was working with location-aware applications and mass distribution of media on the internet. This was all before mobile phones had built-in GPS systems. After some time in Sweden, I moved to Hampshire in the UK to work on the "head end" (backend) for a company catering to satellite and cable TV operators, which was acquired by Cisco partway through my ten-year tenure there. Within broadcasting, they call it "head end" and it’s everything that drives automation of the broadcast. This included EPGs, scheduling, and encryption of data and devices as well. So I was working on the management of life cycles, encryption for devices, and other various necessities. I got my first exposure to Hudson at this company, and I think it was a number of months after Kohsuke originally sent the email or announced that Hudson was being updated to open source and that it was available.

I was working with another person on a project that we had to deliver as quickly as possible. It was just the two of us and I’m not a morning person, so I would work late while my colleague, who was a morning person, would work earlier. We were using Subversion because that was our only option back in the day. However, we would forget to check in some files, so we’d add new files, make loads of changes, perform a local build, do the check-in, and go home. Obviously, the codebase ends up broken because merging missed files. After dealing with this for long enough, I was looking for something to prevent this from happening and wanted to incorporate some CI so we could get feedback. This way, when either of us checks in some files, we can know five minutes before leaving and no one is waiting for an update at the end of the day.

So, I spent a while looking around and there were various options out there. We settled on Cruise Control, which I then spent the better part of a week trying to set up, just to check out and build this project, but it just would not work whatsoever. I don’t know if it’s because we were running it on Windows Server or if something else was causing the issue, but everything I was doing was wrong. I had followed the documentation and it just didn’t work. I was just getting incredibly discouraged and then, after getting frustrated for the last time, I decided there’s got to be a better option. That was when I came across Hudson and I figured it couldn’t be any worse. After configuring it, I was up and running in 10 minutes and it was amazing. While working on projects at this company, there was initially no budget for something like this.

However, I was the lab manager for all the manual testing and we had racks of servers that were no longer powerful enough to do encryption. Since they were lying around, essentially being spare parts, I cobbled together pieces from various old servers to give them more memory and then shoved them back in the rack. There was no budget for it and no IT for it, but it was in the rack, ready to go. It was brilliant and we loved it, with other people eventually catching on. They saw what we were doing and they wanted that ability too. Eventually, along with my regular job of developing code and maintaining the lab, I took on ownership of CI that eventually snowballed and spread out across the division. We were a global company with source repositories in different locations, so we wound up with Jenkins (Hudson) in three different environments: Two in the UK and one in Israel, so it would always be close to the source code.

So, if you take when Hudson was first made available and add six months onto it, that would probably be about the timeline. After leaving my previous employer, I moved over to CloudBees and I’ve been working for CloudBees for the last nine and a half, almost 10 years.

In regards to my initial usage, there were some bugs that kick-started my contributions to the project. I was asking for help on the mailing lists and getting answers from Kohsuke, and I started answering questions from other users. That eventually grew to the point that we wanted to stop doing releases from developer desktops, which we were still doing. While we weren’t technically doing them from developer desktops, we were doing releases from servers, but you would log into the server and do it from a server, which is just as bad. That led to my first plugin, which was the M2 Release (Maven Release) plugin. I wrote that so we could do our releases from Hudson, and then it evolved from there. Later on, there were some instances where we started using Cucumber for automated tests. Since there was no good way to show Cucumber test results in Jenkins, I wrote the Cucumber JSON test reporting plugin. plugin. From there, my usage was mostly running and maintaining Hudson. I filed loads of bugs, while also fixing an odd bug here and there.

During my time at CloudBees, I have focused on Enterprise Jenkins or CloudBees CI and all of its various parts. 10 years ago, when I started to work for CloudBees, I was working on the proprietary side of CloudBees' offering. So I was working on a lot of plugins for CloudBees and sometimes having to fix bugs in open source. I’ve also attempted to maintain the acceptance test harness.

Most recently, I’ve been driving the FIPS 140 effort for our proprietary products, which means we have had to have FIPS 140 hooks inside Jenkins. We’ve been working with the team and managing that to get enough into open source so that we can build on it. There’s a JEP and various plugins that we have contributed towards the FIPS 140 effort. CloudBees CI has now gone GA with support for FIPS 140, so the base work for that is obviously in the open source. However, it’s not as easy to run and you need to do your own checks.

While I was working for NDS, the satellite cable company, as we were scaling up and out, we wanted to be able to allow users to create their own projects. However, we wanted them to essentially be rubber stamp templates. So it’s like this: you’re always going to use a Maven project, so the only different things are where your source control is located and what email should be notified when something goes wrong. That was around the time that Kohsuke had just started his company InfraDNA.

I believe the first time that I worked with Kohsuke, was on the Nectar VMware autoscaling plugin which allowed us to have a pool of resources in VMware that were just virtual machines and just resetting to snapshots and assigning them into builds. So we could say, for this build, I need a virtual machine; here you go, here’s an IP address, and we were good to go. I was amazed at the quickness with which he created that plugin. While in Jerusalem, we mentioned something during a meeting and he came in the next day and said here you go, try this. It was almost out of nowhere and the collaboration with Kohsuke was amazing.

Additionally, at the time it had a cutting-edge UI and the test result reports were great. If you compared it to other stuff, they had a little table of pass/fail or a mess. Hudson allowed you to have a summary, drill into things, and show you the full stack trace and full logs right at the bottom of the builds, as opposed to having all the information in a massive sprawling page of mess.

The most recent thing is being able to support FIPS 140 for any federal people that want to use Jenkins and do it themselves. Up until a year ago, you couldn’t really start Jenkins in a FIPS 140-compliant way because the initial use password that it generates would be generated using a nonstandard encryption method, as well as other various issues.

Recently, I made sure that all of the plugin class loaders are named. If something does go wrong and you get a stack trace, rather than having just the class, you have the plugin name and class so you can immediately see which plugin is having an issue. Because it’s not always obvious, it can be, but if it’s not this spells out which class is from the given plugin. So, a little thing for me has made a big difference. When I see a stack trace, I can immediately just read it as opposed to having to infer something and then check.

Early on in our usage, I was very interested in the extensibility and the ease of writing plugins, extending Jenkins itself to make it do new things that it couldn’t necessarily do on its own. More recently, I’ve been doing bits of various things as needed. It’s good in that it allows you to keep a bigger picture as well, so I don’t end up siloed on any one thing.

I think with Jenkins, it has evolution. Gentle evolution all the time that adds to it and makes Jenkins better. Then, every once in a while, you get this burst of updates that makes things so much better. The first burst of updates was Pipeline, followed by Multibranch Pipeline and then check support. In a strange way, they’re all plugins. It’s not Jenkins has done this on its own, it’s more that the Jenkins ecosystem has fostered this. People are always doing small improvements, and those small improvements add up.

Lots of little things for different people, depending on what their focus is. So there’s been many tweaks to the UI, and there’s been a lot of work from people recently for keeping the backend updated. Work such as updating Jakarta EE, removing legacy things, and upgrading to Spring Security and Spring Framework 6. These updates move Jenkins forward for developers, and it means you can do things more easily for users.

For new developers, don’t be afraid to ask. There’s a wealth of knowledge that all the developers have and we lurk in various different places. However, not all of us lurk in all of the same places. If you’re not sure, just ask, people are always there for help. If you find there isn’t an existing answer, but manage to come up with one, don’t be afraid to help by updating documentation for the next person. We do have a lot of documentation, but there’s always room for improvement across the board, whether that is the user manuals, plugin instructions, how to develop, or how to get started. I think 'Getting started' is quite good now, but in the API documentation you may have challenges figuring out exactly which API you need to use to accomplish your goal.

Our code can always use help as well. If you’re contributing to open source, try and make sure your code is documented using something like Javadoc. That way, when you file a pull request, people aren’t concerned that you’ve got no documentation attached. For example, if you’ve introduced a new API, where documentation is crucial to understanding how to use it. This is a fairly standard engineering code practice. Check and ask before spending time writing code, there might be a very good reason that something is not done or not supported. For example, your idea maybe should be coded in a separate plugin, or you should have an extension point so you can extend.