What does Release Management Mean To You?

Over last year, I have talked to customers, analysts and industry experts to determine what is the definition of Release Management and how it fits in the world of DevOps. I have noticed that there are two different perspectives on this.

Analysts include everything, from Development and QA to post deployment monitoring (Application Performance Management) to be part of the DevOps problem.

Enterprise IT however, has a different take on it. As of now, IT  practitioners in most organizations equate DevOps with Automation – Infrastructure and Application Release automation to be precise.

Based upon the feedback from enterprise IT, I developed an image  which shows the relationship between Release Management and other IT disciplines as they understand it.


The idea is that at its very core, the purpose of Release Management is to move software to a target environment – be it in your Datacenter or Cloud.

In doing so, Release interacts with Planning, Development, Testing, Ops/Deployment to collects status and track milestones.

To reiterate, DevOps means different things to different people but from Enterprise IT perspective I have found that most common definition includes deployment automation (App Release Automation) and Infrastructure Automation/Management.

I see that even though Deployment is somebody else’s problem, Release Management finds itself in the middle of deployment issues if the “handoff”  fails.

What do you think? Does your organization view Release the similar way?

When to consider PaaS in Enterprise IT

A few days ago I talked about the merits of Platform as a Service (PaaS) to help bridge the Dev and Ops divide.  However, PaaS adoption in Enterprise IT remains slow and faces several challenges – some perceived, some real.

Of perceived challenges, the most relevant is the one about security. A banking, insurance or health care IT does not allow hosting (and even developing) of applications in the Public Cloud – which is what the PaaS vendors offer as their primary service.

As a response, a number of these vendors have launched “Private” PaaS – where they offer their technology to enterprises and allow them to host it in their Private Cloud (read – infrastructure within IT’s firewall).

However, from those of us who have worked in Enterprise IT or are intimately connected with it, several challenges, including complexity of deployment, support for thousands of existing apps and problem of fragmented technology still remain. Lets take a look at each of these quickly and discuss alternatives or strategies to adopt the right Cloud for IT.

Complexity of Deployment

Using PaaS is quite simple but if you take the bits and deploy it on your own, the process becomes quite complex. You still have to download all the components, like a web server, app server, messaging service, database that the PaaS would use and wire it together using the PaaS  core that would manage the underlying infrastructure for you.  The process could be time consuming and difficult to manage. However, once you have invested time and resources on the initial setup, management is quite easy (unless you find bugs in the PaaS management components).

Support for Existing Apps

This is one of the thorniest issue that no PaaS provider is willing to talk about. IT organizations have thousands of applications and over 80% of dev time is spent fixing issues with these apps. Of the remaining 20%, most of the time is spent extending these apps and hardly 2-3% is dedicated to developing brand new apps from the scratch. That basically means that all the effort you’d put into PaaS would benefit only 2-3% of what you do. Is the investment really worth it?

Technology divide

Unless you are writing a web app using Ruby (Rails), Java (Spring, Scala) etc., PaaS is not very useful for you. There’s limited support for J2EE and .NET. App servers like Weblogic and Websphere are also not handled gracefully leaving you with a very narrow definition of what exactly is a “Platform”.


First alternative is what the PaaS vendors have been talking about. Adopt PaaS as is for the new web apps being built using modern frameworks like Scala and RoR.

If however, you’d still like to consider private PaaS, my suggestion is to wait. PaaS solutions are still maturing and while they do simplify management of app stack, they could be a hassle to deploy and upgrade and may not be worth the effort and cost at this time.

If you’d like to play with PaaS for some new, experimental development, I think there’s a better option. Adopt a more flexible IaaS option. AWS by itself has added a number of  PaaS like features under its “Elastic Beanstalk” service. With support for Java and .NET apps and auto-scaling features, I don’t think it is too much of a stretch to call it a PaaS. The most beautiful part of AWS EB service is it allows you to control how much or how little control you want over the app stack and where you want it to be available.

Mind you, you are still outside of your firewall but looking at the capabilities and simplicity that AWS brings to the table, I find it a much better solution for Enterprise IT.

Agility Vs. Rigor

Recently I came across two very different IT organizations. One, a cloud based software vendor that provides Payroll services to millions around the country and other an Insurance company.

You’d think that when it comes to software development and release  the software company would have more agile processes while the tradition financial company would focus more on rigor.

The reality is quite different.

Because they dealt with Payroll and each change could mean a direct financial impact on millions of users, this software company preferred rigor over agility – almost as much as any financial organization would.  The Release team recognized that even though the development had gone Agile they (the Release team) was still responsible for .making sure that the code goes through right gates before it is released for end users.

So the obvious question is – Do we have to choose between Agility and Rigor? Can’t we have both?

The answer is –  You CAN have both.  In some cases you even improve one by focusing on other.

Let me take an example of another IT organization, an Insurance company out of UK. With offshore and outsourced dev factories, the Release team was struggling with lost dev time as developers had to wait for days or hours for deployments to go through and testing to complete before they could fix issues and move to the next stage.

By adopting a deployment automation (Application Release Automation) solution, the release team accelerated their cycles several fold freeing up valuable QA resources who were previously engaged in deployment activities. These QA resources could now focus back on testing and bringing rigor to the release cycle – work they were hired to do in the first place.

In short – by accelerating their Release cycles and automating as much as they could, the release team was able to bring more rigor to their processes, eliminate dev downtime and improve overall quality of the release.

Is DevOps making Release Management Obsolete?

There’s a remarkable difference between those who work in Bay Area for one of the Cloud, Release or dare I say “DevOps” vendor and  those who live elsewhere and are employed by enterprise IT shops  at banks, healthcare, telecom companies.

Bay Area DevOps enthusiasts believe that the role of operations within Enterprise IT will be eliminated over next few years. Developers, they argue are writing scripts to deploy their code anyway. They could hand over the scripts to engineers on the ops side who could then deploy the code using these scripts and environment definitions that were delivered to them.

Open source tools from PuppetLabs and OpsCode have made the job of setting up environments quite prescriptive, if not exactly easy.

Deployment could be governed through in-house scripts or one of the ARA (Application Release Automation) tools offered by all major vendors, such as IBM, Serena, CA and a plethora of smaller companies.

Where’s the need for Release Management?

Not so fast, the folks on enterprise IT caution. You could turn your environment into code and automate all the deployments but anybody who has worked in a bank understands that when a major release rolls by, hundreds of applications get updated. How does automation govern the process of planning, developing, testing, delivering these thousands of changes? What about Audit and compliance requirements that financial institutions and health care providers must follow?

In short, automation allows you to get your app to the consumer faster but it does very little to protect you from legal complications that arise with each release cycle.

And that, I believe is the role of the Release Management team. They make sure that all engines including development, testing, deployment, environment management are humming in perfect synchronization with each other, avoid and resolve conflicts as they arise, make progress and challenges more visible and govern the process to ensure complete audit and compliance guidelines that their teams are required to follow.

How PaaS bridges the Dev-Ops divide

Platform-as-a-Service has many benefits including freeing the developer from having to worry about application architecture (middleware, db) complexities as well as worrying about capacity planning as app usage rises (or falls) over time.

There are other benefits that in a way could solve a few Release Management/DevOps problems.

Application deployment is incredibly easy with PaaS. A single line command in Heroku could push your code to the cloud.
$ git push heroku master
Really. It is that easy!
Building a repeatable deployment script is a child’s play!
If you like that, here’s something even better
Since PaaS is a complete stack with add-on services that developers use to write their code, PaaS adoption could help standardize environment across Dev and Ops! Once you have eliminated environment variance and automated deployments, you have created a solid ground to reduce Dev to Ops handoff and accelerated your release lifecycle.

IT is Dying. Long Live The IT

Analysts and some vendor have been proclaiming the death of the IT for at least a couple of years now. Their primary argument resides in the “cloud”.

The argument goes like this – With Developers adopting Agile and QA becoming more automated, the only barrier to moving code faster to production is IT (read Ops).  As business owners adopt more SaaS applications, Developers adopt PaaS and environments are maintained with IaaS (public or private), you wouldn’t need IT all.

Every single IT exec I have met looks at the argument above and shrugs his or her shoulders.  While every single Enterprise IT today has a Cloud initiative, it is crystal clear that core, strategic and business driver apps are not going to move to the cloud any time soon.

An Executive Director at one of nation’s premier Financial Services group summarized the challenge – “I manage the applications that are used for trading.  One wrong move, and the entire business (billions of dollars) could disappear overnight. To suggest that we will hand our applications or infrastructure over to a third party is just not realistic.

I believe everybody who comes from one of such companies could relate to that.

No matter how much automation and cheap and reliable cloud services are developed, IT is very much alive and kicking.

The reports of the death of IT have been greatly exaggerated.


Release rigor in the Cloud

With number of applications and development’s need to push changes out quickly rising, it is only natural that more and more work is done in the Cloud.

The process is simple. While an application is still in development, developers need freedom to act quickly and change environment as they see fit – both things you can’t do easily in corporate infrastructure.

However, the detractors of  (public) cloud claim that it is this flexibility that makes any development (or even testing) in the cloud useless when it comes to releasing the product in production, basically implying that the Release rigor cannot be applied when apps are developed in the Cloud.

I don’t think that’s true. Developers understand what makes their apps happy. Unless they are using PaaS from one of the vendors like EngineYard, Heroku or CloudFoundry, their cloud (IaaS) environment will reflect their in-house environment as closely as possible. They can use same scripts to setup their servers in the cloud.  Any changes to cloud environment can still be documented and new/updated scripts be sent to the QA/ops guys for verification. If approvals come through, the new deployment should go without a hitch.

Once an app is ready to be deployed in higher level environment (like UAT, pre-prod etc), regular Release lifecycle ensues.

Almost all enterprises (banks, retailers, healthcare and manufacturers) have cloud initiative underway and I don’t hear anybody saying that cloud adoption will impact Release rigor in a negative way.


Why should I care about the “Cloud”?

What is the #1 purported benefit of adopting a cloud service? If you listen to the cloud providers like Amazon, VMware, Google, Rackspace and others, it is the ability to spin up dev/test/prod environments within minutes instead of days or weeks.

From my experience , most IT practitioners have streamlined their processes and technology to deliver almost an on-demand service to their dev/test organizations. For companies such as Bank of America, Wells Fargo, American Express, Walmart, Macys, KP, McKesson, etc. “weeks” is just too long of a delay to set up an environment. My experience with some of these companies shows that they can stand up a new environment with 24 hour notice. Some can do it within a matter of minutes. 

Now we could argue that in this day and age 24 hours to spin up an environment is just unacceptable but I believe the right question is – “At what cost?”

For dime/hour, you can have an instance running on most major cloud providers. It sounds cheaper than what system admins within enterprise IT could offer but if you include the cost of time somebody spends installing right software and applications of the server and making sure it works with other (in-house) IT systems, the cost will be more than 10c/hour. Add security processes and integrations and the cost rises further.

However, the power of the cloud is that it has democratized IT. If central/shared IT service is bogged down in running the production systems, developers/testers have an option to jump to the cloud for next to nothing. As everybody gets comfortable with this, admins could better spend their time managing higher level environments (pre-prod, staging, prod) while lower level environments could be handed back to Developers and Testers.

There are other benefits of Cloud (PaaS, SaaS and IaaS) that we will discuss in later posts.


Why Cloud Of IT?

With hundreds, probably thousands of blogs clamoring for your attention, why Cloud of IT ?

Because Cloud of IT is different.  It focuses on key trends including Cloud Computing, Big Data, DevOps and Security from the perspective of the real Enterprise IT practitioners and executives. The sole purpose here is to help IT executives find relevant information – fast. 

Even more important will be the ability to ask questions and express your point of view so that the vendors and IT system providers understand what makes sense for you, people who actually deal with the challenges of keeping banks, retailers and health care providers up and running every day.