Using Release Management vNext templates when you don’t want to use DSC scripts

calendarJun 18, 2015 · 4 min read · Uncategorised  ·
Share on: linkedincopy

Update 21 Aug 2015 - This post contains all the basic information, but there is an improved PowerShell script discussed in Using Release Management vNext templates when you don’t want to use DSC scripts – A better script

Many web sites are basically forms over data, so you need to deploy some DB schema and something like a MVC website. Even for this ’bread and butter’ work it is important to have an automated process to avoid human error. Hence the rise in use of release tools to run your DACPAC and MSDeploy packages.

In the Microsoft space this might lead to the question of how Desired State Configuration (DSC) can help? I, and others, have posted in the past about how DSC can be used to achieve this type of deployment, but this can be complex and you have to ask is DSC the best way to manage DACPAC and MSDeploy packages? Or is DSC better suited to only the configuration of your infrastructure/OS features?

You might ask why would you not want to use DSC, well the most common reason I see is that you need to provide deployment script to end clients who don’t use DSC, or you have just decided want basic PowerShell. Only you will be able to judge which is the best for your systems, but I thought it worth outlining an alternative way to do deployment of these package using Release Management vNext pipelines that does not make use of DSC.

Background

Let us assume we have a system with a SQL server and a IIS web server that have been added to the Release Management vNext environment. These already have SQL and IIS enabled, maybe you used DSC for that?

The vNext release template allows you to run either DSC or PowerShell on the machines, we will ignore DSC, so what can you do if you want to use simple PowerShell scripts?

Where do I put my Scripts?

We will place the PowerShell scripts (and maybe any tools they call) under source control such that they end up in the build drops location, thus making it easy for Release Management to find them, and allowing the scripts (and tools) to be versioned.

Deploying a DACPAC

The script I have been using to deploy DACPACs is as follows

1
2
3\# find the script folder  
4$folder = Split-Path -parent $MyInvocation.MyCommand.Definition  
5Write-Verbose "Deploying DACPAC $SOURCEFILE using script in '$folder'"  
6& $foldersqlpackage.exe /Action:Publish /SourceFile:$folder..$SOURCEFILE /TargetServerName:$TARGETSERVERNAME /TargetDatabaseName:$TARGETDATABASENAME | Write-Verbose -Verbose

Note that:

  1. First it finds the folder it is running in, this is the easiest way to find other resource I need
  2. The only way any logging will end up in the Release Management logs is if is logged at the verbose level i.e. write-verbose “your message” –verbose
  3. I have used a simple & my.exe to execute my command, but pass the output via the write-verbose cmdlet to make sure we see the results. The alternative would be to use invoke-process
  4. SQLPACKAGE.EXE (and its associated DLLs) are located in the same SCRIPTS folder as the PowerShell script and are under source control. Of course you could make sure any tools you need are already installed on the target machine.

I pass the three parameters need for the strips as custom configuration

image

Remember that you don’t have to be the SQL server to run SQLPACKAGE.EXE, it can be run remotely (that is why in the screen shot above the ServerName is ISS IIS8 not SQL as you might expect)

Deploying a MSDeploy Package

The script I use to deploy the WebDeploy package this is as follows

 1
 2
 3function Update-ParametersFile  
 4{  
 5    param  
 6    (  
 7        $paramFilePath,  
 8        $paramsToReplace  
 9    )
10
11 
12
13    write-verbose "Updating parameters file '$paramFilePath'" -verbose  
14    $content = get-content $paramFilePath  
15    $paramsToReplace.GetEnumerator() | % {  
16        Write-Verbose "Replacing value for key '$($\_.Key)'" -Verbose  
17        $content = $content.Replace($\_.Key, $\_.Value)  
18    }  
19    set-content -Path $paramFilePath -Value $content
20
21 
22
23}
24
25 
26
27  
28\# the script folder  
29$folder = Split-Path -parent $MyInvocation.MyCommand.Definition  
30write-verbose "Deploying Website '$package' using script in '$folder'" -verbose
31
32 
33
34Update-ParametersFile -paramFilePath "$folder..\_PublishedWebsites$($package)\_Package$package.SetParameters.xml" -paramsToReplace @{  
35      "\_\_DataContext\_\_" = $datacontext  
36      "\_\_SiteName\_\_" = $siteName  
37      "\_\_Domain\_\_" = $Domain  
38      "\_\_AdminGroups\_\_" = $AdminGroups  
39  
40}
41
42 
43
44write-verbose "Calling '$package.deploy.cmd'" -verbose  
45& "$folder..\_PublishedWebsites$($package)\_Package$package.deploy.cmd" /Y | Write-Verbose -verbose

Note that:

  1. First I declare a function that I use to replace the contents of the package.setparameters.xml file, a key step in using binary promotion and WebDeploy
  2. Again I finds the folder the script is running in so I can locate other resources
  3. I then declare the parameters I need to replace and call the replacement function 
  4. Finally I call the package.deploy.cmd command, and pass the output via the write-verbose to pass the output to the Release Management logs

This is called as follows

image

Summary

So I think these reusable scripts give a fairly  easy way to make use of  vNext Release Management pipelines. They can also easily be given to clients who just want to manually run something.