The Economist website, which runs on Drupal, is one of the big examples that everyone uses for to showcase how good Drupal can be. The Economist was first published in September 1843 to take part in a sever contest between intelligence, which presses forward, and an unworthy, timid ignorance obstructing our progress. Now, unique visitors to the site are around 6.5 million and 32.5 million page views worldwide.
At DrupalCon London, some of the folks from The Economist’s global technical team sat in a room and gave an informal case study of their use of Drupal and took questions from the attendees.
Development
From a development standpoint, the Economist team use Agile project management with Scrum. In terms of how things work for Dev Ops, they use Bazaar as their source control system. One of the main reasons they use Bazaar was access to LaunchPad. No piece of code that The Economist team write goes public without it being checked at least twice. With LaunchPad, any developer can put it up and have the rest of the team check it, comment it and approve. It allows a dialogue between different developers and teams (The Economist have three teams across the globe) and means that the code is generally bug free and robust when it goes live.
The theme
According to one of the devs, the theme for The Economist is possibly one of the most complicated themes they’ve ever seen. As a base, the theme uses a modified 960 grid system. They use modular CSS to ensure that unnecessary CSS isn’t left on the live site when they need to take the module down. The downside of this means that they have a ridiculously long list of CSS files and that because of some of the modules, they have duplicate CSS files throughout the site. In the future, The Economist are working on HTML5 semantic markup and responsive design, to make the site work well on all devices.
Testing
The Economist use Selenium for system/functional testing, SimpleTest for unit testing, as well as hand testing in all environments. Grinder takes care of load testing, and finally there’s team sign off before each release (using LaunchPad). They use PHPUnit to fire off the Selenium tests and the version of Grinder they use is a slightly modified version.
Hudson/Jenkins
Hudson/Jenkins, or Hudkins as The Economist calls it, is basically a way to run code on the command line, including drush commands. It’s used by The Economist because they found using Cron as inelegant, due to the fact that if something failed, nothing runs behind the failed task. However, with Hudkins, it does it on a per process basis, which makes everything a lot less buggy.
Infrastructure
Coming from the customer side, we use the CDN to deliver all the content. From there it goes to the load balancer level, 2 varnish servers to cache, then a memcache layer and 4 database nodes. The structure is exactly the same as the stage environment, as well as a disaster recovery environment. Jenkins is then used to deploy everything between the different environments.
Performance
When you have to scale your website, you figure out that things like memcache and master slave are essential. The Economist use a modified release of Drupal 6 called Pressflow, that comes with things like master slave already installed. Basically, the key to scaling is many levels of caching. Another thing that The Economist team have been playing with and will continue to use is ‘Edge-side includes’, that allows you to handle caching differently by caching portions of the page.
Question and Answer
Q: How many modules are you using on the Drupal site?
A: Around 40 or 50 contributed and custom modules altogether, with a 30/70 split.
Q: How does subscriber based service affect performance?
A: They’re really just authenticated users. However, it’s a really small percentage who come through as logged in users, so therefore performance isn’t affected. If it did go up, we’d have issues with performance and we’d need to readdress.
Q: What tools do you use for project management?
A: we use Scrum as the project management system, but in terms of tools we use Google Docs for spreadsheets and wikis. We’ve tried other tools, but we found they took too much time to update. We also use lo-fi physical taskboards with post it notes in some offices, which means we don’t spend a lot of time updating a tool and more time everyone talking together. With the Austin team, because a lot of people work remotely, we use the task board in Google Docs.
Q: How do you work with estimations?
A: We use the concept of story points within Agile Scrum. Instead of falling into the trap of estimating days, we work out what the story is. We then give them each relative sizes and then take in a certain amount of points. It gets it out of how many hours, and more in relative effort.
Pingback:A DrupalCon Flavoured Wrapup - Ubelly