Answer

Release management: How DevOps facilitates collaboration

How is DevOps different from traditional release management?

    Requires Free Membership to View

Change: it is what we are all about. The rate of change is something every organization should measure. It happens everywhere in the business but it is often the changes in IT systems that have the biggest impact. Who controls those changes has long been a closely guarded privilege. But today release management is a board level discussion because it affects growth at one extreme and risk at the other.

The development teams are tasked with creating new systems to meet the needs of the business. The operations teams are concerned with availability of services. While the motto of Ops might be “if it isn’t broken, don’t fix it,” the Dev teams are always eager to deliver “faster, smaller, cheaper.” The tension that results from this is compounded by whom release management reports to. If they report to Dev, they have the pressure to release more and more quickly to meet time-to-market constraints. If release management reports to Ops, the pressure is to slow the rate of change and reduce risk.

Not surprisingly then, the relationship between Dev and Ops has too often been adversarial. In any IT shop, there are numerous stories told of the developers not testing before releasing and of change managers who never approve any changes.

The DevOps movement tries to address that by stating the obvious truth: without collaboration, release management will fail. Getting Dev and Ops on the same page and getting them to understand each other’s needs is the just first step.

Getting Dev and Ops to trust each other is critical. Creating systems that integrate the activities of Dev and Ops makes the biggest single difference and by far and away the most effective tool for that is an online release calendar. By showing what is planned to release and when, both Dev and Ops can see the same information. By making the updating of this calendar an automatic by-product of the development activities, the Operations teams are informed early on about proposed and in motion releases.

Ops now can have a meaningful conversation with Dev about load balancing the release schedule months ahead of the release window instead of the morning before the release. Dev can see the open release holes and manage their project to those dates. And when the inevitable date change happens Dev and Ops stakeholders can be alerted and can react and even sign off to say they have absorbed the impact – or not.

DevOps is a collaborative approach to release management. But let me leave you with this thought: who should DevOps report to?

This was first published in May 2012

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: