Last updated April 27, 2016. Created on May 29, 2007.
Edited by madan879, boldinmd, nareshbw, ChandeepKhosa. Log in to edit this page.

Discovering the best tools, and learning how to use them effectively, takes time and effort. While that effort may be duly rewarded, spending weeks looking for and trying to configure software can be frustrating. This chapter contains the wisdom of Drupal developers past and present. We share what we have learned, list and evaluate favorite software and best practices, and describe how to set up and use these tools to advance Drupal.

If you have recently started a Drupal project within an IT department and Drupal is relatively new to the team, you may be overwhelmed by the possibilities to develop and deploy, all of which require time and effort to set up. This may also be true if your organization has not yet made a heavy investment in open source. John uses a Mac; Ed is always on Windows; Pete, a native LAMP stack freak, is the Drupal geek who only uses Ubuntu. And now they have to collaborate on their first Drupal site. How can you build a development environment available to team members on different laptops?

Drupal nerd

Then when Phase 2 of the project starts, the Responsive design phase, the theming phase, courtesy of Sass and Compass via RubyGems is the environment going to be able to handle these extra tools? And what if the boss decides full text search on the site is de rigueur? Apache Solr courtesy of Tomcat server.. all needing to be installed on the dev LAMP stack in addition to the standard tools? Phase 2 is when Vagrant comes into its own.

Okay, when the dev environment is decided and the plan sorted, what about deploying the code as it takes shape, from their laptops onto testing boxes while ensuring the repositories are managed? How to ensure everyone has the same Drupal tools, like Git and Drush, available to them so they can swap notes and share those sweet Drush commands?...

Everyone is looking for the killer tool set, the killer dev environment, the ultimate out-of-the-box solution. There are some killer tools out there: VirtualBox, NFS, SSH, Rsync, Drush and Git, and then there is Vagrant. For most teams it becomes a question of pick and mix. If you can arrive quickly at an agreement on what you are going to use and what you are NOT going to use, it can make a project move a lot quicker. My advice is if you are working on a professional project, you should look at using Vagrant in addition to VirtualBox.

There are some really good VM's you can drop straight into the VirtualBox, such as DrupalPro. However, these will only take you so far if you are operating in a collaborative professional context. Vagrant takes the VirtualBox to a new level and provides the extensibility and power you need. There are many well-documented, actively-maintained projects like VDD (Vagrant Drupal Development), Drupal VM, and Vlad, that are great starting points (a more exhaustive list can be found here). A chance for the team to get its feet wet with Vagrant and Drupal, including Drupal 8!

Everyone is encouraged to add their experiences to this chapter.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

imadalin’s picture

This introduction to this "Setting up a development environment" chapter is not objective at all. It's making a sugestion from the start to use Virtualised Environments instead of briefing on most common ways to setup an environment that would suit the user.

Vagrant solutions should be briefed as one good alternative, among other ways of setting up the personal "workstation" to work, among LAMP stacks, custom separate setup of each tool, Docker and why not online dev boxes.

Torenware’s picture

There are certainly alternatives, but for the use case the author brings up -- multiple people with different hardware -- virtuals in general and Vagrant in particular have become the standard tools. They work on most common operating systems, and they let you use the tools you need before you know how to install or configure them.

When used with something like DrupalVM, virtuals allow you to get people up and running w/o getting into sysadmin related subjects such as setting up a web server or a database server. MAMP and similar solutions are still used, but becoming less popular, mostly because beginners can run into problems that are very hard for them to get past. Using a virtual, a complete beginner can have a working Drupal install in an hour or less, and that's hard to beat.

I assume that later chapters do get into details, which you do need to know for many kinds of deployments. But the first page of an introduction can dispense with these, I think,

Rob Thorne
Torenware Networks

imadalin’s picture

I do agree with you, trying to put myself in the position of a beginner, and suggesting to them to get started like that is the right way.

My point of view is that just the introduction is not too objective enough, it's formulated in a way like that should be the only choice.

I'm going to do some additions on the "Pre-made development environment" section that will take in consideration developers from other fields that might encounter problems starting up like that - example Windows Mobile developers that already have Hyper-V enabled and have to scratch heads on how to make Virtualbox work for them. Or devops that work on Linux workstations using the KVM hypervisor. It's one of the moments when this is not so a "beginner level" thing and situations like this do happen.

iAlexander’s picture

The title is "Setting up a development environment" but the copy has literally nothing to do with setting up a development environment. I'm lost. Why would a VM be necessary just because people within teams might be using different operating systems? You can run Ruby (and install gems of course) on Unix and Windows so that means Linux, Mac, and Windows can run the same software without issues. There's no need to use a VM to run software that's already cross compatible unless there are weird bugs within that software. In that case why not use Docker instead of a VM? No need to have everyone running an entire Linux VM just to use command line tools.

Even if Docker isn't an option why not run everything on a VPS or an in-house server and just let people SSH into it to do things with RubyGems and whatever else? Why is the title "Setting up a development environment" if this article doesn't even have a single line of code? This whole website is just weird.

cninroh’s picture

While I support abstracted development environments in the earnest, Drupal.org documentation and especially their way of providing information for developers that are just starting to work with Drupal is surprisingly lacking.