I recently worked on a PHP-based site and was getting tired of shifting files to the server via FTP so I decided to take a stab at utilising Capistrano to do the work for me.
The thing about Capistrano is that once you set it up, you generally never think about it again – so I had to do a bit of trial and error getting things set up for the PHP application.
This tutorial assumes your PHP application is served under the path ’/web/public/’. It is also assumed that you have already installed Capistrano.
The first step is to make sure you have your application stored in a Subversion repository. Next you are going look under your /public directory to see if there is anything that isn’t controlled by Subversion. Textdrive users may want to preserve the _ical subdirectory – and if you have a favicon.ico or .htaccess file that isn’t under Subversion, you’ll want to preserve those too.
Under the root of your local version of the application, you want to run ‘capify .’ from a command line. This creates the /config directory and the deploy.rb file underneath it.
After you modify the deploy.rb file with the correct login details of your remote server, then it’s time to prepare the remote server by running the command ‘cap deploy:setup’ from your local command line. It may prompt you for your remote server password. It sets up two directories (shared and releases) and modifies their permissions correctly.
Move any of the items (if any) you wish to preserve into the shared directory. This is a safe directory that never gets overwritten. We can later modify the deploy.rb script to create symlinks to items in the shared directory.
Then comes the scary bit where you delete the entire /public directory and everything underneath it. It’s OK though, in a moment, you’ll have a fresh copy of the application sent over from the Subversion repository. Now it’s time to do the first deployment. From the local command line (at the root of the application) run the command ‘cap deploy’ and respond to any password prompts along the way.
If all went well, you will now have a new Subversion checkout in a time-stamped directory under the /releases directory. You will now also have a new symlinked folder called ’/current’. But what about /public? Without a public folder the URL will fail. This is where we create a one-time symlink called ‘public’ pointing to the ‘current’ symlink which in turn points to the latest release. This symlink must be done on the remote side. SSH into your server and navigate to the /web folder where ’/releases’, ’/shared’ and ’/current’ now reside. Run the command ‘ln -s [path to application]/web/current [path to application]/web/public’. That should do the trick!
