Release Management Update 3 CTP1 introduces support to PowerShell Desired State Configuration to deploy applications in your environments – this is utterly cool, but…why?
Before looking at VSRM itself, I think a bit of introduction to DSC is needed.
PowerShell Desired State Configuration is a new management platform built-in in Windows and based on, guess what, PowerShell. It can do a bunch of useful tasks, which I leave to the documentation because I just want to dig into the core concepts.
As it is built-in in Windows, it is agentless. Well actually the agent is inside PowerShell and Windows Management Framework, but for our purpose (deployments) we can consider whatever system running PowerShell 4.0+ (so Windows Server 2008 R2 and above, just by installing PS 4.0 and WMF 4.0) a DSC-capable system.
All of that goodness relies on a keyword – Configuration. If you set a Configuration block at the beginning of the script, you are invoking DSC.
DSC uses a .mof file which is created by the script itself, so after creating and running the script you just need to call Start-DscConfiguration with the appropriate parameters.
Let’s see a code snippet, it is very easy to use
Ensure = "Present"
Name = "Net-Framework-Core"
Ensure = "Present"
Name = "Net-Framework-45-Core"
Here it is. The Configuration block is called InstallFX35_45 – it will check for the .NET Frameworks 3.5 and 4.5 on the target servers (or on just localhost if not specified) and, if any of them are not present at runtime, it would automatically trigger the installation of what’s missing via Install-WindowsFeature.
We just have to launch it, to get the .mof file, and invoking Start-DscConfiguration:
InstallFX35_45 -servers "PTFSDT", "PTFSAT"
Start-DscConfiguration -Wait -Verbose -Path .\InstallFX35_45
Everything is handled by the OS – so what we should care about is the whole configuration, nothing else. This specific solution addresses almost all the needs we might face in a DevOps environment – and in a very robust way!
DSC scripts are idempotent – so you can reapply a change and get to your desired state (hence the name…) regardless of the current status. No complex logic for catching exceptions or incremental changes – all is handled by the underlying infrastructure.
You can use DSC for installing roles, services, interacting with IIS, copying files…all from PowerShell, and in a completely reproducible environment.
The PowerShell team released a very handy Resource Kit, to get started with DSC and, eventually, DevOps – you can download it here.