At our company we maintain A LOT of Drupal sites, our current setup goes something like this:
- Every site's codebase has it's own git repo
- New features not likely to be stable enough for the next release get their own feature branch in git
The above I would say is fairly common for most Drupal sites.
What we do special at our company is debian package the sites for deployment using a custom drush command - 'Drush Debian Packaging'.
Drush Debian Packaging provides a Drush command for building Debian packages of Drupal sites as a means of deploying Drupal sites to Debian or Ubuntu servers.
Drush Debian Packaging utilizes the Drupal hooks system to build a Debian package that best fits your sites needs. Features include:
- Automatic virtual host configuration for Apache2 and Nginx webservers
- Cron setup in /etc/cron.d
- Automated code deployment with partition split for sites/default/files
- Automated configuration through the dpkg debconf settings tool
- Automated deployment process
- custom Git VCS handler for building packages from Git
What does this mean?
To build a release:
To deploy a release, first SCP the .deb to all web servers in the cluster. Then on all web servers run (you can use the linux package cssh to type the command to all servers in the farm at the same time):
sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb
On one web server run:
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron
Of course to roll back this is now trivial from a codebase point of view, simply install the previous version of the .deb to all web servers and rollback the database.
Happy to answer any questions about this