For smaller organizations and startups, DevOps adoption and the choice to use a modern CI tool have a relatively straight forward path. However, for larger enterprises that have legacy development processes and tooling already embedded, DevOps adoption isn't quite so easy. But overcoming the DevOps adoption hurdles, even for large organizations, is well worth the effort -- and that's a popular sentiment amongst the attendees and speakers at Jenkins World 2016.
"All the new companies start with an automated build with Jenkins. It's easy for small shops," said Scott Hickey, principal enterprise architect at Mutual of Omaha Insurance Co., based in Omaha, Neb. "They wonder why everyone isn't doing it, but the divide between how easy it is for a small development team to automate deployment with Jenkins and how difficult it is for a large organization to bring all of their projects onto a continuous integration (CI) platform is a large one."
So, how did Mutual of Omaha make the transition? "We had most of the projects building in ANT," Hickey said. "We had Jenkins, but a build only occurred when people wanted to do a deployment. It would put that artifact into an IDE [integrated development environment] depository, and our custom Grails app would pull it and out it onto our clusters."
Now, Mutual is getting on board with DevOps adoption in a more comprehensive way. "What we've been trying to do is implement a continuous integration platform. It may not sound all that revolutionary, but it is for us. We're putting together a pipeline using things like Apache Subversion and Jenkins for automated build [and] test," Hickey said. "The next step does static code analysis with Sonar. Then, we generate an artifact for Artifactory. But we're still doing manual deployment. We're not yet in the cloud. We are deploying to clusters of WebSphere or Tomcat. We're working on building a private cloud right now."
The DevOps adoption journey itself has given the organization a better handle on fast, iterative development. Now, it isn't just the project management that is Agile. The software engineering process itself is becoming Agile for the first time. "In the past, there wasn't really any emphasis on tests; it was just about having a repeatable build. Now, we are building on every check-in." With Sonar, Jenkins and Gradle, Hickey's team has constant feedback and high visibility into code quality using build and test automation. The result is a cultural shift that prompts development teams to check in codes and tests together, so quality is assessed on a continuous basis.
Jenkins paves the way from continuous integration to continuous delivery
I want people to understand that DevOps adoption and CD [are] applicable to every piece of software that's delivered to customers.
R. Tyler CroyJenkins contributor
For organizations that already have a handle on CI, the next step in the DevOps adoption lifecycle is moving from continuous integration to continuous delivery. CD itself is a somewhat misunderstood topic, as many envision CD as being a steady stream of software delivery, with no pauses or manual intervention, where code goes through the build process, and then goes straight into deployment and production. But the reality is more nuanced. "CD is about having your software in a state to be delivered. It's doesn't necessarily mean pushing every commit to your customers," according to Jenkins contributor R. Tyler Croy. "There may be business requirements or manual testing that needs to happen. If you are building an Android app, you're not going to try to push a 10 MB commit every day of the week -- that would be craziness."
However, even if it isn't taken literally, CD should be ubiquitous in principle. "I want people to understand that DevOps adoption and CD [are] applicable to every piece of software that's delivered to customers," Croy said. "For example, you can have continuous delivery of embedded, or have Android publishing into Google Play Stores and data channels."
With software living everywhere from mobile to internet of things, there's no reason the CI/CD model has to be restricted to traditional apps. "It's not just for SaaS [software as a service] or building web applications. Any software that's delivered to customers at any point can benefit from adopting this pipeline of code and delivery practice. The goal is to get code to the customer. CD is about automating those processes, and Jenkins is a good tool for that."
