Octopus allows you to embed PowerShell scripts in your packages that are executed automatically during a deployment. This is a great hook that allows you to:
- Run custom executables
- Configure Windows Services
- Configure IIS
- Execute database deployment scripts
- Configure security settings of files and folders
- Tons of other things
Variables defined in the Octopus portal will be automatically passed to your scripts, and since variables can be scoped to an environment or machine, this provides a nice way to parameterize your scripts for different environments.
The Tentacle agent hosts PowerShell in-process, which means there are sometimes differences between how a script will run in normal PowerShell, versus how they run in Octopus. Testing scripts was always difficult - you’d have to package them up, create a release, and deploy the release just to see if a small change to the script worked.
If you are having trouble getting a PowerShell script to run, you can now test the scripts directly using the Tentacle executable, which means they run in exactly the same context as they do in a deployment. You can do this from the command line using:
Tentacle.exe run-script -v Message="Hello world!" -v Repeat=5 -f MyScript.ps1The -v argument allows you to pass variables (as if they were variables being used in the deployment). The -f argument specifies the script file to run. You can also use -w to set a custom working directory.
Assuming my script looked like this:
foreach ($i in (1..$Repeat))
{
write-host $Message
}The output would look like:
This feature is available from build 1.0.16.1276. Hopefully it makes testing PowerShell scripts in a Tentacle context easier!
Tags:
Related posts
Variable specificity and complexity
Octopus allows variables to be scoped to different environments, roles or machines. A simple example of where this is useful, is to have different values for a database connection string depending on whether you are deploying to a Test or Production environment.
Fun with output variables
In Octopus 2.4 we've added the ability for variables in one step to be available in another step.
Do you build your binaries once?
For any non-trivial application, you're going to be deploying the software to multiple environments. This means you need to choose do you build your binaries once, or do you build them before each deployment?