VSTS Rangers - Using PowerShell for Automation - Part I: Structure & Build

Published on 20 August 2009 • Estimated reading time: 3 minutes

As Willy-Peter pointed out, a lot of my evenings have been filled with a type of visual cloud computing—that being PowerShell’s white text on a blue (not quite azure) background—that makes me think of clouds. This is for automating the virtual machines that the VSTS Rangers are building.

So how are we doing this? Well, there’s a great team involved—it’s not just me—and we’re working on a few key scripts, which, as you might expect, involve pre- and post-installation configuration for VSTS/VS/required software, tailoring the environment, and installing additional software.

The Structure

How have we structured this? Since each script is developed by a team of people, I didn’t want one massive script that everyone would fight over for conflicts and merges. At the same time, I didn’t want to ship 100 tiny scripts that call each other—so I wanted to ship one script but allow development by many. How did we achieve this? Step one was breaking down script tasks into functions, assigning them to team members, and giving them reference numbers:

Note: This is close to reality, but the names and tasks have been changed for the sake of innocent team members.

From this, people produce the smallest scripts possible, naming them with the reference number—for example:

• 2015-InstallSQL.ps1
• 2020-InstallWSS.ps1
• 2025-InstallVSTS.ps1

The Build Script

These scripts go into a folder, and I wrote another PowerShell script to combine them into a single "super script" used for execution. The build script is simple: it uses PowerShell commands to fetch the content of all .ps1 files in the directory and outputs them into a single file, like this:

Get-Content .\SoftwareInstall\*.ps1 | Out-File softwareInstall.ps1

This combines the scripts while keeping their order intact thanks to the reference numbers.

As an aside, I didn’t originally use PowerShell for the build script—I tried the old-school DOS copy command—but it had a few bugs.

The Numbering

What’s the deal with the numbering? For those who’ve never coded with line numbers and GOTO statements, leaving gaps might seem odd—why not sequential numbering? Well, what if we missed something later and had to add a new script? Imagine renumbering all files after that—EEK! Leaving gaps makes it easy to insert new scripts without disrupting the system.

As for why I start at 2015—well, each script gets a range of 1000 numbers (pre-install: 1000, software install: 2000, etc.). This way, I can glance at a script and know its purpose and placement at once. The starting point is 15 because 00, 05, and 10 are already reserved for:

• 00 – Header. Explains what the file is.
• 05 – Functions. Common functions used across all scripts.
• 10 – Introduction. A brief description of the script’s purpose, displayed before execution, followed by a pause. This pause is crucial because if you accidentally run the wrong script, you can hit Ctrl+C at that point before anything executes.

This concludes part I. In future parts, I’ll dive deeper into some of the scripts and the lessons I’ve learned along the way.