BoxStarter suitability for maintaining developer environments?

Aug 29, 2014 at 9:28 AM
Hi, I've just come across BoxStarter and Chocolatey and both are very exciting! BoxStarter's website, examples and blog all seem to be focusing mainly on using BoxStarter for setting up new instances of VMs for use as servers. Chocolatey does have many packages that are entirely developer-facing (things like Visual Studio and notepad++), and BoxStarter has commands to set up the Windows environment for developer use (disabling UAC, that sort of thing) though, so I presume they're intended to be used for setting up developer machines too.

Something I'm interested in (and wondering if BoxStarter is suitable for) is being able to update (and roll back) sets of packages over time, as well as first-time setup. I'd like to be able to version a BoxStarter configuration describing some parts of the environment, alongside the codebase, to ensure that things like required tools and SDKs are at the correct version. Then, if I check out some old version of the project which requires some old version of an SDK, or I want to roll out some change to the codebase which requires some environment variable to be set up, everything is just magically handled.

It's not clear from the BoxStarter/Chocolatey docs that this kind of use case is supported. Is there any concept of automatically uninstalling packages that were previously installed by BoxStarter but are no longer listed in its configuration? Or updating/rolling back to new/old versions of a package? If not, are there any plans to support this or am I barking up the wrong tree?

Thanks,
Ben
Coordinator
Aug 30, 2014 at 8:06 AM
Hey Ben,

Since alot of the most recent Boxstarter work has been providing support for VM environments, that may have skewed alot of the documentation out there. However I would definitely say that dev environment setup is the most predominant use case for boxstarter. Regarding updates and rollbacks, I think Boxstarter/Chocolatey can support these scenarios but maybe not quite the way you are envisioning.

Chocolatey does support an Uninstall command but it is up to package authors to implement that and most dont. However, you might consider a slightly different approach. Instead of trying to include logic that would update from v3 to v5 or rollback from v4 to v2 which can get very complicated, when you create a Boxstarter package, simply focus of bringing the state of the machine to the point it needs to be to support the version of the codebase you expect to run. So for package v3 supporting v3 of your codebase, lets assume the user's machine is currently built for v4. Maybe this means they have .net 4.5.1 installed but v3 requires, v3.5 of the .net framework. So you check if that version is installed and install it if not. That works since .net versions can live side by side. But maybe there is another component that requires v2.6 and cannot be installed alongside of 3.2. Your package, knowing that only one version can exist will uninstall a newer version if it detects it and then install the required version. You might also keep this version of the chocolatey/boxstarter package script in the same version control project as the codebase it supports. This way no matter what version the user pulls from source control, you know they will get the correct chocolatey/boxstarter package that identifies the needed environment.

I'm not sure this truly answers your question. I can say that neither Chocolatey or boxstarter will rollback to a previous state unless the package does that explicitly.
Sep 2, 2014 at 8:29 AM
Hi Matt, thanks for taking the time to reply!

That's encouraging - I'll definitely give BoxStarter a shot. Our team (and every team I've ever worked with!) has suffered from environments being set up differently, sometimes in benign ways ("this would be much easier if you just installed notepad++"), sometimes in very annoying ways ("no wonder your crash dumps have no symbols, you don't have X set up"), and sometimes in very painful ways (old versions of tools secretly polluting shared build caches with invalid files). A nice one-click option to make sure our machines are running the same stuff would be great. If it could also help set up new developer machines, that would be fantastic - no more day-and-a-half next-next-finish clickathons.

Anyway, I see how I can get a rough version of this working, by explicitly uninstalling incompatible packages like you say. Sadly in this field (video game development) there are a lot of incompatibilities so this will definitely be needed, not just for versions of a package but whole packages. I do wonder how this will scale up though - I imagine scripts can get quite hairy quite quickly this way. Also I wonder if it's likely that unexpected incompatibilities will show up, making it difficult to roll back to old versions since they don't know they need to uninstall things which didn't exist at the time?

Perhaps I could implement a wrapper to manage this stuff? Is there any way of querying BoxStarter/Chocolatey for installed packages and how they were installed? If I could tag packages as being installed by the 'project setup' step (to distinguish them from manually installed packages), I could diff this against some versioned manifest to decide what to install/uninstall. Maybe that's overkill though :)
Coordinator
Sep 2, 2014 at 8:55 AM
Ha! I've had a few of those day-and-a-half next-next-finish clickathons. Not fun.

Another approach that may make removing the fuss of upgrades and rollbacks simpler and more scalable is always creating your dev environments from a fresh, known base line. Like a bare os or something similarly minimal. Rather than upgrading or rolling back to another state or version, every version's environment build assumes nothing is or almost nothing is on the box. This may mean that the dev environment is a vm and your base is a simple windows image.

If you have not already, I would take a look at a project like Vagrant http://vagrantup.com. It is similar to boxstarter but very much focused on VMs but has a work flow that does not tie one to working from inside the vm. Rather you can work with your own tools on your own box but your app and its core dependencies live on the VM. The vagrant web site does a better job of explaining it. Some have played with integrating boxstarter and vagrant and I plan to release a boxstarter provisioner for vagrant.

At any rate, it may at least give you some ideas.