Coincidently a very appropriate Easter post.
The first task for a new developer joining a new project, after they have been through the normal introductions and shown where the toilet and coffee machine is, is to get their development environment set up. How well this goes can be a good indication of the team the developer is joining. Is there a check-list that can be followed and can team members provide support when the instructions don’t work? Often teams are too busy to keep setup instructions up to date and often team members barely have time to do their own work never mind helping newbies get started.
Luckily there are tools available that allow you to automate environment setup. First I want to look at chocolatey
The reason Chocolatey is useful is that you can provide a one-line command to silently install anything you need on a development machine.
You need Notepad++? No problem!
choco install notepadplusplus.install
What about version 4.2.2 of NodeJS?
choco install nodejs.install -version 4.2.2
The Azure SDK 2.7 for VS 2015?
choco install VWDOrVs2015AzurePack.2.7 -source webpi
and the IIS Web Role?
choco install IIS-WebServerRole -source WindowsFeatures
Behind the scenes Chocolatey is going out to get each installation from NuGet. Each Chocolatey installation is a NuGet package.
You might be wondering how this helps with automating environment builds. Well read on.
Boxstarter provides the automation goodness around the solid foundation of Chocolatey. Boxstarter allows you to chain chocolatey command into scripts. It handles restart logic to ensure that the complete script eventually completes.
So your chocolatey script might look like this
choco install app1Noreboot
choco install appRequiresReboot
choco install app2NoReboot
Boxstarter will use Chocolatey to install the first app and then start on the second one. When that completes it will detect that a reboot is required and handle the restart process. When the machine starts back up, it will prompt for your credentials so subsequent reboots can be handled without intervention. This behaviour can be changed if that makes you nervous. Boxstarter will start the script from the beginning but this time detect that the first two applications are already installed. It then finishes by installing the 3rd application. With more complex scripts requiring multiple reboots it seems as though Boxstarter repeatedly runs your script until it is sure that everything is installed correctly.
Boxstarter has a number of other useful features. It can configure windows explorer to your tastes by showing or hiding system files, it can trigger windows updates and pin applications that have been installed to the task bar. It can be run on the target machine via a single command, installing Boxstarter automatically and getting its Chocolatey script via a GitHub Gist, DropBox or a file share. It can also be triggered by pointing itself at a remote machine. I haven’t tried that myself but all of the details can be found at Boxstarter.org.
Boxstarter and Chocolatey in the field
As with Chocolatey you can find lots of articles that can get you started combining the two tools. This and this are examples. However, when you get into this for real some of the details can be quite illusive.
Both the examples below install windows features (cinst is an alias for choco install BTW)
cinst IIS-WebServerRole -source windowsfeatures
and you’ll find Chocolatey examples that use the Web Platform Installer
cinst VWDOrVs2015AzurePack.2.7 -source webpi
When you are configuring your own scripts you will soon realise that this is very useful but just as quickly stumble over the question of “what things can I install as Windows Feature or from the Web Platform Installer?”
Let’s start with windows features. These are the things that you get to from Control Panel -> Programs and Features -> Turn Windows Features On and Off. I’m writing this on Windows 10 so this will be different with other Windows OSs. From here I can see what I need but how do I know that IIS-WebServiceRole maps to Internet Information Services -> World Wide Web Services. This took me quite some time to work out but it won’t take you that long because I’m telling you how to do it below.
The key is the Deployment Image Service and Management (DISM) command line. The feature of it that we need is its ability to enumerate the features available on a running instance of Windows. So if you run the following on your target machine
dism /online /get-features
You will get something like this
You get quite a bit so it makes sense to pipe the output of this command to a file.
Anything that shows up in the Feature Name field can be used as an input to the Chocolatey install command.
With the Web Platform Installer, you follow a similar process. Once you find the command things get a lot easier.
webpicmd /list /ListOption:available
The command above gets you a list of what is available through the installer. You’ll need to ensure it is installed first. You can get it here.
Anything in the ID column can be an input to a Chocolatey install.
Hopefully this and the links I have provided will have given you enough to get started and get past some of the initial learning curve. By automating your environment build you are bringing another part of your system under control. Rather than relying on a human reading a Word document you have a machine reading a script. The script can be version controlled with all the benefits this brings. If you get into the habit of setting up all environments via an automated means you can guarantee that all machines are configured the same. You rule out those sys admin changes that don’t get documented and are impossible to replicate across many machines and start thawing out the snowflakes in your environment.