I recently learned a trick for deploying a folder of report templates in TFS to a handful of development team folders: PowerShell.

Being new to PowerShell, I won’t attempt to explain its usefulness or much of its mechanics because those of you who know, already know. (And those of you who don’t know should definitely check it out.) Basically, PowerShell is a handy tool for performing batch tasks that might otherwise cause unsightly bald spots.

So, what did I learn on my first PowerShell adventure? Besides a few basics, I learned how to use variable scope. Variable scope was particularly useful for my application because my deployment consisted of two script files: a bootstrapper and a helper file. My first attempt at writing the helper script was not pretty. I have pasted an abbreviated version here (removing the actual processes) to show my mess of variables not using scope. Looks something like this:

Granted, this script file has several functions: A database lookup to get some parameter values, a loop through the report template folder to get the names of reports to deploy, a function to create the destination folders on the report server and a function to deploy each report. (I realize there are probably better ways to pull off these tasks, but since this is my first PowerShell project, just go with it.)

So thanks to some help from my patient mentor Ryan Cromwell (@cromwellryan), I have a script that works. But how can I make it cleaner and easier to configure? My first thought is I would really like to be able to declare my hardcoded values somewhere easy to see. I would also like to limit the repeated passing of a very similar set of variables through each function.

So how can variable scope help me do this? Using scope I can set my configurable variables at the top of the script. This makes it easier to see/use and eliminates the need to pass these variables on through my chain of functions.

From what I have been able to find scouring Google, a variable’s scope can be either nested (0 being lower than 1 and going up from there) or named. Named scopes are “Global,” “Local (default),” and “Script”. Global is accessible to the current runspace. Local is accessible within the current running function. Script is accessible in the current running script. More detail can be found within PowerShell using the command “get-help about_scopes.” (If you would like more information on nesting scopes, here is a good article on the subject.) But for the purposes of cleaning up my simple .ps1 script file, I will stick with the named scope “Script.”

My script is a little easier to read and manage after re-tooling it using the scope “Script” on some of my variables:

Now my script is easier to configure and eliminates some of the repeated variables passing through the functions. I might have been able to take this further with the rest of the variables, but since these are set by the bootstrapper script and change for each team to be deployed, I will leave that challenge to future exploration.