Trends like agile development, devops, and continuous integration speak to the modern enterprise's need to build software hyper-efficiently -- and, if necessary, to turn on a dime.
That latter maneuver is how CloudBees became the company it is today. Once an independent, public cloud PaaS provider for Java coders (rated highly by InfoWorld's Andrew Oliver in "Which freaking PaaS should I use?"), CloudBees pivoted sharply 18 months ago to relaunch as the leading provider of Jenkins, a highly popular open source tool for managing the software development process.
According to CEO Sasha Labourey, as a Java PaaS provider CloudBees had been "growing nicely," but "a lot of the bigger guys with the bigger checks" were hesitant to commit in a volatile PaaS market that lacked standardization. At the same time, Jenkins was taking off like a rocket -- and Labourey saw a big opportunity, particularly since CloudBees was already offering Jenkins as a service and had already hired Kohsuke Kawaguchi, Jenkins' creator. The Jenkins side dish became the main course.
The Jenkins juggernaut
What's behind Jenkins' popularity? Simply put, Jenkins has become the open source standard for managing the dev side of devops, from source code management to delivering code to production. According to Labourey, "The community sees Jenkins as an orchestration and automation engine ... I think the reason why Jenkins has become the de facto engine is because it's extremely pluggable." An ecosystem of more than 1,100 plug-ins has emerged, enabling customers to add all sorts of functionality and integrate Jenkins with everything from Active Directory to GitHub to the OpenShift PaaS.
Jenkins is a continuous integration (CI) and continuous delivery (CD) solution. The idea of CI is to merge code from individual developers into a project multiple times per day and test continuously to avoid downstream problems. CD takes this a step further to ensure that all merged code is always in a production-ready state. Jenkins enables developers to automate this process as much as possible -- up to the point of deployment. Labourey provides an example:
Say a company is using Chef or Puppet to deploy on AWS. Jenkins is not going to replace that. Jenkins is going to be calling Puppet to do it -- OK, here are the bits, so let's call this Puppet script and see how it works. And the output of Puppet's execution is going to matter to Jenkins because it might decide to unroll the deployment and take further actions. We call it "the pipeline." It's really this series of steps. It could be five steps, or it could be 50 steps.
Jenkins serves as the workflow engine to manage this CI/CD pipeline from source to delivery, Labourey says, but along the way many different tools may be called upon to perform different functions.
Sign up for CIO Asia eNewsletters.