Click here to Skip to main content
15,113,086 members
Articles / Programming Languages / C++
Technical Blog
Posted 3 Mar 2015

Tagged as

Stats

8.5K views
2 bookmarked

Continuous Delivery with TFS: Making Sense of the DSC Feature in Release Management

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
3 Mar 2015CPOL2 min read
Making Sense of the DSC Feature in Release Management

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Graham D Smith
United Kingdom United Kingdom
Dr Graham Smith is a former research scientist who got bitten by the programming and database bug so badly that in 2000 he changed careers to become a full-time software developer. Life moves on and Graham currently manages a team of software engineers and specialises in continuous delivery and application lifecycle management with the Team Foundation Server ecosystem.

Comments and Discussions

 
-- There are no messages in this forum --