CloudShare like many of our customers, is software. And as all you developers know, developing, debugging, and testing software has many parts. Because we are in the same boat as you, it would make sense for us to “eat our own dog food”, and use CloudShare to develop CloudShare.
The CloudShare QA organization specifically runs API and UI-based automation throughout the week. To do this we deployed a pair of Windows environments in the CloudShare Production site that, over VPN, gives us access to local file servers (for writing results) and version control (git). This has allowed us to free up local test hardware and gain access to CloudShare’s cloud-based hosting. You will be amazed at the amount of space saved from physical QA boxes. Testing over our own service is our way of “eating our own dogfood”.
We access our automation environments on CloudShare using RDP, which we connect to using the CloudShare interface and built-in web viewing technology. We debug failed tests, check-in code and build/deploy local test builds as part of the QA effort. Access into our environments is very snappy even though our offices are in Israel and Production runs in the U.S. (Florida). In addition, we are able to execute tests directly using the CloudShare API which lets us run any scripts within the CloudShare environments (in our case batch files).
Using CloudShare to Host CloudShare Automation
The setup we have in Production uses the features available with Team Labs as well as the upcoming general support for Shared environments, which in our case consists of a VPN server providing network access to all machines within the same project.
Aside from the short downtime during our bi-weekly Sunday deployments, our CloudShare environments have allowed us to replace all local environments we used in testing our product for performing UI-based testing.
Happy CloudSharing!
