Rethink your tooling: How to make the DevOps promise a reality

Development and Operations continue their entanglement in 2015, supported by plenty of tools and platforms that aim to make this relationship smoother. But challenges still remain in what promises to be an area of profound transformation over the next five years. Like many popular trends, DevOps suffers from dilution as it becomes a catch-all term for marketing purposes. Jevgeni Kabanov expressed his frustration with this turn of events. "I have a bit of trouble with the term DevOps because I'm not sure it's well defined. It's a great banner, and I really want organizations to move to a place where their operations systems are more development oriented." However, Kabanov pointed out that a lot of toolsets and solutions are branded with the DevOps label without an understanding of what that really looks like in action.

DevOps still evades precise characterization

I really want organizations to move to a place where their operations systems are more development oriented.

Jevgeni Kabanov, CEO of ZeroTurnaround

How would the founder and CEO of ZeroTurnaround define the term? Kabanov offered this explanation, "My thinking is that DevOps is dual. The first part is breaking down walls between development and operations. Both sides have to worry about how they are creating value for the customer—whether the customer is internal or external. The other part is more of a trend from the developers' side—using more development techniques in operations. More and more operations people are coding now with things like Chef, scripting infrastructure, clouds, and deployment. It's about having continuous delivery run all the way back to the build. It applies to the whole lifecycle."

Enabling continuous delivery

Karsten Bugner, technical director with Pernexus Systems, spoke highly of the XRebel and JRebel tools his company recently started using. They made the switch when the traditional approach to development proved to be an obstacle to efficiency. "At some point, the autoloader classes and annotations just didn't work anymore. It just got too heavy to run some interceptors on every class. It was too slow—even in development. That's when we started looking for solutions for class reload."

Bugner quickly learned to appreciate the ability to redeploy over and over without restarting the server all the time. He's satisfied with the tradeoffs that came with lightweight tools compared to standard profilers. "This is all stuff you can find using a regular profile like JProbe. We have one of the big-name profilers, and it takes an hour or two to find information. With Xrebel, you don't get the same level of detail. But you get what matters really fast."

Philosophy is primary, tools are secondary

Simon Maple, Developer Advocate at ZeroTurnaround, had good things to say about SonarSource for ensuring code quality. But he broke down quality into two parts—choosing the right tools and putting them to use. Unfortunately, many development teams fall short when it comes to implementation.

"Too often, developers Use a quality tool once and then put it down. It becomes shelfware. Software quality is achieved by continuously using the right code quality tools. Those tools have to be integrated with development processes and continuous integration. They should be part of the build process so that builds will actually fail when these tools find a problem."

From a practical standpoint, DevOps is a two way street. It isn't just about Ops becoming more adept at development. Dev also needs to start thinking about how their development environment enables more seamless deployment and management for Operations. That means Dev and Ops can't play in two different worlds.

According to Maple, separation between the two groups is still a big obstacle. "The ability for a developer to test in the same environment that production is going to be running in is critical. I still see customers using Jetty development environment and then a WebSphere production environment. They test on their Jetty and then deploy on WebSphere. With this approach, some serious issues of quality can get into the code. Simple processes can fix these issues. It's more about getting developers into the mindset of developing quality software than it is about the tools."

Key takeaways for better DevOps

Define DevOps: There may not be a single definition for this methodology, but there should at least be agreement within each organization about the objectives and outcomes desired from implementing DevOps. Find consensus and work from there.

Rethink tooling: If current tools are inhibiting continuous delivery, consider new options that will enable greater productivity without reducing quality. Decide how much information is enough to allow delivery of working software.

Focus on processes and practices: Tools don't change culture—people do. Review current DevOps processes to identify areas of improvement. Implement training and incentives for better practices, and decide collaboratively on the right tools to support these changes.
 

Is DevOps integration a priority for your organization? Let us know.

Why not follow Jevgeni Kabanov (@ekabanov) and Simon Maple (@sjmaple) on Twitter?