Drupal.org is a large site and faces the same challenges as any other site. Additionally, it is probably the longest-running Drupal site.
Code
We use BZR to get code from Drupal git to staging and production of 5+ individual sites.
Vendor branches keep a clean BZR copy of a project. For Drupal core, we add patches from Pressflow for scalability and performance.
The Drupal.org theme, the new one being Bluecheese, is managed directly in BZR. We don't distribute it to help keep our brand strong, so you will always know when you are on the official Drupal.org.
Many other projects support the *.drupal.org sites as well.
Notable modules include:
- drupalorg module contains our site-specific functionality and details.
- bakery enables single-sign-on across *.drupal.org sites.
Each site pulls in code from vendors and Bluecheese to fill out the file system. This is then checked out on each web server.
Database
Drupal.org's live database is regularly dumped and sanitized, email addresses, private keys, and caches removed. This can be used to set up staging sites, such as redesign.drupal.org. All data changes must be done by users or code on the live site. Each *.drupal.org site has similar processes, using database copies as needed for projects.
Management
This is all automated as much as possible with Jenkins. This ensures that actions are done are documented, consistent, and logged. A few tasks include:
- deploy - push code from BZR to a server
- verify - check if there are any changes not checked into BZR
- snapshot - make a sanitized database copy
- backup - creates the backup
- mk_query_digest - profile slow queries.
- update_git_vendor_branch - copy code from Drupal git to BZR.
Jobs are named with their purpose and then the site name. So, deploy_denver2012.drupal.org will deploy the code from bzr to the denver2012.drupal.org site.