CloudBees’ Jenkins X Offers Cloud Native Continuous Integration
This year marks the 200th anniversary of the publication of Mary Shelley’s Frankenstein, as the iconic monster continues to play a very active role in our collective psyche and imagination.
The specter of Shelley’s monster is also part of the software development world, as “Jenkinsteins.” This infamous nomenclature refers to the large and often CI/CI platforms built upon the open source Jenkins continuous integration server, which now extends to deployments on Kubernetes, and more recently serverless, platforms
During the recent DevOps World | Jenkins World 2018, CloudBees CEO Sacha Labourey also made reference to “Frankenstein Jenkins” and how a new project from the company, Jenkins X, can help. He discussed, among other things during a keynote, the active role Jenkins X would play in helping automate and improve the development experience of a smooth the transition from continuous delivery pipelines to Kubernetes and cloud native environments.
During a one-on-one interview with The New Stack, James Strachan, senior architect at CloudBees, the project lead on Jenkins X, discussed how Jenkins X’s support of Kubernetes — and now serverless platforms — reflects how CloudBees, as well Jenkins X, is becoming more cloud native-centric. He detailed how, in this way, CloudBees, as well as the Jenkins community, will continue to help facilitate a massive shift of production pipelines away from on-premise to cloud native deployments.
The obvious goal would be to rid the native cloud development world of the infamous Jenkinsteins, which have very often occurred in the past when organizations began to rely on Jenkins for automating continuous integration and continuous deployment at scale too quickly.
“I think we’re all trying to become more cloud native and transforming what we are doing in a cloud-native way. This is very much how CloudBees is largely about making Jenkins more cloud-native and transforming Jenkins into becoming a more cloud-native system,” Strachan said. “This also reflects what most of us are doing for our own internal applications that we’re building in our products.”
The idea is to extend the classic Jenkins plugin model to be more cloud native, “so you use more microservices, you use customer resources in Kubernetes and so forth so that anybody can extend the platform in any language,” Strachan said.
“One of the main goals of Jenkins X is to reuse whatever we possibly can that’s good. Anything that Kubernetes does, we use it and there’s a whole bunch of open source projects in the Kubernetes ecosystem,” Strachan said. “It’s an incredibly diverse and vibrant open source ecosystem around Kubernetes.”
James Governor, co-founder of analyst firm Redmonk, did not touch on whether he thought the specter of Frankenstein, or even Jenkinsteins, would or would not become an often unwelcome part of cloud native deployments — while he was optimistic about the future of integrating CI/CD with cloud native deployments on containers.
Thanks to the open source community, as well as a number of tools, including Jenkins, Jenkins should continue to see improvements by, among other things, helping enterprises “get better at testing and shifting left,” Governor said. “As part of the transformation organizations are making with automated testing and build processes, the question now is often how they pull all of that together,” Governor said. “What we’re seeing now is a rebuilding of the stack and this is happening across the board in and around cloud-native technology.”
Feature image via Pixabay.
