After the brief introduction earlier this month it is now time to push forward – let’s see how the Update 3 CTP of Visual Studio Release Management enables you to push your DSC scripts to the target machines.
Firstly, the script. To keep things simple, I decided to deploy my script in an independent build and then leverage on VSRM for the deployment – no build template integration.
[sourcecode language='powershell' ]
[String]$SourcePath = '\\dtfsat\Build',
[String]$AppPath = 'C:\AppPath'
Ensure = 'Present'
Type = "Directory"
Recurse = $true
SourcePath = $SourcePath
DestinationPath = $AppPath
Then we can create a new Standard Environment:
which is going to contain our agentless target server. To configure a target server, you’d need to run Enable-PSRemoting –force and winrm qc –transport:HTTP from PowerShell.
This server must be added using the FQDN and the listener port – the 5985 is the default port used by the HTTP listener.
This server is always going to be in a Ready status as long as there are the required permissions in place.
The only missing bits are the Component and the Release Template. As mentioned, the Component is going to be picked from an external network share (the build drop location) and used as-is. This is just for this sample anyway, the standard Build Definition used by VSRM would work as usual.
The big difference stands in the Deployment Tool used for the component – it is going to be Run PowerShell on Standard Environment, which provides all the facilities for running the DSC script:
This is going to be our single entrypoint for running DSC script. Moreover – if you look at the Release Template toolbox it is quite…empty:
But it would work like a charm :) The Deployment Sequence is going to be pretty lean as well: invoking the Component’s deployment for the target server – and that’s all:
This is what you are going to need to create a basic DSC-based deployment using Visual Studio Release Management. No rocket science required!