I was working at a customer that had set up a test TFS environment. When we set up their “real” TFS, they did a get-latest of their code and imported their code – easy enough. They did have about 100 active work items that they also wanted to migrate. Not being a big fan of TFS Integration Platform, I usually recommend using Excel to port work items en masse.

I’m well into my journey of discovering the capabilities of PowerShell DSC and Release Management’s DSC feature (See my previous posts: PowerShell DSC: Configuring a Remote Node to “Reboot If Needed”, Using PowerShell DSC in Release Management: The Hidden Manual and More DSC Release Management Goodness: Readying a Webserver for Deployment). I’ve managed to work out how to use Release Management to run DSC scripts on nodes. Now I am trying to construct a couple of scripts that I can use to deploy applications to servers – including, of course, configuring the servers – using DSC. (All scripts for this post are available for download here).

In my previous couple of posts (PowerShell DSC: Configuring a Remote Node to “RebootIfNeeded” and Using PowerShell DSC in Release Management: The Hidden Manual) I started to experiment with Release Management’s new PowerShell DSC capabilities. I’ve been getting some great help from Bishal Prasad, one of the developers on Release Management – without his help I’d never have gotten this far!

Just in case you missed it, Release Management Update 3 CTP now supports deploying using PowerShell DSC. I think this is a great feature and adds to the impressive toolset that Microsoft is putting out into the DevOps area. So I decided to take this feature for a spin!

I’ve started to experiment a bit with some PowerShell DSC – mostly because it’s now supported in Release Management (in Update 3 CTP at least).

We’ve been working on a rewrite of our Timetracking tool (formerly Notion Timesheet) and it’s going live today – Imaginet Timesheet! Timesheet lets you log time against TFS work items using a web interface. The web site can be installed on any IIS server (if you want to host it on-premises) or even onto Windows Azure Web Sites (WAWS) if you have a public-facing TFS or are using Visual Studio Online. Once you’ve installed it, just log in, select a date-range (week) and a query and start logging time.

In a previous post I wrote about how to do JavaScript unit testing in VS 2012. The same procedure applies to VS 2013 – but the Chutzpah test adapter now allows you to run code coverage too. At the end of my post I link to another blog entry about how to enable the tests to run during team builds.

Last week I updated my blog engine from Blogger to MiniBlog. The last couple of days I’ve been updating the theme and style. Every good blog needs some good bling!

I have been using Blogger ever since I started my blog back in 2010. Once you get the template right (and set up a domain) it’s not a bad hosting platform. It works nicely with Windows Live Writer (as every self-respecting blog engine should). However, I felt it was time for a change – I wanted to take charge of my own blogging platform.

I love WebDeploy – I have ever since I read Scott Hanselman’s post “Web Deploy Made Awesome: If You’re Using XCopy, You’re Doing It Wrong”. Whenever I’m helping teams that build web applications improve their ALM processes, invariable I end up moving them onto Web Deploy. Not only is it an easier and cleaner way to deploy, but you get the bonus of being able to manage configuration files (Web.config) in your project.