The aim is to create a staging setup which will allow continuous deployment for Drupal, which is something of a challenge in itself.

In this setup, I create three drupal installations (production, staging and development), all under git version control.

  • Here, I’m using the dev site as the canonical origin.
  • The staging site updates from that dev origin
  • The production site updates from the staging site.

Clear?

Contents

Git + Drupal basic setup

Guides

Git Basics

Git + Drupal

How-to

  • Set up a new site in ispconfig with:
    • PHP (not safe_mode)
    • Mysql databases
    • ssh access (preferable)
    • a new admin user for each site with ssh access for all accounts (preferable – not sure how to do this without that)
    • create a database for each site, note down dbname, usernames, passwords etc.

ssh to the web server

$dev-user sudo apt-get install git-core
$dev-user cd ~/ 
$dev-user git init
$dev-user git clone  http://git.drupal.org/project/drupal.git fooproject
$dev-user git checkout 7.0
$dev-user '''git remote rename origin drupal'''

Problem: http://drupal.org/node/803746 recommends ‘git remote rename origin drupal’ which throws an “error: Unknown subcommand: rename”. I found advice here: http://groups.google.com/group/github/browse_thread/thread/d17dba902727fff4 to edit .git/config (at the project root) and just make the name change manually. That worked fine.

$dev-user git remote add origin path/to/your/central/git/repo
$dev-user git checkout -b fooproject

on ISPconfig, I had to move the ‘fooproject’ directory to the pre-determined server path :web – but that worked fine, and I think Git is still happy with where the files are…

I also had to edit the .htaccess file (Ispconfig doesn’t gives us a 500 server error). I replaced the existing .htaccess with:

<IfModule mod_rewrite.c>  
RewriteEngine on
#RewriteBase /  
RewriteCond %{REQUEST_FILENAME} !-f  
RewriteCond %{REQUEST_FILENAME} !-d  
RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]  
#RewriteCond %{REQUEST_URI} !=/favicon.ico
</IfModule>

Then, I cloned the sites to the staging site, making sure to retain the error log directory used by ispconfig by default:

$staging-user mv ~/web/error ~/ (move the error log dir out of the way)
$staging-user rm -rf ~/web 
$staging-user 
$staging-user  git clone /path/to/production/repos web
$staging-user mv ~/error web/

I then repeated the process for the ‘production’ site, making sure it gets cloned from the staging site, not directly from the dev site.

Then set up and configure sites . At least that was easy!

Now we try it out, by installing a module:

$dev-user cd ~/web/sites/all/modules/
$dev-user wget http://ftp.drupal.org/files/projects/views-7.x-3.0-beta3.tar.gz
$dev-uesr tar -xvf views-7.x-3.0-beta3.tar.gz
$dev-user rm views-7.x-3.0-beta3.tar.gz
$dev-user git add views
$dev-user git commit -m "added views 3.0 beta"

then login again as the staging user

$staging-user git pull

And it should just pull down views nicely.

That’s our git repositories and Drupal instances set up, now we have to think about Staging.

Staging Setup

Staging is a significant issue with drupal

Guides

Process

drush install poormanscron