Patching and Testing in the Cloud
Curator's Note: The content of this article was originally written by Raman Chawla over at the Cloud Velocity blog.
Application development, bug fixing, testing and patching the OS on which the application is running are routine tasks for a developer. But, this process could get very involved, as often this requires the same development environment as in the staging/ production. This translates into a hunt for getting access to additional systems or a request to IT to provide additional resources for development and testing before the patch that a developer has worked on is tested and deployed on to the production systems. A developer would rather not go through these hoops to get the resources he or she needs. He would prefer to have access to unlimited resources and would like to have tools that would make his development or deployment environment available on demand, so that he can concentrate on more productive tasks to enhance and extend the application that he has built.
At CloudVelocity, we have developed a cloud migration and cloning service that provides the functionality that as a developer, I could use anytime to extend my setup inside the enterprise into Amazon’s public cloud (AWS) – essentially, seamlessly set up a hybrid cloud. The cloning service allows a developer to clone multi-system application clusters into the AWS cloud. The Cloud Cloning service clones your systems, physical or virtual, into the AWS cloud – it not only clones the application and app data, but also clones the underlying OS, libraries and binaries needed to run the application seamlessly. I will provide detailed step-by-step instructions on how to do this in my next post.
I invite and encourage all developers and QA engineers to try out our cloud devtest free trial and see for yourself how this service can help replicate your setup and related services into the AWS cloud and let you focus on more critical tasks and not to get bogged down with Infrastructure requirement related issues.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)