@madpilot makes

I recently read about the deployment model that Flickr uses. After picking my self up from the floor, it made me think about my own deployment methods, and I have started implementing a new system, which I though I would share.

First off all, let me describe the types of projects that I have to deploy:

1. Internal MadPilot or Personal projects – i.e. stuff hosted on the server at my house (which also doubles as my development server)
2. External projects that I can take a local copy of to work on
3. External projects that I am forced to work on “off-site” i.e on the clients server.

The deployment system I will describe here covers project type 1 and 2. Not much I can really do with 3, as I have no control over other people’s servers…

Most of the projects I work on, I’m the only developer, but the system described is designed to scale to multiple developers.

Step 1: Set up a subversion repository

I have my subversion repository structured as such: [svn_root]/MadPilot/Clients/[client_name]/[job_name]/

Because I do a lot of outsourced work, I use the job_name to denote different jobs for the same client. If the client is a one off (i.e. the client isn’t another web company) I will usually leave this off. The website code will be stored in the Website directory. This allows me to store documentation and other bits and bobs outside the development tree.

Step 2: Checkout the empty tree

Next I create development and test directories with in my webserver: usually of the form [web_root]/clients/[client_name]/[job_name]/dev/[developer_name] and /clients/[client_name]/[job_name]/test.

I then check out the empty subversion tree to all of the directories so that they become under source control.

Step 3: Setup the webserver

At this point I will set up a virtual host for the client of the form [developer].dev.[job_name].[client_name].clients.madpilot.com.au and test.[job_name].[client_name].clients.madpilot.com.au (Yes, this does end up with stupidly long URLS, but I prefer them to be descriptive. No one sees them other than the client anyway…)

Step 4: Import the initial tree

It is at this point I download the existing site, or start a fresh if it is a from-scratch job. I then add all the files to the repository.

Step 5: Setup any databases

I try to make sure that every developer has a separate database, so does the test system. Usually named [client_name_[job_name]_[development_name]

Using the system

When you start working on a project, you make sure you login to your working directory on the server (usually via SSH) and do a subversion check out. When you finish, you check your work back in. When the system is at the point of testing by the client, you check everything out to the test site.

Using subversion means that you have a versioned backup of all the code, and you can manage multiple developers and a test system at the same time.

Going to production

This can be the tricky bit. For projects on my server, I usually just do an export into the production directory. If the system was tested well enough, if should just work. Gotchas include paths to local files and permissions, but this should be documented anyway.

On external systems, this can be a little more difficult. At the moment, I export the code into a temporary directory, and manually FTP the files up. I hope to be able to automate this in some way, even if it will just reduce me typing.

Next thing to do is to write a nice web front end to subversion so I can do “one-click” deployment… Ahhh :)

So that is my plan – what does everyone else do?