When we talk about tools, developers are more at home managing development processes with issue tracking tools like Atlassian’s JIRA, and configuration management tools like Puppet or Chef.
Traditionally, development teams had the sole objective of satisfying a particular business requirement. They led to focus on software delivery and internal quality metrics and left it to release managers to behave as a buffer between any internal process requirements, or as a link across other groups that may have taken a more precise approach to service management.
In short, developers concentrate their efforts on ‘pushing out code.’ Changes and improvements to production systems and attendant failures in giving service are seen as a section of this rush to get the latest and greatest code down to consumers. Developers thus manage to be flexible, proactive, and reliant on self-service for achieving their goals.
Operations groups, on the opposite hand, are “reactive.” They are focused on service management and incident response. Teams supporting operations serve to use organization models closely followed with ITSM and ITIL. A site operations team at a high profile website will utilize the term “customer” to relate to internal end-users building incidents and change requests in a system like BMC Remedy or ServiceNow.
In a different example, a team maintaining cloud infrastructure for forty internal development groups will view communications with internal groups similar to how service providers view relationships with customers. To precisely track cost and forecast capacity, cooperations with these groups would then follow well-established models for service management.
DevOps Challenges in Modern Software Delivery
Historically, ITSM and ITIL were both designed to enable a set of standard best methods for service management and IT. When an international enterprise requires an internal Help Desk to handle the delivery of a software project to thousands of employees, these are the measures that the enterprise can utilize off-the-shelf.
If you are organizing a release, you build a series of changes and aggregate them into release requests. A review board allows the requests, and a service analyst recognizes the risks associated with the release process.
Ultimately, a detailed study of the output of a release-tracking tool—that follows a release as an incident to be managed and replied to—will identify any further implications of the change request.
DevOps Development Operations Gap
DevOps seems to be operating for some enterprises. In fact, it is not unusual to hear success stories from the likes of Facebook, Netflix, Amazon, or Etsy. Claims of multiple (in some cases hundreds) of deployments a day are not unusual.
Most companies still feel stranded when it comes to DevOps. While they know the benefits of being Agile, they do not understand where to focus or how to begin down the DevOps path. A big reason for this is the inherently distinctive nature, approach, tooling, and incentives between development and operations teams.
In short, there is a much neglected yet huge disconnect within the IT department between teams tasked with supporting software and teams tasked with creating software. In these industries, the crossing or handoff from development to operations remains to be a bottleneck.
The Solution: Release Management
It is in this context of development meeting methods that Release Management becomes significant. It is surely the lynchpin for a smooth change of applications from code completion to deployment into live production environments.
It is simple to get carried away with assuming that DevOps begins and ends with ALM tools in combination with automation (Continuous Delivery) tools. While these tools assist an important purpose and have been easily embraced by development teams, they still leave large gaps in the application delivery workflow.
Connect with TestUnity to create an efficient and effective Release Management function within your IT organization.