Bridge the Gap Between Development and Operations (DevOps)

Development teams are “proactive.” Developers create software systems, and they often have an entirely different model of business from the Operations teams. These groups have a wide variation in both process and approach to software releases. Some development groups working on slow-moving, back-office systems may be very amenable to the service management model of software delivery.

Other groups, who are focused on fast-moving, highly technical systems, are not often aligned with the IT Service Management (ITSM) and Information Technology Infrastructure Library (ITIL) models.

Developers focus their efforts on ‘pushing out code’ and tend to be agile, proactive, and reliant on self-service for accomplishing their goals.

When it comes to 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 purpose of satisfying a particular business need. They tended to focus on software delivery and internal quality metrics and left it to release managers to act as a buffer between any internal process requirements, or as a bridge across other groups that may have taken a more formal approach to service management.

In short, developers focus their efforts on ‘pushing out code.’ Changes and enhancements to production systems and attendant failures in providing service are seen as part of this rush to get the latest and greatest code out to consumers. Developers thus tend to be agile, proactive, and reliant on self-service for accomplishing their goals.Operations groups, on the other hand, are “reactive.” They are focused on service management and incident response. Teams supporting operations tend to use organization models closely aligned with ITSM and ITIL. A site operations team at a high profile website will use the term “customer” to refer to internal end users creating incidents and change requests in a system like BMC Remedy or ServiceNow.

In another example, a team managing cloud infrastructure for forty internal development groups will view interactions with internal groups similar to how service providers view relationships with customers. To accurately track cost and forecast capacity, interactions with these groups would then follow well-established patterns for service management.

In a nutshell, Operations teams are responsible for keeping existing services available, meeting agreed upon Service Level Agreement (SLA), while still helping the business innovate by rolling out new products and enhancing existing products.Also, IT Operations are always faced with less when it comes to budget and time. The mantra of doing more with less is driven by easy access to technologies such as virtualization and cloud computing that has increased efficiencies and made IT an open endeavor instead of a CapEx investment.Changes and enhancements to production systems and attendant failures in providing service are seen as part of this rush to get the latest and greatest code out to its consumers.At the same time, competitive pressure and practices such as DevOps now require IT Operations to be nimble, efficient, and cost-effective to ensure they can provide strategic value to the business and not just be considered a cost center.

This balance (business needs vs. accountability) makes operations teams cost-conscious, process-driven, reactive, and wary of sudden and rapid change.

DevOps Challenges in Modern Software Delivery

Historically, ITSM and ITIL were both created to enable a set of standard best practices for service management and IT. When an international enterprise needs an internal Help Desk to manage the delivery of a software project to hundreds of thousands of employees, these are the standards that the enterprise can use off-the-shelf.

Different services can be assigned SLAs, and systems like ServiceNow or BMC Remedy can be used to track incidents. Costs are controlled, and system availability is accurately measured. These models work well if you are delivering a predictable set of services to internal “customers.” Software releases are predictable events, which can be forecast days or months in advance, and are then tracked and managed in a rigid process that aligns with an ITIL standard.

If you are planning a release, you create a series of changes and aggregate them into release requests. A review board approves the requests, and a service analyst identifies the risks associated with the release process.

Ultimately, a detailed analysis of the output of a release-tracking tool—that tracks a release as an incident to be managed and responded to—will identify any further ramifications of the change request.

The DevOps movement emphasizes automation, self-service deployments, and continuous delivery pipelines to support an Agile software development process. When an organization adopts tools and procedures associated with DevOps, this often shifts more of the responsibilities of software deployment and service management onto development teams, who are working closely with operations teams, with developers often driving the initiative.

DevOps seems to be working for some enterprises. In fact, it is not uncommon 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 uncommon. In fact, Etsy makes the bold claim that “a new developer commits to production on Day 1.”

Is this reality to be found across the IT spectrum or is it the viewpoint of a few unicorns?

Most enterprises still feel stranded when it comes to DevOps. While they understand the benefits of being Agile, they do not know where to focus or how to start down the DevOps path. A big reason for this (as outlined in previous sections) is the inherently different nature, approach, tooling, and incentives between development and operations teams.

In short, there is a much overlooked yet huge disconnect within the IT department between teams tasked with supporting software and teams tasked with creating software. In these organizations, the intersection or handoff from development to operations continues to be a bottleneck.

Development still perceives operations as a brick wall they run into despite their best intentions and approach (Agile) to application development. To development teams, it still feels as if they are tossing code over this brick wall, hoping it will be deployed correctly by IT operations. Operations, on the other hand, look at development suspiciously. Has adequate testing been done? What about ticket sign-offs, authorizations and approvals, and due process? How about ensuring the code has been acceptance-tested, been through various stages and gates, and is indeed ready for prime time?

The Solution: Release Management

It is in this context of development meeting operations that Release Management becomes significant. It is indeed the lynchpin for a smooth transition of applications from code completion to deployment into live production environments.It is easy to get carried away with thinking that DevOps begins and ends with ALM tools in conjunction with automation (Continuous Delivery) tools. While these tools serve an important purpose and have been readily embraced by development teams, they still leave huge gaps in the application delivery workflow.Release Management is the bridge between development and operations, and you can strengthen that bridge with the right approach, tools, teams, and processes. Our free white paper provides a tailored approach to creating an efficient and effective Release Management function within your IT organization. Get it now!