Ok, so why is this such a good thing?
Step templates are great – there is even a large library of pre-existing templates to download (https://library.octopusdeploy.com/#!/listing). If you’ve not used them before, step templates allow additional scripts to run during your deployment.

Examples could be: post to slack, create certain folders, delete given files etc. Basically anything you can achieve with powershell can be done in step templates.

Lets just stick with step templates then?
If you’ve gone through the process of setting up several deployments with Octopus and find you want to replicate the same functionality across several projects or installs then you need to re-create all the step template configurations each time. It’s not the slowest process but the idea below helps streamline things.

Now that you can run scripts from a package, why not source control the steps you want to run? One key advantage is that you can then see things like history of all the deployment steps.

What needs setting up?
You need to be running version 3.3 or higher of Octopus – see above for the link.

I’ve been using a simple test deployment of an out the box MVC project along with a new project specifically for the scripts.:

In Octopus this has 2 steps:

The first is a vanilla website deployment of ‘WebApplication1’. The second the startup scripts:

Note the package id. The idea behind using a separate projects is that the powershell scripts never need to exist in the website project.

The startup script project

I chose to use a class library for the simple reason that I could include a reference to Octopack and hence building the output nuget file was trivial.

The nuspec file is important as it tells the packaging to include all powershell files:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>WebApplication1.Startup</id>
    <title>TODO Your Web Application</title>
    <version>1.0.0</version>
    <authors>TODO Your name</authors>
    <owners>TODO Your name</owners>
    <licenseUrl>http://TODO.com</licenseUrl>
    <projectUrl>http://TODO.com</projectUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>TODO A sample project</description>
    <releaseNotes>TODO This release contains the following changes...</releaseNotes>	
  </metadata>
  <files>
	  <file src="**\*.ps1" target="\" />
  </files>
</package>

Packages simply contains a reference to Octopack:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="OctoPack" version="3.0.53" targetFramework="net46" developmentDependency="true" />
</packages>

And finally the scripts:
Helloworld.ps1

Write-Host "Hello World PS script example"

if ($OctopusParameters) {
	##enable the next line to show all Octopus variables
	#$OctopusParameters.GetEnumerator() | Sort-Object Name | % { "$($_.Key)=$($_.Value)" }
}

#use this approach to pull in additional script files
. .\Startup.ps1

And the more important one, Startup.ps1

function createFolderIfNotExists{
	param([string]$folder)
	if (!(Test-Path $folder)) {
		Write-Host "Creating $folder"
		New-Item -Path $folder -ItemType Directory
	} else {
		Write-Host "Directory already exists!"
	}
}

function assignReadPermissionsTo {
    param([string] $item, [string] $readPermissionsTo)
    if(!(Test-Path $item)) {
        throw "$item does not exist"
    }
    $users = $readPermissionsTo.Split(",")
    foreach($user in $users) {
        Write-Host "Adding read permissions for $user"
        $acl = Get-Acl $item
        $acl.SetAccessRuleProtection($False, $False)
        $rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user, "Read", "ContainerInherit, ObjectInherit", "None", "Allow")
        $acl.AddAccessRule($rule)
        Set-Acl $item $acl
    }
}

function assignWritePermissionsTo {
    param([string] $item, [string] $writePermissionsTo)
    if(!(Test-Path $item)) {
        throw "$item does not exist"
    }
    $users = $writePermissionsTo.Split(",")
    foreach($user in $users) {
        Write-Host "Adding write permissions for $user"
        $acl = Get-Acl $item
        $acl.SetAccessRuleProtection($False, $False)
        $rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user, "Write", "ContainerInherit, ObjectInherit", "None", "Allow")
        $acl.AddAccessRule($rule)
        Set-Acl $item $acl
    }
}

$foldersToCreate = @("_logs","test\deep")
$usersToGiveAccess = "IIS_IUSRS"

if ($OctopusParameters) {
	$installFolder = $OctopusParameters['Octopus.Action[Deploy website].Output.Package.InstallationDirectoryPath']

	Write-Host "Environment: " $OctopusParameters['Octopus.Environment.Name']
	Write-Host "Deployment folder: " $installFolder
	
    Foreach ($folder in $foldersToCreate) {
        $newFolder = [io.path]::combine($installFolder,$folder)
        createFolderIfNotExists -folder $newFolder
        assignWritePermissionsTo -item $newFolder -writePermissionsTo $usersToGiveAccess
    }	
}
$PSScriptRoot = Split-Path -Parent -Path $MyInvocation.MyCommand.Definition
Write-Host "Current running folder is: " $PSScriptRoot

It’s worth noting this should be considered a POC of the approach. The next steps would be to split the scripts up into more meaningful units, remove hello world and update the nuspec with more valid information.

If you struggle with accessing the Octopus Parameters you require, the script in helloworld allows you to dump out all parameters and their values. In the startup script the parameter: $OctopusParameters[‘Octopus.Action[Deploy website].Output.Package.InstallationDirectoryPath’] depends on the name of your deployment in step 1 of your deployment process (Deploy website)

The post Octopus deploy – Script Steps sourced from a package appeared first on blog.boro2g .co.uk.