Web Stacks: Optimising for Efficient Local Development

16 FebBrian Gilbert

I've been building websites since 1995, back then it was all static HTML and a lot simpler, all you needed was a web browser to test things.

As time progressed I started building sites that also needed an application server and database backend I also started looking at setting all of this up with a local web stack. Over time I've tried several options and this presentation is a comparison of several Drupal compatible web stacks. 

The Presentation

I will be presenting “Web Stacks for Local Development” at DrupalSouth 2014 on Sunday the 16th February at 4:00pm (in the Soundings Theatre). The talk will be posted here as soon as the recording is available, but come see me in person if you’re attending!

The talk wasn't recorded at Drupal South, but here is a recording from the Drupal Melbourne Meetup.

 

What is a Web Stack

A web stack is the combination of tools that are required to sever your website to the browser, as Druapl developers these are typically the following:

  • Webserver: Apache, Nginx etc
  • Database server: MySQL, MariaDB, Percona etc
  • Application Server: PHP

In production it may also include a caching layer such as Varnish, but you usually wouldn’t want that in your dev environment.

I believe there are efficiency benefits to be had by choosing carefully the web stack you use for local development which is why I decided to do a presentation about it at Drupal South today.

Throughout the presentation I compared several 1 click installers, and some more advanced setups to show that you can save time during development using the tool that is right for you.

For those that didn’t have time to grab a screenshot of of the links describing solutions to some of the issues that I highlighted they are included below. 

Links from the presentationAcquia Dev Desktop

Acquia Dev Desktop doesn’t work so well on windows, I’ve documented how to improve things at:

OSX Aegir Installer

The OSX Aegir Installer script that I created can be found at:

Hosts Management

We don’t like having Drupal running under subdirectories of a single site, so we use wildcard DNS so that we can create a vhost entry for each site and access it without having to manually edit the hosts file on our laptops

Cron Setup

So that Drupal can run scheduled tasks it’s best that you have cron configured here are the Drupal documentation pages for doing this:

Configuration Management Tools

Once you start going down the virtualisation route you’ll likely want to automate setup of the virtual machine, you can use any of the following configuration management tools:

drupal planetdrupal

Original Article: