When I first started listing the draft titles of blog posts for my series on implementing continuous delivery with TFS, naturally the vNext / Agent-less / PowerShell DSC feature of Release Management that shipped with 2013.3 was on my list. And why not? Surely, this was the successor to the agent-based way of doing things? Out with the old and in with the new…
Naturally, I’d looked into PowerShell DSC and knew that it was touted as a make-it-so technology for configuring Windows servers: rather than using an imperative script to install and configure components, one uses a declarative approach that describes what a server should look like and PowerShell DSC goes off and does one’s bidding, so to speak. It wasn’t immediately obvious how the new vNext features of Release Management would relate to the delivery pipeline I was building in Azure but I trusted that time would tell. Well, time has now told and as far as my research is concerned, I can’t see that the vNext features have any part to play. Deploying a DACPAC? Running automated tests via Microsoft Test Manager? The vNext features appear to be irrelevant.
Interestingly, I’m not the only one who has come to the conclusion that vNext is not a must-do replacement for agent-based deployments. Both Colin Dembovsky and Donovan Brown have recently blogged on similar lines. So, what is the point of the vNext features in Release Management? Clearly, if you want to ensure that your environment is configured correctly before you deploy your components then a vNext release template might be the way to go. But most organisations are probably (or should be) thinking about automating the configuration of their servers at a higher, more global level, not just when it comes to triggering an actual deployment. Certainly, at the time of writing this post, I think I’m right in saying that if you want to use Release Management with Visual Studio Online, you have to use a vNext release template, but this just feels like Microsoft haven’t implemented using agent-based release templates yet.
Although I’m planning to cover PowerShell DSC in a different blog post series as far as this series is concerned, I’m not going to complicate things by covering the vNext way of implementing releases as it feels like it won’t add much value and will be entering a world of unnecessary rework and pain. Disagree? Sound off in the comments…
Cheers – Graham
The post Continuous Delivery with TFS: Making Sense of the DSC Feature in Release Management appeared first on Please Release Me.
