Vaprobash

Since Ubuntu 14.04 is released, and most of the kinks are worked out, I wanted to let you know how I see Vaprobash moving forward.

A New Repository

Vaprobash is moving onto Ubuntu 14.04 LTS, where it will stay until 16.04 LTS (if it's still relevant then).

Some people still need Ubuntu 12.04, and so they will still be able to use it! Going forward, there will be two development tracks (two repositories): 14.04 and 12.04. I'll be spending most of my time on 14.04. The 12.04 repository is now official in "maintenance". PR's and bug fixes are still welcome.

The fideloper/vaprobash repository is now at Ubuntu 14.04 LTS. You can, as always, grab the Vagrantfile by using http://bit.ly/vaprobash:

wget -O Vagrantfile http://bit.ly/vaprobash

For those who need to use Ubuntu 12.04 LTS (perhaps if you need to test against php 5.3 or php 5.4), there is the fideloper/vaprobash12 repository. The Vagrantfile for this repository is located at http://bit.ly/vaprobash12:

wget -O Vagrantfile http://bit.ly/vaprobash12

The Goal

Vaprobash is meant to get you a development server up and running, as quickly and painlessly as possible.

It's secondary goal (along with serversforhackers.com) is to have you learn how to set up servers yourself. To this end, Vaprobash uses bash scripts, which are reasonably clear in showing each step towards installing various pieces of software onto an Ubuntu server.

The hope is that by not obscuring (and complicating) the install process with a provisioner of some sort (Ansible, Chef, Puppet), people can learn by seeing, copying and tinkering on their own.

I want people to learn enough to grow out of Vaprobash.

Stability

Vaprobash gets a lot of pull requests. I love this - it's a sure sign that it's simple enough for people to grasp and modify.

However, this has a detriment. At any point in time, there's usually a bug somewhere as well as some new feature all intermingled into the develop or master branches. This makes it hard to pinpoint a release.

Furthermore, PR's regularly introduce bugs; They aren't always thoroughly tested. I can understand that - provisioning a server over and over to test all the various use cases is a pain. It's a slow process, and there are a ton of variations (depending on what people choose to provision).

As of yet, there isn't a great testing process. Even if we used the magic of Docker to make relatively quick, repeatable tests, it would still be hard to test. It's not enough to test that Nginx was installed. We also need to test that it's working (running), and it's virtual servers are configured, and probably some other factors as well. Furthermore, tests could be misleading due to other settings changed by other provisioners - they are not all self-contained. For example, Apache and Nginx need to be aware of if PHP was installed.

If anyone has a good solution for this, I'm all ears. I think some sort of Docker-based testing would be amazing.

Going Forward

Moving forward, I want to start using a tagging/versioning system for both repositories. This will lend some stability for those who need it.

Tagging versions will allow users to "freeze" Vaprobash, so they get the same sets of install scripts every time they provision a new server. This means that their installations are much, much less likely to be different, even as Vaprobash changes (new features, bug fixes).

Each repository will soon be marked as stable with a 1.0.0 release. Then bug fixes will be pulled in readily (increasing PATCH versions) while non-breaking features will increase MINOR versions. Finally new (breaking) features will increase MAJOR versions.

This will be similar to Laravel, where there will be branches for MAJOR.MINOR releases, and tags for all MAJOR.MINOR.PATCH releases.

PR's for new features will be added in more slowly. Perhaps use that extra time to keep testing your scripts :D