views:

104

answers:

2

I'm trying to establish a best practice for Virtual Machines for developers. Currently we work on Windows 7 with Visual Studio 2008. However, we need to experiment with VS2010 and to do this we create Win7 VM's and load what we want in there.

My technique is to create a new VM, in this case a Win7 VM, and once it's gone through all it's updates etc. take a copy of it for the next time I need the same type of VM. I used one copy to test in and then eventually abandon or delete it once I've made it unstable enough and go back and make a copy of the original. However, I find that there were lots of small utilities and enhancements that I'd made to the previous working VM that I had never installed in the virgin VM and have to install all of those again.

I'm looking for a best practice in using VM's for software development.

+1  A: 

Given that you aren't able to keep things ordered and have a list of enhacements (the ideal thing to do IMO), why not simply have two VMs, one where you work, and the other 'virgin'. Then, when you or anybody else does an enhancement on your work VM, it has to be replicated on the 'virgin' VM. Next time you or anybody else installs a new copy of the VM, after some iterations you'll have the 'perfect virgin version'.

Vinko Vrsalovic
That is the ideal approach, however, in reality, the virgin version never gets updated. It's a bit like most people's approach to comments in code or unit tests - they'll get back to that when they have time.
Guy
If you have enough machine to have both VMs on at the same time, it shouldn't even take much time.
Vinko Vrsalovic
Common practice is production, beta, and test snapshots. You do lots of work (that might get reverted or deleted) in test snapshots. When the work seems good, you put it in the beta snapshot and verify it. Only then do you promote beta to production. If your beta is a snapshot ahead on the production branch, you don't need to redo the work on the VM, just "promote" the snapshot.
Adisak
+3  A: 

VMWare has a great snapshot manager that lets you move non-destructively through a VM snapshots tree. You can take snapshot at point A and then advance the VM to point B (another snapshot), revert to A and advance to C (snapshot C). Then start a new sub-tree in a non-destructive manner at any of those points. You can also clone a VM and flatten multiple snapshots to a single snapshot as well as delete intermediate snapshots and prune branches on the tree.

It's very intelligent how it handles snapshots. I used Virtual Box when it only had linear destructive snapshot reversion -- I understand that VBox has improved but VMWare still has it beat for snapshot capabilities.

Also, if you're debugging in a VM, VMWare has extensions to record a VM's execution for debugging as well.

Adisak
How would this help to get the tweaks on the system if you forget to take snapshots after most tweaks? (every?)
Vinko Vrsalovic
@Vinko: No snapshot manager is going to help you if you forget to take snapshots. I don't know if there is an auto-snapshot feature or not on any VM, but even an auto-snapshot isn't going to take them at the exact points you want (or label them usefully).
Adisak
@Adisak: Exactly, but Guy in a comment to my answer says that the problem is that people will forget to do X (be it install it on the other VM or take a snapshot)
Vinko Vrsalovic
Do your experiments in a test branch that you *NEVER* export. Then keep a production branch. You can make as many beta snapshots as you want in the production trying out stuff from your test branch. When you are happy with a beta and it's fully tested, promote that to your production version but keep around earlier snapshots for the production as well.
Adisak