development environment

This thoughts applies directly to web development, but this concepts can be used also for other fields of development for instance c++ or KDE.

Good Old Style

in the pre virtualbox times it was pretty easy, all the tools and services that are needed for development were simply installed so that you can use it everytime.

Since i working most the time on a laptop where battery time is an important topic this approach has some drawbacks. Therefore whenever you do not develop it is not required to run the i.e. LAMP stack, especial the memory intensive things like MySQL server. So in the end it is a good idea to not waste the system resources.


The solution is simple: only launch that stuff on demand. The next logical step was to create a dedicated runlevel like #4 where i had configured MySQL and Apache to launch. With that it was very easy to enable all the stuff whenever it is needed and normally u would save system resources when it is off.


with systemd [1] it is a bit more different because a runlevel as such does not exists anymore. But nevertheless it exists a similar thing that can be used called target. You have to define a so called target where you place the relevant services and then you can launch this target via systemd command:

# launch the target with apache, mysql
sudo systemctl start

The whole approach works quite nice, but there is one hidden issue: software version differences. For instance it's often very important to launch the same version of Apache or MySQL or PHP like on the final production servers, to having real world behavior and not discover strange behavior later on release time. With python this is quite nice solved with the virtualenv approach. There you can install a specific python version number and the related software to it. But for PHP based stack it is not that easy.

Next Generation Style

as already mentioned virtualbox is a very handy piece of software that allows you to maintain templates of machines for special purpose. Meanwhile a tool called Vagrant [2] helps much more by automating the builds of those machines. So your machines gets disposable because you can rebuild it from scratch. The configuration of this machines then can be done from others like chef solo or puppet [3]. I personally prefer the puppet approach because it is very well structured and it's easy to cut down pieces and have a dependency analysis done.

To come back to the issue that a need for specific OS or version of software exists, it is now quite easy to provide the installation as part of the project. A Vagrant file and a puppet configuration is needed and the VM can be generated and configured as needed.

UPDATE: i don't agree anymore, ansible [4] is much more simpler and therefore better than puppet


for me it depends on the project itself if the overhead of a VM configuration is the effort worth. But for long running projects that needs to be maintained and or supported over a longer period it is worth to invest the effort.

Especially the puppet configurations can be found on github for a lot of common setups.

UPDATE: Ansible-Galaxy contains a lot of common configurations.

For instance a Python-Django-Mysql [5] based development environment was missing, so i created one by inheriting a Python-Djanog-PostgreSQL based one. I added also the puppet configuration for the installation of mysql etc.


[2]Vagrant - Automate VirtualBox
[3]Puppet Provisioning
[4]Ansible Provisioning
[5]Django-Vagrant-Mysql Template