December 6, 2012 Update: The virtual machine and corresponding hands-on-labs / demo scripts have been upgraded to use Visual Studio 2012 Update 1. You can download them from here.
Now that Visual Studio 2012 Update 1 is available, several people have asked whether or not I am updating my ALM virtual machine. The answer is yes – and it will be available by sometime next week. Watch my blog for details. There are some really nice improvements in Update 1 that I think developers, architects, project managers and testers alike will enjoy.
A longer question I have also been asked is whether or not Update 1 can be installed by end-users into my virtual machine. The answer is “not really” (unless you want to jump through some workaround steps). The reason for this requires a bit longer of an explanation.
If you have worked with my virtual machine you may have noticed that every time you boot it up, the date and time jumps to May 16, 2012. The reason for this is that in order to show a pseudo-realistic example of how Team Foundation Server can be used to support an actual development team, we need to pin the system date to a specific day in the middle of an iteration. If we didn’t do this, then the VM might look great on the day I shipped it, but if you downloaded it a month later the data is going to start to look stale. You’ll be in some future iteration with no recent work item activity, a flat burndown chart, etc., sort of like any good post-apocalyptic zombie movie where life and routine as we know it stopped months ago.
Setting your operating system to an older date and time is of course a “hack” that you should never use on your actual Team Foundation Server instance, but since my virtual machine is for training and evaluation purposes I have taken this (and a few other) liberties where necessary to optimize the virtual machine for those experiences.
One implication of this hack is that after you boot the virtual machine and start working with Team Foundation Server you should never reboot the virtual machine. If you do, then the operating system will reboot into the morning of May 16, 2012, and Team Foundation Server will get confused since you will be going “back in time” – something that Team Foundation Server is simply not designed to support. Instead, I always suggest that users take a Hyper-V snapshot of my virtual machine after they boot it up for the first time but before they start working with it so that they can always roll back to a known clean state in case they make a mistake or simply want to repeat a scenario (which is what I do routinely when I am demonstrating Team Foundation Server at conferences and customer meetings).
Which brings us to Visual Studio 2012 Update 1. If you try installing Update 1 into my virtual machine you will notice that you are prompted to reboot during the installation process. While you won’t receive any errors or warnings during the setup/upgrade process, if you attempt this you will start to notice problems later on – especially in web access. This is because you are going back in time every time you reboot.
I know a few people were burned by this and I’m sorry for the time you may have wasted going down this path. Generally speaking, I always tell people that the virtual machine was built specifically to support the nearly two dozen hands-on-labs / demo scripts which go along with it. While you are welcome to use it for other purposes, your mileage may vary, and this is a good example of something which just won’t work.
One workaround if you really want to install Update 1 yourself into my virtual machine would be to go into the Task Scheduler and disable the task which configures the date and time to May 16, 2012. After you disable this you can run Update 1 as expected, but keep in mind that the project management data will no longer look accurate since you will be many months ahead of when it was designed for. Or, you can wait a week until I publish an official version.
Thanks for reading and as always for all of the feedback.
Brian can you give details on the "few other liberties". I'm tasked with creating training VMs for Microsoft development technologies like TFS for our internal development teams and I'm wondering if you have any best practices we should be following?
I should have known that question was coming. :-)
Nothing too major. Some examples off the top of my head include that UAC is disabled, all users are Administrators, Windows Update is disabled (but I recommend always running the VM offline so it shouldn't be a security risk even if the updates go stale), that sort of thing. Also, most work items only contain enough detail to support the hands-on-labs / demo scripts. You won't see detailed descriptions for instance, although that sort of information would usually be vital for a real developer to understand what they need to dev.
Thanks Brian. Any chance when you release your new VM it will be based on SRV 2012 and SQL 2012?
Not this time, no. I had considered it, but I need to use SP2010 use for some of the Update 1 scenarios and SP2010 is currently not supported on WS2012.
When SP2 for SharePoint 2010 is released maybe we'll get it on WS2012
Maybe by that time we'll be asking for SP2013 ;)
Does the build controller work in the new VSALM or does it still think its on the old VM?
The build controller should work now.
Any chance we can get the virtual machine without the update ? I'm concern about when the updated one will be available (I'd be very gratefull to have a version for Friday)
Thanks in advance.
Julien, it's live now: http://aka.ms/vs11almvm
I've been playing around with these ALM VMs for awhile for our training purposes and it'd be really nice if the data in the TFS Work items was more representative of real world data. The fact that the work items and test cases are so weak it makes it harder to show my TFS users these demos without having to constantly caveat the labs. It would also be nice if the Team Builds had real data show code changes and work items opened and closed between builds. Again nice job...but please round out the work items and spend the time filling out the scenarios. It takes forever too download and set these up for our users so I appreciate the work that's gone into creating them...it just feels like you've covered 90% but left out the best 10%.
Sam, thanks for the nice words and constructive feedback. It's certainly worth considering. I have steered away from using "real" user stories / test case definitions simply because it's a religious topic (there are lots of opinions on the "right" way to write these) and that's not something that the VM is designed to teach. Part of the beauty of TFS is that it lends itself to letting teams work in a style that suits them, so where it's not required to get prescriptive, I have tried to avoid doing so for fear of sending a message that this is "the way" to use TFS.
Richer check-in data would certainly be nice. I have to figure out how much work that would be, though. To be honest, having to maintain these VMs and labs with every quarterly update that Visual Studio / Team Foundation Server is shipping now is proving to be a lot of work. :-)