Having worked in various roles across the full spectrum of the development cycle, I find that one of the most frustrating challenges is
how do I maintain a repeatable deployment process? Can I be sure that what I deployed into our Integration Server, is the same thing that I deployed into our UAT, and production environments?
In past projects, I have experienced 100+ page installation guides with time consuming manual changes. For one project, we even resourced a full time deployment team just to deploy and maintain our daily builds.
Now let me introduce you to the wonderful world of Virtualization :) In my current role we have access to an ESX/VMWare/VSphere virtualized server environment. How does this help with repeatable deployment you may ask?
Imagine this...
1. Daily Build runs via Team Build:
-> Compiles, Unit Tests etc.
-> Produces MSIs
2. Before deployment:
-> Target Server reverts to (snapshot: base)
-> MSIs are deployed (via the Daily Build)
-> Target Server state is (snapshot: build)
-> Testing is conducted (reverting to states as required)
Tomorrow, this all happens again... You can revert to a previous build, or base build at any given time. Automated, repeatable and simple.
The way that we have chosen to snapshot our servers from the Daily build script is to write some
custom MSBuild Tasks which ultimately interact with the target virtual server. VMWare publish a number of APIs that you can use, including a command line tool called
VMRun.exe, however with this tool you need to know which physical host the guest is on and the name of the vhd, which for me kind of defeats the purpose of using a central management interface like VSphere.
We chose to use the
VMWare vi Server Web Service SDK, which is essentially a web service running on a Tomcat web server. This allows you to manage all of your virtual guests including snapshotting.
The VMWare SDK gives you a .Net solution written in C#, but simply following the build instructions only gets you half way there. [A word of warning: Don't simply add a web reference to the WSDL from your VSphere server. Whilst this may get you something that works, the performance of the generated proxy class is woeful! It took 4min to instantiate the proxy at runtime when I tried this. The SDK actually recognises this as a .Net serialization issue, and supplies a tool to optimize the generated proxy class].
For me, none of the batch files supplied worked out of the box and only seemed to support using VS2003 anyhow. At the end of the day what you need, is to generate your web service proxy class using the Optimization Tool supplied, otherwise it will run like a dog.
To get the VMWare SDK solution to build in VS2008:
1. Download and save the 2 WSDL files from your VSphere web server (afterall this is what you will be interacting with),
2. Run the Optimisation Tool supplied to generate your proxy classes,
3. Add these proxy classes to the solution and update any project references as required.
4. With a bit of commenting out, and removing projects that you will never use, you should be able to build the solution.
The projects that you need for snapshotting are AppUtil, VMSnapshot, and the Credential projects. When you build the VMSnapshot project you should end up with an executable VMSnapshot.exe and 4 assemblies (AppUtil, Credential, and the Proxy and it's serialization class).
VMSnapshot.exe should allow you to run snapshot related commands out of the box.
- list
- create
- revert
- remove
Once you have the command line tool, you can simply write a custom MSBuild Task to wrap around the executable. Add to your daily build and deploy script and enjoy!
