Friday, May 22, 2015

Configuring a Dev Environment with PowerShell & Chocolatey

At work this month I was tasked with developing scripts to bootstrap windows machines into our development environment. Many years back I was in charge of a few small networks, and I'd used PowerShell (PS) and Group Policy to control virtually every aspect of our machine setup and deployment. Drawing on that experience, I knew that I could use PS to setup and configure developer machines.

I was aware of Boxen for OSX, so went searching and found Boxstarter which is similar. While cool and all, I decided to focus on developing the scripts and not how they'd be delivered to the machines.

To start in on the process I first determined what needed to be installed and configured, and any steps that would have dependencies.

1. Enable Windows Features - IIS 
2. Configure IIS 
3. Install Scale Out State Server 
4. Install URL-Rewrite 2 
5. Copy files from server to local drive 
6. Install developer tools (using Chocolatey) 
7. Clone Repositories

After determining the requirements, I started working on the scripting and that is when I learned all that I did not know.

- Power Shell Tools for Visual Studio -
Upon starting to script up the various steps, I realized that the PS ISE that comes with Windows lacks the niceties of other editors. I tried Sublime, Atom, and a few custom PS editors before I found PowerShell Tools for Visual Studio. This VS extension allows you to edit, debug, and even test (with Pester) your PS code. While not entirely bug free, I have to say this VS tool made the development experience much more pleasant.

VS Screenshot showing  Pester tests running

- Pester Tester -
The Pester framework bring mocking and BDD style test assertions to your PowerShell scripts. The documentation is good, and the framework simple enough that it doesn't take much time to learn. One interesting thing to note is that you can run your Pester tests in the VS test runner (using PS Tools for VS). At least .ps1 files work, tests for .psm1 (PS Modules) always showed as not run tests. You can get around this by simply running the PS command Invoke-Pester in the root directory of you project to run all the tests in the PS test runner.

While Pester is great because it helps lock down your code and protect from regression bugs, you still need to test your scripts by running them. I used Windows Azure virtual machines for this. I spooled up Windows 7, 8.1, & 10 machines and ran the script against all of them. That's how I discovered that some of the configuration code I was using for IIS was failing on Windows 7 but working on 8.1 & 10. I was able to tweak the code, spool up more virtual machines, run the script and check configurations. Tedious as it is I'm not sure I know of a way to get around this step. Here is an example of some code tested with Pester.

- Chocolatey -
Chocolatey in concept is pretty awesome. Its a package manager for windows, based on PS and NuGet. I made use of it in my project by first having Chocolatey install itself and then install all the apps that a dev typically needs. The Chocolatey gallery has most common applications and the installers accept flags allowing for install customization.