A lot of Drupal companies have started adopting virtual development environments. This has a lot of benefits for unifying the way people collaborate on projects. The main idea behind it is to have everyone working on the same environment, following the same production set up. Using a virtual environment, you can standardize what versions of PHP, MySQL, Apache, Nginx, Memcache, Varnish, Solr, Sass/Compass libraries, etc. are used. This way, you do not have to worry about things like setting up your front-end developer on their Mac, Windows, or Linux machine with a bunch of software for a particular project. In this article I would like to share some thoughts on how we at Propeople utilize Vagrant, an open-source software that we use to create virtual development environments.

Starting point

When we start a Drupal project, we do not just keep the Drupal codebase in the repo. We also keep configuration files of Vagrant and the Drupal repo. We use configurations from puphpet.com as a starting point but add some customizations on top. Based on our production set up (version of operating system, web server, PHP versions) we generate configs and then adjust them to our needs. One example of such a code structure can be seen at https://github.com/podarok/ppdorg. Here is the basic structure:

IP address and tools

We use a virtual host for the project. For example, after bringing up the virtual machine, we can use the URL http://ppdorg.192.168.56.112.xip.io  to access our development site. We use the xip.io service for building host names. In some projects, we also put a custom index.html.

Tools

We usually set up tools like Adminer.php, phpinfo.php and some others for developers. One of the regularly used scripts we include is a reinstall of the site (we build our sites as installation profiles) and pull_stage.sh – a script to pull the database and files from the staging or live environments.

Pull from staging

On Vagrant Box we install Drush and use it for syncing of the database and files from the remote environment. In order to have SSH login to that environment, we also copy the SSH keys to vagrant box. This can be done by adjusting the puphpet/shell/ssh-keyget.sh script by adding the following to the end of the script:

echo "Copy box ssh keys to ${VAGRANT_SSH_FOLDER}" cp ${VAGRANT_CORE_FOLDER}/files/dot/ssh/box_keys/* ${VAGRANT_SSH_FOLDER}/ chown "${VAGRANT_SSH_USERNAME}" "${VAGRANT_SSH_FOLDER}/id_rsa" chown "${VAGRANT_SSH_USERNAME}" "${VAGRANT_SSH_FOLDER}/id_rsa.pub" chgrp "${VAGRANT_SSH_USERNAME}" "${VAGRANT_SSH_FOLDER}/id_rsa" chgrp "${VAGRANT_SSH_USERNAME}" "${VAGRANT_SSH_FOLDER}/id_rsa.pub" chmod 600 ${VAGRANT_SSH_FOLDER}/*

We generate keys, placing them in puphpet/files/dot/ssh/box_keys. Then we add the public key to our staging server and that is it. It is possible to “Vagrant SSH” to the box and then run the script to keep your database and files up to date.

When we pull a database from staging we, of course, sanitize email addresses and adjust settings (for example, switching to Sandbox environments of third party systems that we integrate with, etc.).

Drupal's settings.php file

On the Drupal side, we also create a sites/default/dev_settings.php file with all the settings for the database, memcache and any other parameters needed for development. So the only thing developers need to do is to copy this file to settings.php and run the reinstall.sh script to set the site up.

Configuration changes

Let’s say we have added memcache to the project, or Apache Solr. The only thing that we need to do is to commit the Vagrant configuration changes to the repo and ask everyone to run “vagrant provision”. Doing this will set everyone's environment to the current state. This is why we love Vagrant and see the benefits of using it every day.

Downsides of Using Vagrant

We need to have enough RAM. Usually we assign 1Gb for each box. Preferably, a development machine should have 8Gb of RAM because some of our projects have multiple boxes. Another preferable thing is having SSD. What this means is that if you have pretty decent laptop, you should have everything in place to try Vagrant out.

Conclusion

We find using Vagrant to be extremely effective. It allows our teams to work together more efficiently to deliver some of the biggest, most complex Drupal projects in the industry. Adopting a virtual development environment has had a positive effect on our development workflow, getting rid of past pressure points in our process. To learn more about how we can help your Drupal project succeed, please contact us.