DevOps Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Forget Trains. Take off on a Release Plane!

08.25.2012
| 7782 views |
  • submit to reddit
airplane by Kuster & Wildhaber Photography
Creative Commons LicenseKuster & Wildhaber Photography

 

This is a guest post by Kevin Parker, VP and Evangelist, Serena Software


For those that have to deal with release management, release train is a well-understood term. It refers to a software development schedule where multiple products are released as a part of a single ‘train’ on a regular, pre-planned schedule.

But just as a train can be late thanks to leaves on the line, a fatality or engineering trouble, so release trains can be delayed by both internal and external problems. In order to solve this, it’s time to get off the train and look upward for inspiration.

When we think about catching a train we know we can arrive a few minutes before it is due to depart and still get on board. We can seat ourselves wherever we want in a carriage. At a train station, the ticket barrier may be non-existent and, once aboard, rarely is your ticket inspected.

Anyone can bring any amount of luggage, regardless of weight limit, and it can contain whatever we like because no one checks it. In the days before automatic doors, I have been able to sprint down the train platform, open the door and jump into a moving carriage.

What message does this send project teams wanting to join a release train? The message is ‘Just get on the train’. Release teams don’t seem to mind if it is cramped. The entry criteria can be low and often waived. The team may not have time to check whether a particular release has the credentials needed to be on the train. The release team trusts that an update won’t to be disruptive. This also assumes that all of the different teams and individuals involved know what is going on and why.

Today, we have many release management processes that are well designed but the problem is they are not well enforced. So, I think it’s time to drop the release train metaphor and start talking about the release plane.

To board a release plane, you first have to go through airport security – the quality assurance of IT. This means that not only are you not bringing your hand gun and Swiss army knife, you are not allowed to bring lethal amounts of mouthwash and hair gel.

You can’t even think of bringing your deceased great aunt’s gigantic suitcase as hand baggage because the vigilant airport staff will wrestle it from your grip, enjoy telling you off and tag it for delivery at your destination. This all happens before you even see the plane.

You will also not be getting on the plane if you are not standing patiently with the rest of the passengers waiting to board in the 20 minutes allocated for boarding. When that door closes no amount of pleading, serious family crisis, nor career-making meeting is going to guarantee you a ride on that plane.

But we all know this. The airlines have conditioned us to accept that their terms of carriage and timetable are intractable. Meanwhile, train companies make us feel that their open platforms, open seating and open tickets are there for passenger convenience – and to be taken advantage of.

Entry on to a software release plane requires you to not just meet but exceed a train’s entrance criteria. This includes everyone knowing what is defined at the beginning of a project, how big the number of releases are, and ensuring that all the processes are followed from start to finish. This includes both the ‘assembly’ of software as well as all the testing and business compliance requirements too.

This approach sounds incredibly regimented, but it does not have to be. What it does require an understanding of what is involved across all elements of the application delivery team.

Release trains are not the most agile method of getting from A to B by today’s transportation standards. On the other hand, planes can get to the destination fast, turn around quickly and offer full visibility of who and what is on-board.

Project teams must take responsibility by arriving at the gate ready to go and fully committed to the destination. Let’s not make lack of planning and preparation on behalf of the passengers, a burden placed on the crew of the release plane.

Once we are in the air, there must be no chance to add extra baggage, finesse our packing or get off because we decide we’re not ready to meet the prospective in-laws. If you get on the plane you are committed.

Release managers are pilots. They are highly skilled, well trained and very experienced. They get you safely from your development departure airport to your production arrival airport. Their job is not to make sure you packed your toothbrush or your passport. They charge a lot of money for what they do because their job is fraught with danger and they carefully navigate around the storms so you don’t have to. They get you to where you are going on time, carefully and quickly because they can.

Recently, I’ve been working with a component manufacturer that is facing a massive release management problem. Its release trains arrive just four times a year and when they do, they are brimming over with all sorts of cargo and interesting passengers, many of whom have been on their journey for months or even years. In fact, the train has so many carriages it takes 70 hours to unload.

The release plane approach is much more suited to their business needs, as it enables them to pinpoint opportunities and work requests in far greater detail. This change in approach makes sure they meet their process and compliance requirements, but also makes them more efficient as a whole.

To make the change from release train to release plane, organisations have to have better orchestration of their release management processes. We need a more efficient and controlled approach to how software is released in order to keep pace with customers and release planes provide this.

So I say that we change our language to suit modern times. We take the best of existing processes and make them more agile, more responsive to business needs, while also linking into the security or compliance requirements that will always be there. The release plane delivers greater agility if those processes are set out in more detail, and are followed more strictly.

Why not come fly the friendly skies?

Published at DZone with permission of Daniel Ackerson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: