One of the biggest challenges in working in a large community like the Drupal community is removing bottlenecks. All too often the community can seem to come to a grinding halt on just one issue that can only be managed by one person. On Monday Dries gave a presentation at MIT and talked about how some of the Drupal community’s biggest problems have helped create some of our best solutions. In particular, he cited how our server melt down in 2005 lead to the creation of the Drupal association to proactively manage and plan for our infrastructure growth.

Today the community continues to be challenged with re-designing and implementing On the surface, it doesn’t look much has happened, but improvements in projects, and search have made big strides in making easier to use. The Drupal community works well in parallel and through lots of small iterations. Unfortunately, our development and staging infrastructure has not supported dozens of developers and themers working in parallel. We’ve now taken the time to build out that parallel development and staging infrastructure.

It is important to understand why a large site like can be hard to do local development for. First, serves about 30 million pages a month, and has over 600,000 nodes. It has tens of thousands of attached files including patches, screenshots, videos, and graphics. Setting up a greater than 1GB database and syncing over 5GB’s of files is a tough task for a local development environment.

Much of the new design for is focused on making it easier to find what you are looking for on For the redesigned development sites we also need to have a working Solr server. For example, a page like the new download and extend landing page has Drupal version search filters and at least seven blocks that are search results themselves. For themers to theme pages, their site needs content, graphic assets, patch files which need to be attached to issue queues, and the site must have working functionality.

Also, content is valuable even though it is licensed under creative commons license. If a copy of the site were to fall into the hands of spammers could suffer abuse. For that reason, we don't casually give away copies of the database and code to anyone who asks.

I'll review this new infrastructure and explain how our team plans to work to support at least 10 development sites in parallel.

The Servers

Web server

The dedicated virtual machine at contains 10 virtualhosts, and is entirely devoted to the redesign project. The webroot of this VM is /var/www.

Database Server

The database server is separate, and lives on (which is a cname pointing at, the solr slave).

The Sites

There are 10 staging sites for the redesign, each of them are password protected with: drupal/drupal to keep out search engines and bots.
Staging 1 ( through Staging 10 ( are virtualhosts on the server. Each site lives in it's own directory, /var/www/staging1 through /var/www/staging10, respectively. They are almost all setup with a recent copy of
Each of these virtualhost containers has a separate instance of's codebase + sanitized database, and we will give selected volunteers the access to commit theming and administrative changes to an instance for testing purposes.

Backing up a site's database, restoring a site

The redesign administrators have two scripts in their home dir, backup-tables and restore tables. The administrators have sudo and can run each script to backup or restore the last backup of a db. For example, if someone is going to test something on staging5 that will likely break it. You can ./ staging5. Will take about 20 min and then ./restore-tables staging5 will restore the latest backup
Database copies of

Santized DB dumps of database are available on the database server. The database server can hold 10 copies max. The problem there right now is that you need to take a dump of the database server and then reload it into another database to run an SQL script on it. This continues to be a cumbersome process that can only be done by our two database administrators Narayan Newton and David Strauss.

Granting theme repository access
* Once the re-design developers and themers have signed up for an account on we need to review their request and determine if they are a likely candidate to contribute. We get a lot of requests from people who just want to run the theme on their own site. Right now over 35 community members have write access to the SVN, and several dozen have read access so they can generate patches. Admittedly, this approval process is a significant bottleneck.
Once the contributors account has been approved they can issue the following commands:
 svn checkout
* They can also log into SVN using their username and password from
The documentation tab on the front page of the redesign implementers group for more information about how to get access and use SVN.

Pushing theme changes to development sites

There is an SVN directory called development-themes that will be checked out to each sites /themes directory. Each themer can set the default theme for anyone of the 10 instances to see their changes go live. Since Drupal can support many themes we may be able to support dozens of themers working on a site simultaneously.

Theme Deployment

We have now setup cron jobs to checkout themes from the themers sandbox every 5 minutes.

Syncing production with a master staging site

Code and configuration changes happen on We need to push these code and configuration changes to staging sites to keep them in sync. The staging sites are managed via an SVN branch HEAD == redesign and the live site is the SVN branch DRUPAL-6--1 == All configuration changes should be in drupalorg.install updates.
Deployment of code, content, and configuration changes continue to be one of the big challenges in Drupal and might be the big feature of Drupal 8. Many of Drupal’s best core innovations come from necessities.

Pushing development configuration changes to all the staging sites

When new features are being built on a staging site, we need to push these same configuration changes to all ten of the staging sites, or they might not work as the developers and themers need them to.

Asset management

Since themers work with so many graphic assets we need a way for them to more easily share their working assets and get them accessible to the redesign staging sites.

Infrastructure administrators wanted

Now that our redesign infrastructure is built, we need Drupal administrators and developers to help with the development, staging, and deployment cycles for all 10 of these re-design sites. I know we’ve asked for infrastructure administrators before and there’s been a lot of interest. If you are still interested contact me . A big thank-you to our infrastructure team for making this possible.