One inevitable activity in any web application is updates. I am always refactoring code, adding new features, and improving existing features. I get everything working the way I want in my development environment and then need to deploy the changes. Typically, that deployment has three components: update the scripts via subversion, modify the database, and use php to update database records.

To address this problem, I want to create a lightweight patch system for my applications, and the developerBlog is a good target for experimenting with this idea. Below is a skeleton of the directory strucuture I want.

Directory Listing: /dblog/shell

/dblog/shell
    apply_patch.sh
    conf/
        sh.conf.dist
    php/
        constants.php.dist
    sql/

The patch components will reside in an applicable directory. For example, a patch (that I will arbitrarily name 2.1) has only an SQL component. In that case, there should be a file called 2.1.sql in the sql directory.

I envision a couple configuration files. One (conf/sh.conf) helps apply_patch.sh execute the right versions of PostgreSQL and PHP, and identifies the paths to key directories. The second configuration file (php/constants.php) bootstraps the Istarel Workshop Frameworksto to any PHP script so that I have complete access to the framework and application class hierarchies.

Subversion

Notice that the configuration files both end in .dist. The idea here is that I want to be able to run the patches in my development, staging, or production environment. Clearly, the path and program names and paths are likely to be different in each environment, but I want to have these distributed versions available as guides. Thus, the skeleton as shown is made part of the subversion repository for the project.

markf$ svn add shell
markf$ cp shell/conf/sh.conf.dist shell/conf/sh.conf
markf$ cp shell/php/constants.php.dist shell/php/constants.php
markf$ svn propset svn:ignore sh.conf shell/conf
markf$ svn propset svn:ignore constants.php shell/php

In order for the local environment constants to be respected, I make sure that sh.conf and constants.php are not part of the subversion repository.

Patch Application

The name of the patch will be passed as an argument to apply_patch.sh. The shell script then executes a subversion update for the frameworks and the application. If there is an appropriate SQL or PHP patch, those are applied as well.

Listing: /dblog/shell/apply_patch.sh

#!/bin/bash
. conf/sh.conf

# identify the patch being applied
if [ ! $1 ]
then
    echo "Patch not defined"
    exit
fi

# apply subversion update to framework
echo "Updating framework via subversion..."
cd $FRAMEWORK_DIR
svn up

# apply subversion update to application
echo "Updating application via subversion..."
cd $PROJECT_DIR
svn up
cd shell

# apply database patch
if [ ! -f sql/$1.sql ]; then
    echo "No database patch component"
else
    echo "Applying PostgreSQL patch component..."
    $PSQL -q -U $DATABASE_USER -f sql/$1.sql -d $DATABASE_NAME
fi

# apply PHP patch
if [ ! -f php/$1.php ]; then
    echo "No PHP patch component"
else
    echo "Applying PHP patch component..."
    $PHP $PROJECT_DIR/shell/php/$1.php
fi

This is a bare bones approach to the problem, and future work may require me to chance its structure. For example, I may want to add a switch that tells the script to ignore the step for updating the framework. A subsequent blog entry will demonstrate how to apply an actual patch to the developerBlog.

If I were always going to use Apple's file sharing to connect to my development server, I would never have to expose my subversion repository to the network. However, I like to have my laptop serve as a mobile development server. Previously, I performed my own synchronization of websites. Subversion provides a more elegant solution.

Starting the Subversion server

One powerful feature of subversion is its server, which makes networking easy.

markf$ svnserve -d 

With the server now running, I can now check out repositories across the network by providing full path information to the particular project.

fenoglma$ svn co svn://10.0.1.225/Library/Subversion/bnr
fenoglma$ svn co svn://10.0.1.225/Library/Subversion/fw

A later blog entry will talk about the changes necessary to permit commit actions from these remote repositories.

To help maintain a consistent code base for the myriad projects in which I'm involved, I decided to create a subversion repository on my development server.

Creating the Repository

The developers of Subversion (http://subversion.tigris.org) offer a series of recommendations for organizing a subversion repository, but I am taking a much simpler approach (for the time being).

markf$ sudo mkdir /Library/Subversion
markf$ sudo svnadmin create /Library/Subversion/
markf$ sudo chown -R markf:staff /Library/Subversion

Populating the Repository

I begin with the Istarel Workshop Application Frameworks itself. On the development server, the web applications will reside in /Users/markf/Sites. Subversion allows both local and networked connections. The frameworks in its current state (and located in ~/Documents/fw) will be utilized to initially populate that project in the repository.

markf$ sudo svn import fw file:///Library/Subversion/fw -m "Initial state"

With the project (fw) now in the repository, its web server location can now be initialized.

markf$ cd ~/Sites
markf$ svn co file:///Library/Subversion/fw

The first project used to test the new frameworks is the Big Nerd Ranch 3.0 website. This too will be made part of the subversion repository.

markf$ cd ~/Documents
markf$ sudo svn import bnr file:///Library/Subversion/bnr -m "Initial state"
markf$ cd ~/Sites
markf$ svn co file:///Library/Subversion/bnr

Committing Changes

Subversion needs to know which editor should be used when changes are committed, so I create ~/.profile with the contents EDITOR=vi.

Those Pesky ._ Files

One hazard of using Mac OS X for web development is the potential proliferation of ._-prefixed files. Normally, they remain out of sight and out of mind. Subversion, however, keeps an extremely watchful eye on a folder's contents and will flag these files as unknowns when checking the project status.

I had little luck with svn:ignore and wildcards, so whenever the OS X detritus files rear their ugly heads, I use a simple unix command to purge my project directories of them.

markf$ find . -name "._*" -print0 | xargs -0 rm -rf