Ravello Ties Cloud Testing to Continuous Integration

One of the challenges with testing applications in the cloud is that it’s difficult to replicate the production environment where those applications will ultimately run. No matter how big the cloud is, the data center where those applications are tested usually bears little resemblance to the data center where the applications will actually end up running.

To help developers deal with this issue, Ravello Systems created an encapsulation technology that allows organizations to replicate their exact production environment inside a cloud testing service. This week, Ravello announced it is extending that capability to include an Apache Maven plug-in along with programming language bindings for Ruby and Python, and support for Continuous Integration systems such as Jenkins, Bamboo and TeamCity.

With one API call, developers can instantly supply provisions for a complete Clone of their existing on-premise production application. They can deploy it in the public cloud testing environment managed by Ravello and exposed via RESTful APIs, says Navin Thadani, Ravello's senior vice president of products. Thadani says each code commit can be tested on a clone of production in the cloud for instant and accurate feedback from within an integrated development environment.

The emulation technology that Ravello developed was created by the original developers of the Kernel-based Virtual Machine (KVM) software that Red Hat offers. The technology that underpins the Ravello service today is based on what the company describes as a Cloud Application Hypervisor, which allows an application to run on any virtual machine as an unmodified guest.

Application testing is among the foremost classes of workloads that enterprise IT organizations want to move to the cloud. Investing in IT infrastructure in support of application testing that is sporadic in nature is generally viewed as a waste of capital. Even then, most organizations can’t afford to create an exact replica of their production environment. The end result is a compromise: They make do with testing services in the cloud in the hope that specific infrastructure issues will not manifest themselves later. The trouble is that the production environment is getting more complex with each passing day. This makes it all the more likely that updates and patches will have to be applied after the application goes into production.

It’s usually 10 times more expensive to fix an application after it’s in production, which generally guarantees that applications are going to be both over budget and, just as worrisome, behind schedule.

Be sure to read the next News Services article: New Charts, Features Join the Google Visualization API