When Forrester analysts Amy DeMartine and Kurt Bittner wrote “The Seven Habits of Highly Effective DevOps” the habit I focused on was habit number one: “Establish trust and transparency between Dev and Ops.” This is at the core of release management: DevOps Trust and Transparency – ensuring that both sides of this equation agree when it comes time to ship software.
In that report they compare DevOps to therapy for a broken relationship between Dev and Ops listing the stereotypes that either group has about the other. Bridging the divide between these two departments can, at times, feel like counseling an organization to communicate better. I’ve had many meetings with both Ops and Dev teams simply to find a way to make one side understand the other’s motivations when it comes to production control and release management.
Dev wants to move quickly, and they often make oversimplifying assumptions about what is required to support software in production. Ops would love nothing more than stability even if it means that critical software updates are blocked to preserve uptime. Bridging the gap means having lots of meetings, translating different vocabularies, and becoming an expert at understanding what motivates each team.
Release Management is Shuttle Diplomacy
“Shuttle diplomacy” is a term used in international relations. Think of two sides of a contentious conflict – so contentious that they refuse to meet with each. It’s often up to a small group of diplomats and negotiators to literally “shuttle” between two hotels in a neutral city to bridge this disconnect. Once an agreement is in sight, only then will the two parties agree to a meeting. For a complex, risky software release the process of negotiating timelines and developing plans to mitigate risks often feels like the asking operations to surrender to the possibility that site availability may be affect by a software release.
Whether you feel like a therapist or the Secretary of State, the process of building a dialog between Development and Operations suffers from a disconnect made more difficult by the incompatibility of the tools either side uses to communicate. Effective DevOps is about relationships between people within the IT department, but it is also about adopting tools such as Plutora that can translate between two groups.
Establishing a Common Language for DevOps
Plutora saves you from having to be the middle-man to a complex negotiation between Development and Operations because it establishes a common language for releases. Let’s examine three common disconnects between Development and Operations:
Issue Numbers versus Change Request IDs – Developers understand code and the issues filed in systems like JIRA to track feature requests and bug fixes. When a developer needs to understand the root cause of a bug they will think in terms of SCM commits and issue numbers. “Is this change related to ITP-324?” When an operations professional calls them up and talks about a request number in BMC Remedy the game is already lost. “Is this change covered by CR3000923?” Plutora gives everyone insight into the issues that comprise a change request ticket because it is responsible for automating the flow of information between these two systems.
Project Codenames versus System Names – Developers get creative with project names. The next version of the homepage isn’t “Homepage version 2.0”; it is some arbitrary codename like “Phoenix” or “Wasabi.” Teams of developers will rush to deliver “Wasabi” without even thinking that operations views this as aversion 2.0.4 running on the production network. While this might seem like a small disconnect solved by an email mapping project codenames to version numbers, think about an organization with more than two development teams and hundreds of systems in production. Plutora provides both sides with a single source of truth for what’s going into production and what people should call it.
Release Versions versus Release Dates – Once a developer pushes code to production they might get a call from a system administrator, “What code did you push last Thursday?” In most organizations without Plutora, the release process is a mystery owned by a small core of developers – the ones that have the patience to focus on this “last mile” of development. Unless the organization has built-in instrumentation to quickly identify what code version is in production most developers won’t know the answer right away. They will have to step back through source code and figure out when a binary was shipped to production. With Plutora both operations and development can look at a history of changes – an end-to-end history that doesn’t have gaps due to miscommunication.
What Trust and Transparency Looks Like
Plutora brings transparency to a department by filling in the information gap that exists between Dev and Ops. Developers and project managers create a rich trail of information about changes in a release and the process used to qualify a software release. It is this essential data that is often “walled off” from operations. Operations personnel use tools like BMC Remedy and Service Now to track production changes, but these two systems never meet.
With Plutora they do meet, and over time you’ll find that operations departments and application development teams start to appreciate one another’s roles. Developers understand the process and procedure necessary to promote code from “code complete” to “live in production,” and operations professionals appreciate having a window into the development process.
As this trust and transparency becomes more established it encourages a new way of thinking about software releases. With Plutora, developers become more aware that “operations” isn’t a separate process to be separated from development. Instead, they understand that it is an essential part of the software development lifecycle to understand how code is qualified and delivered to production. Developers start taking a more proactive role to ensure that production changes can be tracked and that teams are made available to communicate about upcoming releases before they surprise a production support team.
On the other side of the wall, operations professionals focused on infrastructure and uptime gain the ability to predict releases in a way that increases trust. Without Plutora, there’s a Wall of Confusion between the two departments and operations has very little ability to predict what’s going to be thrown over that wall. Without Plutora operations feels like they are under constant surprise attack by development teams that advertise false or constantly slipping schedules.
With Plutora you’ve invited both parties to the table to start the continuous process of learning how to communicate.