I’ve been coding a web project using Aurelia for the last couple of weeks (more posts about what I’m actually doing to follow soon!). Aurelia is an amazing SPA framework invented by Rob Eisenberg (@EisenbergEffect).

A couple of months ago I did a series of posts (this one has the summary of all my RM/DSC posts) about using PowerShell DSC in Release Management. I set out to see if I could create a DSC script that RM could invoke that would prep the environment and install the application. I managed to get it going, but never felt particularly good about the final solution – it always felt a little bit hacky. Not the entire solution per se – really just the application bit.

We’ve got some TypeScript models for our web frontend. If you’re doing any enterprise JavaScript development, then TypeScript is a must. It’s much more maintainable and even gives you some compile-time checking.

I’m back to doing some dev again – for a real-life, going-to-charge-for application! It’s great to be based from home again and to be on some very cutting edge dev.

This morning I went to check on my blog – the very blog you’re busy reading – and I was greeted with a dreaded YSOD (Yellow Screen of Death). What? That can’t be! I haven’t deployed anything since about 10 days ago, so I know it wasn’t my code! What gives?

In my previous post I showed you how to use PowerShell DSC and Release Management to configure machines and deploy an application. There was one part of the solution that I wasn’t satisfied with, and in the comments section you’ll see that @BigFan picks it up: the configuration is hard-coded.

A few months ago Release Management (RM) Update 3 preview was released. One of the big features in that release was the ability to deploy without agents using PowerShell DSC. Once I saw this feature, I started a journey to see how far I could take deployments using this amazing technology. I had to learn how DSC worked, and from there I had to figure out how to use DSC with RM! The ride was a bit rocky at first, but I feel comfortable with what I am able to do using RM with PowerShell DSC.

Jim Lamb wrote a post about how to use a custom activity to match the compiled versions of your assemblies to the TFS build number. This was not a trivial exercise (since you have to edit the workflow itself) but is the best solution for this sort of operation. Interestingly the post was written in November 2009 and updated for TFS 2010 RTM in February 2010.

Update 4 RC for Release Management was released a few days ago. There are some good improvements – some are minor, like the introduction of “Agent-based” labels improves readability for viewing agent-based vs non-agent based templates and components. Others are quite significant – like being able to use the Manual Intervention activity and tags in vNext templates, being able to use server-drops as release source and others. By far my favorite new feature of the update is the new variable capabilities.