psDeploy - deployment automation library

psDeploy contains both a library of cmdlets and a simple framework to drive deployments, which can either be used independently or together. The framework helps writing terse deployment scripts by automating common aspects such as logging and error handling.

Here is a simple template which illustrates a simple deployment script using psDeploy:

Set-StrictMode -Version 2
$ErrorActionPreference = 'Stop' 

Import-Module psDeploy

$psDeploy.Log.Name = 'Example2'
$psDeploy.Log.Journal = 'C:\Logs\Journal.txt'
$psDeploy.Log.Transcripts = 'C:\Logs\Transcripts'

deploy -transcript -journal -script {

    Write-Host "Doing stuff..."

} -success {
    
    Write-Host "Let's start testing"

} -failure {

    Write-Host "Please check the logs"

}
				

This template illustrates the following common practices:

• The use of Powershell's strict mode, which validates the script's syntax and catches errors such as typos, undeclared variables and non-existent properties.
• Two-level logging for easier tracing and reference. psDeploy can help maintain a journal of all the script that have been run on a specific machine, a well as detailled logs of each individual deployment.
• Automatic error handling. The deployment will stop at the first error, and automatically display details such as the command that failed.
• Entry points to add success and failure behaviors, such as sending post-deployment emails.

Whether deploying from a local desktop, the CI server or any other machine, Powershell scripts usually need to be triggered externally.
A common way to do this is to call them from a DOS batch file, or from something similar to the ANT <exec> task.

It is recommended to call powershell the following way:

powershell.exe -NoProfile -ExecutionPolicy Unrestricted -File .\deploy.ps1
				

This has the following advantages:

• It runs the scripts in the exact same context as the Powershell ISE. Using other syntaxes might trigger unexpected behaviours, such as strict-mode or the default error action not being applied to imported modules. This could be the intended behaviour, but be aware of the differences with the ISE's "run" button.
• It disables the local prfile, which ensures the script will run exactly the same on any machine, without relying on local settings and aliases.
• It ignores the execution policy, which ensures the script will run even if it has not been signed. It is of course up to the team to decide on whether or not to sign the scripts, which can ensure they are not tempered with between environments.