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.
Docker is one of those tools, and Docker in conjunction with Jenkins is having a profound effect on development teams. Everyone knows that Docker streamlines development and makes deployment vastly easier, but Labourey observes that it also helps keep developers honest: They can no longer blame some misconfiguration of the development environment when a build crashes and burns. On a physical machine the development environment gradually becomes corrupted, inadvertently causing builds to break. But when you’re coding on top of a pristine Docker image, you have only your own flawed code to blame when builds won’t run.
Together Jenkins and its integrated ecosystem provide the coordinating software infrastructure for agile development and more broadly form “the core of the devops initiative,” says Labourey.
Getting there from here
All this automation and devops efficiency sound great, but what about organizations that have barely wrapped their heads around agile development? Labourey offers advice for wading into CI/CD:
I think the best way to do that is to start small. Pick a project. Don’t say, “OK, now we’re a continuous delivery shop, everything goes this way.” Start with a team that’s willing, that’s maybe more flexible than other teams, maybe newer team members, less entrenched into the existing way of doing things. Pick an easy project. Don’t try to use that as a way to say if that one works, everything will work. Don’t try to fail; try to succeed. Pick a willing team, pick an easy project, get there. This team is going to be your best sales guy because now you can show that it works. They can talk about how their job got better because, frankly, the old way is boring.
Part of the process, notes Labourey, is to "extract the knowledge that sits quietly in people’s brains and put it into the pipeline as logic." That doesn't happen overnight. Often, development organizations begin by hammering out CI and work their way toward CD over time.
Development organizations tend to have widely varied, highly specific requirements. So CloudBees offers both a generic, subscription-based SaaS version run by CloudBees and a "private SaaS" version, which customers can deploy on either AWS or Azure (or locally on OpenStack) and customize it to their heart's content.
It's hard to overstate the importance of orchestrating, automating, and streamlining the development process. CI/CD is central to devops, and a successful devops implementation in turn has implications that extend beyond IT to business itself. Continuously improving software continuously improves products and services. Tesla, for example, had a serious setback with one of its models catching fire -- and rolling out a software upgrade fixed the problem overnight.
"It’s interesting if you get 10 percent more efficiency; if you spend $100 million a year in IT, well great -- you have $10 million you can spend somewhere else," says Labourey. "But the real benefit is when the business realizes that by leveraging those tools and that way of doing things, they can increase sales by 10 percent."