I got an email yesterday from some cloud vendors offering a seminar on "Why you should move dev and test to the cloud."  The two vendors specifically suggested moving them to the cloud even if you weren't deployed to the cloud. For our cloud customers, I have been advocating this for quite a while, but I would never suggest moving test, and to a lesser degree, dev to the cloud if your deployment platform wasn't the cloud.  My disagreement is based on the importance that I put on keeping your live site or other service up and running.

The real recommendation I have, based on our experience supporting our customers, is that your dev and test environments should be as much like production as possible (with any obvious required differences such as different levels of access control.)   So, if you're deployed to cloud, you should test in an identical cloud environment.  If in colo, you should test in an identical colo environment.  That way, any environment-dependent problems will surface during test, instead of during deployment.  And we find that more than 50% of the failed deployments that our customers have are the result of having a difference in their environments, whether it's a different PHP config file, different memory size, or different set of libraries on the systems.    This applies to development as well.

Yes, the cloud offers some great advantages for "disposable infrastructure," letting you set up and destroy test or dev environments at your leisure.  But if their use leads to a bad deployment and downtime, any advantages of cloud dev or test are lost.    The nice thing about our AppLogic-based cloud or PrimaCloud is that you can copy an entire virtual datacenter from your production environment and make it your test or dev environment very easily.

All of this ease of creating and destroying infrastructure doesn't eliminate the need for good process.  Do you have configuration management and version control tools in place?   Do you have a process with approvals for releasing from dev to test?   How about from test to your production environment.  How do you decide how much testing is enough, and of what type?  What process is in place if you discover critical bugs after release? Can you roll back your production environment easily?   The cloud facilitates answering these questions, but as you can surmise, it doesn't answer them!  

Comments (3)

Subscribe to this comment's feed

Show/Hide comments

bespoke software: Keep up the good work, http://www.geeks.ltd.uk/Services.html

Quite inspiring,



Thanks for bringing this up

1

December 14, 2009

ENovikoff: The obvious question...

from reading your comment is, "why don't you have your production system in a virtualized environment?" There are really very few applications these days - except for some canned software that has licensing problems - that wouldn't benefit from a highly available virtualized deployment. In the case of our Computing Utility and PrimaCloud products, both are self-healing as a consequence of virtualization, which reduces the risk of unplanned downtime.

2

November 22, 2009

shankar: cto http://www.aspiresys.com

Completely agree with this. This is one of our producteering practices that we preach to our development and testing teams as well. It is extremely important to test your product on a similar environment which is as close as possible to real production environment. In fact, sometimes, we have challenges using virtualized servers for testing purposes as the CPU utilization, memory usage, etc. does not reflect a production server environment.

3

November 22, 2009

 Show/Hide comment form

Name

Email

Website

Title

Comment

Write the displayed characters

Add Comment