Wednesday, April 18, 2012

Is Agile Deployment an oxymoron?

One must say that considering the amount of planning, rigidity and inertia involved, agile is not the first adjective that comes to mind when talking about software deployment. Yet, software development processes have evolved so much in the last few years, gaining in responsiveness and productivity, so why should software deployment not be able to keep up? So much emphasis is put on software development yet, consider the first principle of the Agile ManifestoCustomer satisfaction by rapid delivery of useful software.

Many organizations completely miss the point by interpreting "delivery" as ready to ship and patting each other's backs upon achieving that goal. I don't mean to snicker at the benefits of agile development but there's more to customer satisfaction than producing useful software. If it takes weeks before the software is live in production then what's in it for the customer?

Agile deployment is all about closing the last mile in the SDLC in order to deliver on the agile promise. It's pretty obvious so why are we even talking about it? After all, software deployment is no rocket science. Well, much of the slowness in software delivery results from the tedious manual configuration operations where the risks of making mistakes or oversights remains equal regardless of the level of changes in the software, coupled with the customer pressure to avoid service disruption. That tension between service continuity and enhancement delivery is a major cause of disconnect between R&D and operations. Automation is the essential pre-requisite to software upgrades reliability and repeatability.

Let me backtrack a bit here; the reliability of software upgrade delivery is affected by deployment and configuration errors but obviously mostly depends on software quality. While individual components are usually properly validated by unit testing, integration testing is too often relegated at the end of the development cycle. Because development teams mistakenly consider that deployment is entirely up to operations, even integration testing environments are often managed outside R&D because developers feel it is a waste of their time to keep up with all the intricacies and the tediousness of the installation process.

Software developers must be the first to practice what they preach by setting up the toolchain that enable rapid delivery of useful software for their own purposes and thereby enhance their agile development processes. Beyond these internal benefits, promoting the usage of similar deployment automation to operation and support teams also indirectly benefits R&D as they also eliminate a large chunk of internal support issues that end up winding on their own desk.

In the following article of the series we'll look at specific characteristics of agile deployment tools and how they differ from traditional infrastructure management systems.

No comments:

Post a Comment