Early this year I had an “opportunity” to replace my desktop mini-tower (bonus tip - making unauthorized heat spreader modifications to SDRAM chips can lead to instability and eventual system failures). I was very much not looking forward to the click-click-next-accept-click-fest that typically comes with re-installing a bunch of client applications and the resulting system reconfiguration. This seemed like the time to bite the bullet and try that most challenging of tasks - configuration management for a Windows workstation.
Chef is my configuration management (CM) platform of choice. While Chef has great support for Windows, things get squirrelly for any CM tool when dealing with client applications (MS Office, VMWare Workstation, Firefox, et all). There’s very little standardization among all of these different applications. Some come as MSI, some as EXEs, and still others as ZIPs or even more exotic formats. All have their own custom implementations of silent install switches and configuration files, if they support such options at all. Dealing with these is beyond the purview of a CM tool. What’s a system builder to do? Enter Chocolatey!
Chocolatey Package Management
Chocolatey is a somewhat new (circa 2011) solution attempting to bring apt-like functionality to Windows. With a clean PowerShell interface to packages distributed via NuGet, an abstraction layer is created that allows users to have a consistent API with which to interact for dealing with messy client applications of all sorts. Having recently had my first hands on experience with the nifty MacOS Homebrew toolchain, this seemed like just the thing.
Chocolatey shows a lot of promise. The community package feed of user created software is fairly robust. The Chocolatey ecosystem is evolving quickly and the overall solution doesn’t feel as polished as the current Homebrew experience. Particularly pain points include the the lack of a homebrew-fonts equivalent for font installation, and Chocolately’s dependency on NuGet for package distribution’s unfortunate side effect of breaking the clean connection between the client and a GitHub repository. Not having the issues and PR system from GitHub has been a particular annoyance, with Chocolatey’s primary system being a rather ad hoc combination of Disqus forums, Gitter, Google Groups, and occasionally GitHub issues. RealDimensions Software (the development organization behind Chocolatey) also pushes their paid version a fair amount. This is understandable given the need to establish a support model for the open source tooling, though I don’t always agree with their choices on what to paywall. I fear that real maturity in this space is going ultimately going to take more work from Microsoft, who seem to be more focused on meta-level infrastructure such as NuGet at the moment.
Developing the Cookbook
My most useful technique for developing this install process is the maintenance of a log of all the changes and installs I’ve made on my system. Building a custom Windows 10 box with Packer enabled me to get a Vagrant-controlled VM up and running, which I could then use for testing the initial versions of the cookbook. Microsoft seems to have gotten much stricter with their license and activation enforcement these days and I quickly ran into problems with my retail license key using up the allowed activations due to VM reinstalls, so this was only useful for my initial tests. More complete tests benefited from some failed setups of my disk encryption, necessitating a couple of clean reinstalls. Nothing like a little live fire exercise, eh?
Sounds nifty, so where’s the code?
While I’d love to share the cookbook I came up with for my Windows workstation management, I currently have a number of secrets and other proprietary content embedded in it. License keys, references to private servers, and a number of non-redistributable font files all live in this cookbook.
Apart from the immediate need of using this to get my desktop system installed and configured, I’ve also applied this cookbook to my older laptop system. This has corrected a host of settings drifts between the two environments that would have been next to impossible to track down manually. Now I can finally fire up an IDE, terminal, or design program on either system and be confident I’ll have the same look and feel on either system. Couple that with the existing VCS and cloud file sync systems and my environments are pretty darned transparent across any modality.