In meeting after meeting I’ve had with client Operations (Ops) and Development (Dev) teams, I’ve strived to make one side understand the other’s motivations in production control and release management.
Dev wants to move quickly, and often makes oversimplifying assumptions about what’s required to support software in production. Ops would love nothing more than stability, even if it means 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.
For Ops people involved in a complex, risky software release, the process of negotiating timelines and developing plans to mitigate risks often feels like being asked to surrender to the possibility that site availability may be affected by a software release.
Effective DevOps is about relationships between people within the IT department; it is also about adopting tools that can be aggregated in a meaningful way.
Establishing a common language is a good place to start.
Let’s examine three common disconnects between Development and Operations.
1. 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, the developer will think in terms of source code commits and issue numbers: “Is this change related to CTF-324?”
When an operations professional calls development and throws out a request number—“Is this change covered by CRI-4000810?”—the game is already lost. Insight into issues comprising a change request ticket needs to be provided for automating the flow of information between these two systems.
2. Project Code Names versus System Names
Developers, come clean: You like to get creative with project names, don’t you? The next version of the homepage isn’t “Homepage version 2.0;” it’s something arbitrary and 007-ish, like “Atlantis” or “Poseidon.”
Teams of developers will rush to deliver “Poseidon” without even thinking that Operations views this as a version 2.0.4 running on the production network.
This might seem like a small disconnect solved by an email mapping project, code names to version numbers, but think about an organization with more than two development teams and hundreds of systems in production: a single source of truth for what’s going into production and what people should call it needs to be provided.
Consider 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, 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 need to go back through source code and figure out when a binary was shipped to production. With an aggregated solution, both Ops and Dev can look at a history of changes—an end-to-end history that doesn’t have gaps due to miscommunication.
3. What do Trust and Transparency Looks Like? Trust but verify
An aggregated system 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 Ops. Operations’ people use tools, such as BMC Remedy and ServiceNow, to track production changes, but these two systems never meet.
With an aggregated solution, they do meet, and over time Ops and Dev 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.” 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 an aggregated system, developers realize that “operations” isn’t a separate process from development. Instead, they understand it is an essential part of the software development lifecycle and how code is qualified and delivered to production.
Developers start taking a more proactive role to ensure production changes can be tracked and 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 up time, gain the ability to predict releases in a way that increases trust.
Need for Aggregation of Data
There’s a lot going on: Agile, Orchestration, DevOps, Microservices, Continuous Integration, Delivery and Deployment; a data aggregator and real-time reporting are must-haves.
The good news? DevOps Analytics can be aggregated in seven different data models (including Agile Project Management, Source Control, Build Pipeline, Code Quality, QA, Production Availability and IT Service Management). Even better, the results are compelling enough to satisfy various stakeholders.
Please see Exhibits A, B and C as reference examples from DevOps Analytics used at Accenture.
Exhibit – Release readiness
Exhibit – B Infrastructure monitoring
Exhibit C – Application monitoring
Without a system to aggregate all of the data models, Development and Operations must overcome a high wall of confusion. But it doesn’t have to be that way. A little communication goes a long way. How are your language skills?