The curse of updating the IDE

A frantic Monday search for the cause and cure was followed by a patch on Tuesday to fix a problem that obviously hadn’t cropped up in testing. No matter how good your testing is, you’ll always find that real, live users will do some things slightly differently from the way the testers did.

The curse of updating the IDE

Development process updates

Until now, our source control and development process tracking has been housed on Microsoft’s Team Foundation Server 2008 (TFS), although some projects that are still active had even started life on TFS2005.

While we’ve been reasonably happy with these project management tools, the development process flow software was definitely showing its age. Microsoft’s MSF Agile template from TFS2005 was a little clunky and inflexible. TFS2008 improved matters somewhat, but we hadn’t bitten the bullet to upgrade several large projects. We even had the source code for a myriad of small projects still sitting in a Visual SourceSafe repository.

We shut down early on the Friday, pushed all that SourceSafe code into TFS2008, then backed up the TFS database and upgraded our server to TFS2010, and backed up the database again. Our TFS server was a virtual machine still running Windows Server 2003, so we then provisioned a new virtual server running Windows Server 2008 R2, installed TFS2010 onto that and restored the database from the previous server onto the new one. By Monday morning we had all our VSS and TFS2008 projects on a brand-new TFS2010 server.

There are lots of ways this process can go wrong, but we had to backtrack seriously only once, when we got the installation order of components wrong and couldn’t recover. We’d planned for such a mishap and were taking backups of the virtual hard disk (VHD) file for the virtual server after every single installation or upgrade.

That’s one of the great things about virtualisation – a backup is a five-minute job, not a five-hour on

That’s one of the great things about virtualisation – a backup is a five-minute job, not a five-hour one. The other major benefit was the ability to provision the new virtual server and transfer data to it before decommissioning the old virtual server, without having to buy any new hardware.

The physical hardware these virtual servers were running on had plenty of spare capacity but, were it to get a bit tight it would be easy to temporarily decrease the number of virtual processors or the amount of virtual memory allocated to any of the virtual machines, while you still needed both old and new virtual machines running together. Just remember to restore those allocations once the old machine is finally decommissioned.

For the old projects we’d had since TFS2005, we created new MSF Agile 5 projects and moved the source files into the new project so we could take advantage of its new features.

MSF Agile 5 projects are quite like Scrum projects and follow similar principles, capturing requirements as User Stories that are broken down into smaller and smaller sub-stories until you can define a set of tasks needed to implement that function and the tests needed to confirm it works.

All these stories are written from the user’s perspective and usually start from the template “As a I want so that ”. This structure can help you think about security and the reasons behind the goal/requirements and so avoid writing “how to code this feature” too early in the development cycle.

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.

Todays Highlights
How to See Google Search History
how to download photos from google photos