Welcome!

Plutora Brings DevOps to the Enterprise

Plutora Blog

Subscribe to Plutora Blog: eMailAlertsEmail Alerts
Get Plutora Blog via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Continuous Integration, DevOps for Business Application Services, Continuous Testing, DevOps Journal

Blog Post

Release Managers at a DevOps Divide By @Plutora | @DevOpsSummit [#DevOps]

If you've been a release manager you'll understand that you sit between two groups

If you've been a release manager you'll understand that you sit between two groups:

An operations group tasked with accepting and supporting a software release. This group wants a predictable process, they view releases as incidents to be managed, and they answer to a business that wants predictability and accountability.

One or more development groups tasked with creating software to be released. These groups tend to be more diverse. You might have one development group that is using bleeding-edge technology to create a next-generation website that is more research than development, and another group developing applications against Oracle that is more predictable.

What you understand is that you have to bridge these two groups - groups that use different terminology:

  • When operations talks about a customer for IT Service Management they might be talking about development.

  • When development groups talk about a customer they are likely referring to a real customer of a large website or a system.

Development and Operations use very different tools:

  • When an operations group such as a help desk needs to keep track of changes to production they might use a change management database or an incident response system like ServiceNow or BMC's Remedy. Most of these tools have standard, predictable forms that feed into a well-defined process.

  • When a development team needs to track down changes in a release they might refer to a source repository in Perforce or Github. These teams will discuss architecture and other issues in free-form discussion threads in Atlasssian's JIRA.

These teams use different language, they operate with different tools, and it is your job to coordinate with both of them. So what do you do? Well, you have a choice. Here are your options:

  1. You can side with operations and model your releases as a strict ITSM-focused process. If you choose this path you'll likely have to educate some of the senior members of your development teams on ITIL and what it means to approach IT from a service management perspective. Following a strict ITSM-focused process will absolutely reduce risk, but at the cost of agility. The amount of up-front planning and design required by heavy IT process can suck the air out of the creative, collaborative process that has come to characterize most product development groups.
  2. You can side with development and ask your operations to embrace a more agile, DevOps-focused view of software delivery. In this approach software isn't a service to be managed for an internal customer, it's a shared responsibility of both operations and development to work together to create systems to support software that can be deployed continuously. While this is a popular trend, the largest organizations supporting the most critical systems can't afford to expose the business to the unpredictability and risk that often accompanies a transition to DevOps. Most mission-critical organizations that have adopted a more agile approach to development require a "firewall" around such groups and software releases, transforming DevOps to groups that speak ITIL and ITSM.
  3. You can use a tool like Plutora which provides hooks for both of these views. With Plutora you can integrate systems that track project status in development-focused tools like Atlassian and then turn around and create a CRQ in BMC Remedy - all without asking either group to adapt to the other's process. It is this third way of operating that has come to characterize effective release management.

Release management is the bridge between operations and development. You can think of it as a heat shield protecting a release during the reentry process from a DevOps orbit to a more manageable IT service management approach that the largest companies have come to expect.

If you don't want to bother your development groups with talk of BMC Remedy and IT portfolio management, and if you want to isolate your IT service management teams from the free-form creativity of agile development process, Plutora is the purpose-built tool designed to act as an organizational adaptor.

Plutora facilitates communication and collaboration between different groups involved in the release management process because it was designed by people who have experienced both sides of this equation. Plutora captures the decades of experience our release managers have had delivering agile software to the largest, most risk-averse companies in the world.

Our recommendation is to take the third option. Provide the necessary tools that can facilitate communication across this divide without requiring either side to adopt the tools or terminology of the other.

More Stories By Plutora Blog

Plutora provides Enterprise Release and Test Environment Management SaaS solutions aligning process, technology, and information to solve release orchestration challenges for the enterprise.

Plutora’s SaaS solution enables organizations to model release management and test environment management activities as a bridge between agile project teams and an enterprise’s ITSM initiatives. Using Plutora, you can orchestrate parallel releases from several independent DevOps groups all while giving your executives as well as change management specialists insight into overall risk.

Supporting the largest releases for the largest organizations throughout North America, EMEA, and Asia Pacific, Plutora provides proof that large companies can adopt DevOps while managing the risks that come with wider adoption of self-service and agile software development in the enterprise. Aligning process, technology, and information to solve increasingly complex release orchestration challenges, this Gartner “Cool Vendor in IT DevOps” upgrades the enterprise release management from spreadsheets, meetings, and email to an integrated dashboard giving release managers insight and control over large software releases.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.