tellmetwin.com is backed up automatically to two different countries and yes the backups are tested.

http://factoryjoe.com/blog/2009/02/16/what-really-happened-at-magnolia-and-lessons-learned/

http://www.youtube.com/watch?v=Ik66THWLlM4

With Drupal or any other similar system you are going to wind up with a lot of CSS, and for the most part you want this to be cached by the user to speed up load times. However when you deploy new code, you definitely want the CSS to be refreshed.

To address this issue we take advantage of a browsers default behavior of not caching files with different names by adding a query to the end of the css call.

Our basic approach is to have the build number or revision somewhere and insert that into our CSS calls.
We first define a variable in index.php at the root of the project with a token that ANT will replace with a build number.

This is what is in my index.php file:
define('BUILD_REVISION', '@build-revision@');

The ant task looks like this:

replace file="${temp.dir}${cache.buster.file.path}" 
            token="@build-revision@" 
            value="${Revision}"

Revision is from Subversion.

Whenever we call a CSS file we need to reference the constant we just defined for example:

<link rel="stylesheet" href="<?= base_path() . path_to_theme() ?>/css/sugababes.css?< ?=BUILD_REVISION?>" type="text/css" media="screen" />
</link>


Now whenever you do a build a revision is added to the end of the CSS call.
/css/sugababes.css?420247

The browsers will now update the CSS file whenever you deploy a new version of the project.

If you just do a SVN checkout or do not use ANT on your workstation copy, everything will still work fine you will just have the token rather than the build number appended to your CSS.

There may be an alternative method where you extend drupal_add_css to automatically append the token and if you are using Drupal long term you should probably investigate that

Doing ANT deployments is a great way to leverage some XP programming methodologies, but most importantly it allows you to do deployments to different environments in one step, making screw ups less likely.

Let’s assume you have some developers with a full version of the application on their workstations and you have a qa and production environment. You also store all your files in version control (we’ll use subversion because its the most common). If your not using version control… well you really should do that before you do any builds!!!!

We want ANT to do everything for us, checkout from subversion, do some configuring, then copy everything to target server. So lets get started.

Here is an outline of what we are going to do:

1. Get Drupal Ready
2. Get ANT Ready – set up with dependencies
3. Create environment specific property files for ANT
4. Create ANT build.xml file

Get Drupal Ready

First thing we need to do, is add a folder build to the root of our drupal project. This folder will hold our properties files and the build.xml file. We will also need to create the necessary settings.php files for each environment. I like to store these in version control and have ANT deal with copying/renaming the right one. Below is a screenshot of what my Drupal project looks like:

The setting.php files have all the environment specific settings. settings.php should not be entered into version control as each developer will have specific settings. As part of their local workstation setup they should copy settings.php.example to settings.php and customize as they need to.

Get Ant Ready

Go ahead and install ANT from the apache website, you will also need these libraries:

1. SVN ANT – allows you to checkout from subversion from ANT
2. JSCH JARS – allows you to SCP and do other nifty things

Make Your Properites File

We are going to use property files to store all the values that ANT will use for the project. Use a different one for each environment (see above screenshot). Here are the values contained in mine:


# -----------------------------------------------------------------------------
# build.properties
# This file is referenced by the build.xml file.
# -----------------------------------------------------------------------------

Create your build.xml file

Here is a basic outline of what we want ANT to do:

We will want our ANT build script to do the following:

1. Checkout Project from Subversion
2. Cleanup Project & Configure For Target Environment
3. Add A Revision Number & Timestamp To A Specific File
4. Zip Up The Build
5. Securely Transfer and Extract The Build On Target Server

To be slick, we will pass the following paramters into ANT on the command line:

1. Target Environment
2. Subversion Revision For Build (or HEAD)
3. Username and Password for Target Environment – dont store this info in the properties file.

For ANT, this is an example of what I want to type in:

ant build-drupal -Denv=qa -Drevision=HEAD -Duser=benny -Dpass=xxpassxx

That should be all to do a build, what environment do you want to deploy too, what revision do you want deployed, what is the username and password to login.

Here is my ANT target to checkout from subversion:

<property file=”build.properties.${env}” />

<path id=”project.classpath”>
<pathelement location=”${svnjavahl.jar}” />
<pathelement location=”${svnant.jar}” />
<pathelement location=”${svnClientAdapter.jar}” />
</path>
<typedef resource=”org/tigris/subversion/svnant/svnantlib.xml” classpathref=”project.classpath” />
<target name=”checkout”>
<svn username=”${svnant.repository.user}” password=”${svnant.repository.passwd}”>
<checkout url=”${svnant.project.url}” revision=”${revision}” destPath=”${temp.dir}” />
</svn>
</target>

Note the ${env} syntax, this is how you pull in values from the command line. For example I want to type the following to ant ant deploy-drupal -Denv=qa and then will use the qa value to get the right properties file.

Below is the task to insert the build number into the footer and to bust any CSS cache:

<target name=”revisionnumber”>
<svn>
<status path=”${temp.dir}” revisionProperty=”Revision” />
</svn>

<tstamp />
<!– For CSS Cache Busting Constant in index.php –>
<replace file=”${temp.dir}${cache.buster.file.path}” token=”@@@” value=”${Revision}”/>
<!– For Info In Footer –>
<replace file=”${temp.dir}${comment.file.path}” token=”@@@” value=”Revision: ${Revision}, Build Date: ${DSTAMP} : ${TSTAMP}”/>
</target>

Below is the target to copy the correct settings file:

<target name=”populateRelease”>
<move file=”${temp.dir}/sites/default/settings.php.${env}” tofile=”${temp.dir}/sites/default/settings.php”/>
</target>

These two targets zip and scp the file:

<target name=”zipRelease”>
<mkdir dir=”${build.dir}”/>
<zip destfile=”${build.dir}/FILE-NAME_${revision}.zip” basedir=”${temp.dir}” />
<antcall target=”clean”/>
</target>

<target name=”deploy”>
<scp file=”${build.dir}/FILE-NAME_${revision}.zip”
todir=”${user}@${deploy.server}:${deploy.path}”
password=”${pass}”
trust=”true”
/>
</target>

Most importantly is this task that extracts the files on the target server, note that the Uploads and Files folders are not touched, since these contain user created data they are not stored in subversion and are not included in the build.

<target name=”extractConfigure”>
<sshexec host=”${deploy.server}”
username=”${user}”
password=”${pass}”
trust=”yes”
command=”cd ${deploy.path};
rm -R includes;
rm -R misc;
rm -R modules;
rm -R profiles;
rm -R scripts;
rm -R sites;
rm -R themes;
rm .htaccess;
rm robots.txt;
rm cron.php;
rm index.php;
rm xmlrpc.php;
unzip -o FILE-NAME_${revision}.zip;
rm FILE-Name_${revision}.zip;”/>
</target>

And thats pretty much all the pieces you need, the rest of the plumbing is standard ANT.