Tickets Are Not the Glue That Holds a DevOps Team Together

DZone 's Guide to

Tickets Are Not the Glue That Holds a DevOps Team Together

Do you claim to be doing DevOps while still communicating primarily via tickets? Then you are doing DevOps wrong.

· DevOps Zone ·
Free Resource

“We need to slash our page download times!” It’s not an unreasonable request given just how much research shows performance affects engagement.

These days there are so many options for improving the performance of your website. Obviously optimizing your code is one way, but external services like CDNs, memory caches and web server plugins also provide excellent opportunities to increase performance.

Melding web applications with external services requires detailed knowledge of both the infrastructure and the code. How exactly can a web application be split up so static resources are served by a CDN while server generated resources don’t get cached? How does cache TTL or invalidation affect the validity of business critical data? These are the kind of issues that will make or break a project that crosses the boundaries of code vs infrastructure.

We all know the solution: DevOps. If you have a team with a common goal and top to bottom knowledge of the problem space, the question of crossing boundaries is no longer a concern. Problems are solved quickly and efficiently as people bounce ideas and solutions around a tight-knit team.

The issue is that a lot of what people call "DevOps" is really just a dev team and an ops team playing the telephone game through a ticketing system. This childhood game is famous for demonstrating just how much is lost in translation as a message is whispered from one person to the next, and while writing things down in a ticket does eliminate the variability of the message, it also typically removes a lot of the context that the ticket was created in response to. 

Ticketing systems are perhaps a necessary evil for capturing issues across groups of people who have no other choice than to communicate electronically. I certainly don’t expect for a developer of an open source library who lives on the other side of the world to get up at midnight to have a chat on the phone about an issue I discovered in their code. It is also appropriate for well-established business processes like creating a new user account, or for tracking the progress of problems that are already well understood and in the process of being resolved.

But ticketing systems can not not be the glue that binds dev and ops teams together. There is just no way that the kind of intricate issues that face these teams every day can be adequately captured by a text box and a couple of categorization drop down lists. Attempting to do so guarantees that even trivial problems take weeks to solve, and innovative new solutions are never implemented.

If being assigned a ticket is the first time members of your dev or ops team hear about a problem or see a request for some new feature that makes up a part cross-boundary solution, then you are not doing DevOps. And if you are not doing DevOps, then you are not in a position to take advantage of all the solutions that require knowledge of both code and infrastructure to implement.

devops, devops best practices

Published at DZone with permission of Matthew Casperson , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}