• As a web professional, I’ve had to find my own route to get to this point, so I make no warranties about the accuracy of this information as it pertains to your setup, hosts, etc.
• I’m using a very specific set of software and services that work for me. Naturally, there are alternatives out there that may be better suited to your needs.
• As such, I can offer suggestions should you need them, but cannot and will not offer my services repeatedly as “support”.

Part 1: The Tools

I design my sites primarily in Photoshop, and when specialized tools or techniques are needed, sometime Illustrator. There are four main pieces of software that I use for web design and development, on the coding side.

1. Transmit for basic FTP.
2. Coda for hand-coded HTML and CSS.
3. MAMP for local Apache/PHP server.
4. Headdress for virtual hosting in a local environment.

Part 2: Web Services

Hosting. I use MediaTemple as my host. They’re very reliable and have some great features that ease the pain of having to configure sites with sophisticated backends. This author assumes that the reader knows the basics of establishing hosting, domains, FTP, etc.

Version control via Beanstalk, and specifically their Subversion (SVN) hosting. This aspect is essential in my workflow, especially for syncing sites between computers, but also as a backup and revision mechanism for working with other designers and developers. I can’t imagine how I managed to maintain sites prior to using SVN.

With Subversion, you’ll need to learn some new lingo, i.e. “repositories” and “commits”. Because we’re going to be using Coda, I’m not going to delve into all the command-line pokey-jiggery you’ll need to know in Terminal, but at some point it wouldn’t hurt to acquaint yourself with that, either. The short version is that your “repository” will function very similarly to your site root, and it has its own structure based on Subversion best practices. A “commit” is a lot like FTPing your files up to a remote server. The converse act, or pulling down files, is called “updating”.

For my graphic files, I use Dropbox. I don’t know entirely why, but I like the service and they’ve got apps for iPhones and Android phones so you can email files to people if you need to. It’s automatic and effortless, and while I probably should be using Subversion to manage those files, I like the fact that Dropbox saves to the cloud when I save in my graphic apps. However, there is a service constructed around SVN + Photoshop files called Timeline. Check it out.

Part 3: The Breakdown

Let’s start from the bottom and work up. You’ll need to have Headdress and MAMP installed, as well as Coda and Transmit for moving files around. Any site you develop on the Mac using my methods will need to be stored in the ‘Sites’ directory of your user’s ‘Home’ folder. These local directories for each site are referred to, in the context of SVN, as “working copies”.

The next critical step is to configure Headdress to use the httpd.conf file generated by MAMP. The two most important aspects of these two pieces of software working in conjuction with each other are that we can now see PHP files and includes rendered out in our browsers without having to FTP them, and that we’ll have site-specific local URLs that get generated each time we add a site in Headdress.

When you start working on a new site, you’ll naturally want to name the root folder of that site after the client or even the project name. You’ll need to consider this carefully as it will affect how your SVN commits work out. My rule of thumb regarding this approach is this — if you’re building a full, standalone site for a client that should get its own repository. If you’re doing a bunch of emails, landing pages, and microsites for the same clients you can lump all those into their own repositories and respective working copies.

On the web service end, you’ll need to log in to your Subversion hosting site, and create a repository. You should at least do this immediately after creating a local root folder for the working copy, but DEFINITELY prior to adding a more robust file structure within said working copy. In my case, Beanstalk will generate three folders within each repository — branches, tags, and trunks. The trunk will be used for housing the main code base, while branches are used for the type of versioning where you may get really divergent copies of a given code base. Bringing those back together into the trunk is called “merging”. We won’t be exploring that process quite yet as I haven’t done it!

Now that we have our basic SVN file structure, we’ll move into Coda and make sure all our hosting details are in order. When it comes to choosing your local folder, you’ll always want to choose ‘trunk’ within a project root. Not doing so can have some serious ramifications later down the road and fixing a broken SVN repo is not fun. While we’re at it, let’s get those same details plugged in to Transmit so we can administer the files in a more effective hands-on fashion if need be.

In Coda we’ll take this opportunity to sync up our SVN repo to our working copy, and this will allow us to start adding files within the correct workflow.

See, that was easy!

We’ll also go ahead specify our working copies as local sites in Headdress. It’s as easy as locating your ‘trunk’ folder and giving it a name. You’ll also want to start and stop MAMP if it was already running.

Now, we’ll start adding some files in Coda (I’ll use a simple plugin called CreateProject). We’ll commit that to our SVN repo and check the files in Beanstalk. Yep, they’re there!