Almost every one of my deployments with Octopus Deploy involves a step where variables are replaced in configuration files. Frequently we encounter the case where a variable has not been properly replaced. Now I am not implying there is a bug in Octopus, but rather that mistakes happen. Regularly.
Some time we misspell a variable in either Octopus or the config file, or we add a variable to the config and not Octopus, etc… The deployment succeeds, but the application doesn’t work. It’s common enough, that one of the first troubleshooting steps we perform is to search the config file for #{
and see if anything is found.
I got a little bit of time a few weeks ago and put together a script to help resolve this issue in the future.
Source code for Find-Unreplaced PowerShell cmdlet
The script will look in the files you specify for the pattern #{...}
. You can also specify the folder to look in, if you want the cmdlet to search recursively, and if matches should throw an error. The output includes the full path of the file, the unreplaced variables that it found and the line number they were found on.
Here are a few examples:
Find-Unreplaced -Path $OctopusOriginalPackageDirectoryPath -Exclude *.Release.config -Recurse -TreatAsError
This will look recursively through the path your package was install to and if any unreplaced variables are found, it will throw an error. You could put this at the end of you Deploy.ps1
and this would actually cause the deployment to fail. The -Exclude *.Release.config
is because we should have unreplaced variables in the in files like web.release.config.
Find-Unreplaced -Path .\ -Recurse
In this case the script is looking the current directory, and again, recursing. No files are excluded and it’s just using the default Files
parameter of *.config
. It will issue a warning if matches are found. You might put this in your PostDeploy.ps1
Now I commonly use this script with the -TreatAsError
flag set and catch this type of error immediately during the deployment.
No comments:
Post a Comment