Oleg Nenashev
Oleg is a developer tools hacker, community builder and DevRel consultant. He's passionate open source software, open ecosystems and open hardware advocate. Oleg is a core maintainer Jenkins project where he writes code, mentors contributors and organizes community events. He is a CNCF and CDF ambassador, Testcontainers Champion and a former Jenkins Board member and CDF TOC Chair. Oleg has a PhD degree in electronics design and volunteers in the Free and Open Source Silicon Foundation, and in a number of Ukrainian support and Russian anti-war organizations.
Sessions
Jenkins has been one of the most popular automation servers in the world. It is widely used for CI/CD purposes in cloud environments. You may have heard that Jenkins is not cloud native, and of course it is true. You may have heard that Jenkins controllers are a legacy monolith from the 2000s. That is not true, it is quite cloud friendly if used right. And yes we tried to make Jenkins cloud native, but it didn’t quite work. Why?
I have been involved in Jenkins architecture projects for more than ten years, including pluggable storage, multi-tenant Jenkins, cloud native agents, breaking down the controller monolith, Kubernetes integrations, etc., etc. Some of these efforts worked, some didn’t. But it was a great learning experience that can be used by developers and maintainers of other projects that consider re-platforming them to make cloud- and Kubernetes-native. I'll talk about the technical assumptions and mistakes we made in Jenkins, and how it worked. What to keep in mind when doing the re-platforming? And do you even need it?