I just came across a piece that Bernard Golden wrote in his CIO blog entitled Dev/Test in the Cloud: Rules for Getting it Right . He makes a lot of good points including what we see the most successful enterprise development shops doing with the cloud; “Treat the cloud as an extension, not a separation.”
Unfortunately, he does not point out what dev/test tools should be put up in the cloud but simply states “dev/test tasks,” as if it is obvious which ones to migrate. Let’s see if we can leverage his work to figure which dev/test tasks are cloud-ready in two steps:
Step 1: Figure out what is NOT GOOD for the cloud. List your existing dev/test processes and cross things off that aren’t:
Mostly independent, or have clean dependencies on stuff that’s in your network but externally accessible
OK to upload (no security concerns or bandwidth constraints)
Run on plain vanilla x86 systems (today the cloud is the world of Windows and Linux)
Made with tools that you can run externally (watch for node-locked licenses, etc.)
Step 2: Of what is left, figure out what will get the most benefit from the cloud . In other words those that are slow, resource intensive, or bursty in compute demand.
Do you have anything left? Good! Most enterprises have critical development steps but not entire development workflows that can be wholesale lifted to the cloud. Great examples are; compiling sources, testing on several different operating systems, and scalability and load testing. This is why Mr. Golden was smart to point out that you should “Treat the cloud as an extension, not a separation.”
The remaining question is how can you effectively manage the process if it likely requires a combination of cloud, physical and virtual compute resources and the integration and orchestration of dozens of tools in your tool chain? Certainly this is enough to make a traditional development process held together by home-grown scripts and a hard working release team break under the pressure.
Lab manager applications do a great job of determining “where” something should be run but does not handle “what” should be run or manage the process of “how” the steps are completed. For this, check out ElectricCommander. We are helping some of the largest development enterprises in the world migrate the right dev/test steps to the cloud.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.