Development environment

One of the things which is really holding me up is learning just enough about development environment creation/maintenance to let me get to the good stuff: coding.

The basic concept is: create a simple way to have a consistent environment in which to develop code. This is actually a very old idea – probably the most famous historic example was back in the mid-1800s when in the USA everyone was talking about the war between the states but the scientific world in Europe was caught up in the argument about germs – one side believing that germs ‘spontaneously generate’ while the other saying they were living organisms which can travel to a sterile nutrient-rich region and infect it. Louis Pasteur[en.WP] developed an enclosed environment which could be sterilized, and his bottle became the symbol for the concept of germs (and, more importantly, proper sterilization.)

Virtual boxes in a box

In computing, a similar concept is the ability to create ‘virtual’ boxes. Because each container describes the environment it will create, it is relatively easy to share this information so one can A) collaborate on a single project, knowing everyone will have the same experience, and B) maintain a single central configuration which can be updated and all contributors can have the same environment.

This is especially true for provisioning – creating that nutrient-rich region. Basically, I want an environment where no one actually touches the server, but instead solely uses it for testing. The reason is, if Jane uses vim and customizes the server to suit xyr style, and Joe uses joe and customizes the server to suit xyr style, they may alter the environment enough that Jane cannot reproduce an error Joe comes up with. Instead, Jane and Joe should do all their work in project folders on their main computer which are shared with the virtual environment. This way they can customize the environment where they are coding, but the testing environment is always exactly the same.

There is something else, too. Logging into a server is considered harmful[B]. If you need to log in it probably means something was not set up correctly, or you cannot see something from outside it, which should be fixed in the container configuration or the provisioning. As Willem suggests, needing to log in is ‘sysadmin smell’, like code smell, a warning that something is probably wrong.

Another issue is which virtualization tool to use. Because this learning project has no budget whatever I choose must be no cost, and while I would prefer to use open source there are very few products which work across the big three OS – Windows, FreeBSD/MacOS, and Linux. The software stack to provide virtualization, automation, and provisioning I chose is VirtualBox[O Wiki] (not really open source), Vagrant[O GH], and Puppet[O GH] – and I am using PuPHPet[O GH] to simplify working with Puppet because I just do not have time to teach myself all the ins and outs of this stack. Vagrant is key; it makes it super easy to manage the dev vm, to reprovision, etc.

Okay, so, I have built my development box, and it is sharing the project folder to /var/www/srt. Now I need to write instructions on how to access the site locally (using the hosts file, allowing a non-proxied browser to access via http://srt.dev). And I am certainly in touch with JEDI’s observations, mostly the negative ones.

We are almost to the ‘magic???’ box in the flowchart!