The creator of Jenkins has gone native in a cloudy DevOps world
Kohsuke Kawaguchi takes a swing at rampaging Jenkinsteins
Jenkins, er, DevOps World kicked off in Nice this week as CloudBees took to the stage in front of 800 fans of the pipeline to show off some of the toys available to lucky devs.
Kohsuke Kawaguchi, creator of the Jenkins automation server and chief technology officer of CloudBees, launched into a run-through of what he described as the "five superpowers" CloudBees is bestowing on developers (for a fee), after confessing to the audience: "I've been at this more than a decade."
The Jenkins community has been enjoying some impressive growth, adding 24.4 per cent more projects year on year (only counting those that allow usage information to be slurped by the project, of course). That popularity has, unfortunately, also resulted in the growth of what CloudBees CEO Sacha Labourey referred to as Frankenstein Jenkins or, more snappily, "Jenkinsteins" as teams add plug-ins to create a "gigantic, fragile master that falls apart".
Dealing with these "Jenkinsteins" is therefore important.
Unsurprisingly, the cloud and Kubernetes took centre stage, with Cloud Native Jenkins singled out for particular love. "Think of a world where Jenkins runs itself," enthused Kawaguchi, which may be a little worrying for some, considering the WestWorld theme of portions of the conference.
Killer robots aside, getting Jenkins properly cloud native is a priority. The plan is to strip file system-based storage from the product and lose the inherent single point of failure of the Jenkins master process as things scale up and down as needed, thanks the elasticity of the cloud. Kawaguchi pointed to artifact archiving to S3 as an example of progress before wheeling out two members of the Special Interest Group (SIG) working on the project in the form of the Microsoft and Google.
The Microsoft representative, resplendent in an Open Source T-shirt (this is the new Microsoft, remember?), promised that an Azure artifact plug-in would be available in a month or so, insisting the software giant wanted to give users "as good an experience as we can in DevOps". Microsoft, of course, has its own CI/CD product in the form of Azure DevOps.
Because it is impossible to talk DevOps these days without throwing in a Kubernetes reference or two, the Kubernetes-native CI/CD Jenkins X got a nod from Kawaguchi, who insisted "you don't need to be an expert in Kubernetes to utilise it". The command line tool can import an existing project, build a pipeline (along with the likes of Helm Charts for Kubernetes), set it up in GitHub and run the pipeline to deploy a version to a staging environment. Simple, right?
For his part, Kawaguchi likened the approach to a high-speed train that only goes to one destination, that destination being cloud native development: "You can sit back, relax, and let the train take you there."
Jenkins X, some open sourcery that the closed source CloudBees Core v3 will extend (according to CloudBees' James Strachan) runs on-premises or in the cloud. The company intends this will be a step on the road to doing away with the overloaded master model with lightweight services that can be created and also killed at will. Pitchforks and torches await Jenkinstein's monster.
The brave can also sign up for early access to Kube CD, which adds a GUI atop Jenkins X for the delivery and deployment of cloud apps on Kubernetes. Unfortunately, only those bought into Google's Kubernetes Engine and GitHub need apply right now.
Also on the CloudBees Core front (in this case version 2, which has yet to be hit with the re-architecture stick), CloudBees took advantage of DevOps world to announce support for Google's secure LDAP service. The link-up with the Bees' chums in Mountain View will allow the same Google Cloud Identity or G Suite credentials to be used to connect to CloudBees core. Handy if you're heading cloudwards.
Version 3 of CloudBees Core, due next year, will see a fully re-architected engine, which can be flung at Kubernetes clusters as part of an enterprise suite. Chief Product Officer Christina Noren was keen to emphasise that CloudBees Core was the new title of the existing CloudBees Jenkins Platform and CloudBees Jenkins Enterprise before issuing an apology for confusing devs with a seemingly endless parade of product names.
While CloudBees refuses to be drawn on dates (other than Noren promising "this time next year") the governance model due as part of CloudBees Core v3 will be of great interest to jumpy admins with a eye on compliance. The wholesale move to Kubernetes will open up some handy gating abilities to thwart even the most enthusiastic developer.
Pipeline, Evergreen and Configuration as Code
Some upcoming features were also trotted out, although several could be filed in the "about time too" folder. Evergreen, for one, was described as a "radical simplification" of Jenkins with the lofty goal of getting a system up and running in "five clicks and five minutes".
It's something to strike fear into the hearts of consultants, who make a living from persuading enterprises that CI/CD and Agile is a better bet for success than a traditional waterfall approach.
Coupled with "Chrome-like" automatic updating, except without the creepiness, the hope is that things will keep working without requiring constant babysitting.
Along similar lines, Configuration as Code aims to make Jenkins "less of a snowflake", to quote Kawaguchi. The product, version 1.0 of which took a bow in September, aims to allow a user to configure Jenkins using human-readable YAML rather than setting things up manually or hitting the API using custom scripts. Being able to slap version control on a configuration file and roll back a failed upgrade will, according to Kawaguchi, allow "change with confidence".
Finally, Kawaguchi had a warning that Pipeline users who are not already doing so should really be using the Blue Ocean UI by now. It has been around for a while now, and if the creator of Jenkins is saying "I hope by now everyone is using it", then it probably is time. ®