Should we create Virtual Machine environment so a consultant can develop in similiar environment?

Question

This is a large project and currently there are only 3 developers working on it. We have some money in the budget to contract development help from a software consulting firm. However, because the location of our business it would be beneficial if the consultant could do their development off-site. Also, our company policy doesn't allow contract help to VPN into our network, so that is not an option.

My question is, would it be a good idea to create a Virtual Machine that copies our internal environment (particularly our database and WCF service) and give the consultant the Virtual Machine image so that they can replicate the environment at their place of work?

I haven't worked much with Virtual Machines, so I'm not sure if this is a good idea or if there are huge obstacles that I'm not thinking of.

If anyone has ever done anything like this, it would be great to hear the pros/cons. Any help would be appreciated.

Answer 1

Considering your limitations of not being able to use a VPN, virtualization sounds ideal. That way you can set up the environment, and give it to the consultant. There is no question about what he set up is correct, and he isn't going to be charging you a large amount of money for him to set up his working environment.

Answer 2

It's a great solution given the restrictions that you have in place in terms of access.

The downsides to this are considerable though, and should be taken into account. The most immediate one is that neither side will be able to see the updates that the other one is making. If the volatility level is high on both sides (or just one), then you run the risk of wasting the effort of either or both of the sides because they are out of sync with each other.

This can be overcome, but it will involve a tremendous amount of work to remain in sync.

A better solution would be to have your SCM exposed securely outside of your network, and then give the consultant rights to only certain branches of code (or as you see fit). This will allow him to develop concurrently with you (instead of completely separated) and still be limited from doing too much damage (given the restrictions you place on him).

Answer 3

I've done this.

Upside is that you can duplicate the build environment and the tools. We do something like that here to standardize the development environments for our devs.

I've done the VMWare type development for another company before and it was darn convenient to get an image from them and be up and running right away.

Keeping code changes in sync can be accomplished if they can get (restricted) access to your codebase, perhaps via a VPN but you mentioned they can't - I couldn't either. Typically in my situation, I collected up my diffs from the provided baseline and provided them back to the folks I was working with as they had no VPN. A little tedious, but it worked OK since the work we were all doing was neatly separated.

I utilized SVN on my end to keep track of changes I made. Not as good as having VPN but it allowed me to keep things straight. The burden was on them to merge my changes back into their tree. Then I'd get an update from them. Not ideal but it worked.

Answer 4

My teams have had good experiences with both Virtual PC and VMWare. On the positive side, we were able to configure the Virtual Machine EXACTLY as we needed. Once you have an established Virtual Machine but before you do any development, save that file to a different location. If anyone on the team needs to do a "restart", you have an image that you know works as intended. You can also use it to clone as many VMs as you need.

Once you're ready to send the VM file to your consultant, there are a few ways to get it to them. Some teams post the file to a public site and sent a link to download it. My team ran into issues and concerns with this (it was a large file and the concerns were around securing the link so only authorized persons could download it), so we put it on a flash drive and sent it by certified mail.

A few considerations.

First is Source Control. Since you said your consultants won't be able to establish a VPN connection, you will need to design your project and assign tasks in a way that means there is NO overlap between your work and their. Establish your contracts (Interfaces, Services, etc) as early as possibly and Breaking Changes to the contracts is an Event that gets communicated to the whole team.

Second, it also means that the full burden of integration testing falls on your in-house developers shoulders. I recommend doing that early and often, because once the contract is up with the consultants, you cannot rely on being able to contact them again.

Third is Licensing. The Virtual Machine is another machine as far as your vendors are concerned. Some vendors account for this and other's don't, so you'll need to check the licensing on each component. This includes the Operating System, Database, Libraries, IDE, etc.

Fourth is Computer Names. Each Virtual Machine is treated as a machine on the network as well. If you clone the VM image, each one will have the same machine name and will confuse the network. In our case, the router thought it was under a DDoS attack and shut itself down. Each VM solution has its own way of resolving this, so I'll stop there. This will affect your in-house developers more than the offsite folks.