We Use Private Integration Labs – You Should Too!

By Danielle Arad - February 11, 2014
2 min read

At CloudShare we are working agile. Every 2 weeks we have a new version deployed to production. One of the advantages of such short iteration is the ability to get very early feedback from customers or from our customer facing colleagues.

However, we sometime want to get this feedback before the version is deployed. Our developers want to get validation from the product manager before QA start to run their tests. Or sometime we even want that of our customer facing persons will discuss a specific feature or UI with the customer itself, before the feature is done.

The traditional method to address these needs is by using screenshots from the developer local machine, or by tedious documentation of ‘how exactly the feature’ is going to be look like.

A more accurate and easy to use approach might be to deploy the new (incomplete) feature / UI to an integration lab where the product manager can access it and review it before it goes to production or even before the development is done.

Well, screenshot and documentation are clearly not the best way to demonstrate a feature in a web application. Using an integration lab is much better and this is what most modern organization are doing.

However, this method has it is owned flows. The integration lab is usually shared between different stock holders: QA , developers, or an IT person (who is ‘just checking the new splunk service in the backend, it will take me a minute (or a day)’.)

Definitely not ideal, and if there is a customer involved then it is not even considered as an option.

At CloudShare we solved this pain by using our own platform: “CloudShare TeamLabs” for Private Integration labs. As I wrote in the past, we have a project in our TeamLabs account called “CloudShare – DogFood”.

This project contains several blueprints, each representing another dev environment configuration. Each PM or customer facing personnel has its own environment in this project, which can be considered his own Private Lab. And he can use this private lab to examine and even demonstrate features that are in development phase.

For example when our Product Team wants to demonstrate the new UI for a prospect or a customer, he/she simply access a private CloudShare lab, checkout the correct branch in the Git that is installed in his environment already and he can access his own private instance of CloudShare web service. Using HTTP access or the web VM FQDN, he can access it directly through his browser from anywhere. Then he can demonstrate or examine the new features or the new UI capabilities, before they are deployed to production. Maybe before QA had finished testing them, or maybe even before the feature is done.

Having integration labs opens the doors for use to be even more efficient with our releases, and most importantly opportunistic as each developer has their own instance to test new and forward thinking features and code they could not previously.