(Last updated in 2018)
In the CloudShare dev group, we occasionally work with an outside consultant or contractor.
One of the most annoying pains when hiring a developer contractor is the need to provide him with a development environment. The consultant usually wants to work on his laptop in his office / home and needs a development environment immediately. Besides, as opposed to an in-house developer, there is no real value in letting him install and configure his own developer station.
A typical web developer environment in Cloudshare might contain an IIS server with special configuration and sites and application pools, SQL server, Redis instance, Visual Studio 2012, Git with several repositories configured and more.
The problem becomes even more painful when hiring a consulting company, not just an individual, at which point you need to provide developer environments to several sub contractors. Sometimes they will work on it for only several days before passing it forward to another sub-contractor. And it’s critical that the environments are uniform with standard configurations.
There is also the problem of connecting them to our Git server and allowing them a way to work on the most updated code. Some of the contractors might not be familiar with Git and in a short engagement we don’t want to waste time on Git training and tutoring on our agile development methodologies .
How do we solve it? We use CloudShare TeamLabs of course! We have a project in our TeamLabs account called “CloudShare – [ProjectName]” .
This project contains several blueprints, each representing another dev environment configuration. A blueprint is like a library of muti-machine environments with the exact OS, software, networking, running state, and configurations we require for the contracts, like stated above.
In each blueprint we keep several snapshots that capture the chronological code progress (e.g., code versions). Environments created from these snapshots are connected via shared environment and VPN to our Git server and hence allow the developer to pull and push while working on his environment. This allows us to use a hybrid-cloud scenario where our TeamLabs environments can consume resources from our on-premise ones.
Using our CloudShare development environment on top of the Cloudshare platform makes it very simple to provide any developer (internal or external) with a fully configured dev environment. Simply add this person as a user to the CloudShare dev, or create a new project to separate different groups of developers. This developer will get an invitation to the project and will be able to provision an environment for herself with the needed policy.
When considering web development, another key feature allows an even better experience. While the work itself during the coding and debugging is done via remote access the web developer, tester or a product manager will usually want to see the final result directly and not through remote access. This is relevant especially for UI development where exact colors, fading effects, and responsiveness varies between direct browser experience and RDP experience. To solve this problem we use Cloudshare “Web Access” capability. Cloudshare enables us to connect through http to the IIS in the environment by simply clicking on the “WebAccess” button.
Because we started using TeamLabs we have better control of the infrastructure used by our contractors. Less variables to chase down when we move to production. And save a TON of time dealing with infrastructure that was just a tedious and wasted task.