In my first job just out of university, I was working on a large project, which was in its early development stage, with the typical tech stacks (Git/Java/Spring/Oracle). The original architect had already prepared the tooling and we were using Jenkins for CI and almost CD. However, we were also automating other things with Jenkins. We had offices in different cities and each office had a TV with a Jenkins Dashboard in full-screen to monitor our critical jobs. I did a lot of coding in that project, learned about good practices and optimization, and above all I acquired a lot of knowledge about many tools and rapidly grew beyond the "coding space" to understand more about what’s going on around it. Additionally, I also started to help manage tools, deployments, and integrations.

I have been using Jenkins since 2012. I was doing a lot of Java/Spring development when I originally encountered Jenkins, and it was our main CI and general automation tool.

In the early days, I was a junior engineer so I did not make the initial choice, I had just discovered the tool. However, it was clear to me that there were not a lot of other options that could match what Jenkins offered.

Back in the day, Jenkins could build in a reproducible environment, rather than our local machine, and also brought us confidence in a branch’s stability. Developers had different operating systems and machines, and some tests that required significant time and resources. This meant that developers were not always able to run them locally. The Jenkins server was crucial to guarantee that proposed changes were stable. Nowadays, Jenkins is a highly scalable and cost-effective CI/CD server, especially when managing ephemeral agents. Most of the CI/CD we manage is templatized, readable, and the complexity level is low.

I am quite involved in troubleshooting various Jenkins issues and environments. A particular aspect of Jenkins that I am keen to troubleshoot is scalability. I enjoy the challenge of reproducing and diagnosing issues that occur only at scale, such as with large queues, large agent fleets, and concurrent builds. Getting to the root of these problems is incredibly satisfying.

When we moved to Jetty 10, I fixed the idle timeout for websocket agent connections that was not identified for weeks. It is a good example of a critical problem that is not simple to find the root cause for, but for which the fix is quite simple once you get it. I also helped fix the restart mechanism of the TCP Agent listener. It was broken for a while and started to become a popular problem around the time we moved to JDK 11. Another one might be the Kubernetes plugin, which can run steps in agent pod containers using the Kubernetes Exec API. However, that API is not really reliable and transient issues can happen. This was known for a while and at some point I just helped by implementing a retry mechanism around it.

I maintain the Support Core plugin and added the ability to download support packages for node, items, and builds. This helped administrators quite a lot, allowing them to gather information from the UI, rather than connecting to the servers. I also maintain the Mina SSHD API plugin, which I created to move forward with the deprecation of other libraries, such as Trilead SSH. Aside from this, I help fix issues here and there when I identify them. In many cases, I spent enough time troubleshooting an issue that the fix becomes the easy part.

The Jenkins project is quite large, but choosing one area to focus on can help with digesting the history and purpose. Alternatively, you can start with small bug fixes. These are most typically found in plugins and can be a feature that you are more familiar with. Importantly, don’t be afraid to open a pull request, as contributions are very welcome. You may be asked to change something, rework something, or create a test. That’s OK; that’s being part of the community of an open source project, and you might just like it eventually.