Hello! ☞ This is an archived version of Al Shaw's personal website. The current site is http://shaw.al.
I have spent a lot of time pasting things into textareas.
For a while, I thought that was the only way to make template changes. Make a change, command-C, command-V, save. This was fine for tweaks, but as I started making more substantial design changes over at TPM, it became clear I would need a more systematic way of keeping track of template code. There is a ton of template code at TPM. Each blog has its quirks, and even though there is a lot of modularity, there is also a lot of uniqueness. The front page is extraordinarily complicated, with over 60 templates alone! Shortly before embarking on the front page redesign, I got started with Subversion, and created a repository to keep track of the changes. Each time I made an edit, I would save the file and then copy the text of the file into the template box in MT. At the end of the day, I would issue a $ svn commit -m and call it a night. This is largely what I still do at TPM. While there are a number of problems with this workflow (not the least of which is apple key abuse), the biggest, and most potentially dangerous problem with it is that there is no way to be absolutely sure that you’re copying the right code into the right place. Short of extreme vigilance, every deploy is a disaster waiting to happen. And the only failsafe is to copy the existing code back into a text editor so you can quickly revert if you somehow fucked up. Needless to say, front page tweaks still make me very uneasy.
It was only when I was setting up this blog that I ran across this extremely useful article which introduced me to the ‘link to file’ field. Using this feature, which allows you to hardwire your templates to raw text files in your filesystem not only guarantees that you always know exactly what file you’re drawing from, it also allows you to deploy via your favorite version control software.
Enter Git. While there isn’t anything inherently wrong with SVN, I’ve recently started experimenting with Git, and really love its flexibility. Here’s how I used it to set up a fast deployment workflow for Shhhaw:
I started with a local folder on my PowerBook, and stuck all my templates in there. Running a quick $ git init created a Git repository to keep track of changes. Then I created a bare git repo on my web server: $ git init --bare (git doesn’t like to push right into repos with active working directories).1 This article has a good overview of setting up a remote repo. I connected my local folder with the remote one with $ git remote add bare ssh://url, and then pushed my code into it with $ git push bare master2.
From there, I ran a $ git clone on my web server to pull from the bare repo into a new repo, let’s call it mt-shhhaw-theme-working. I linked all these templates into a staging blog with the exact schema of my live blog and hit Publish All Files in MT. It looked good. Then I cloned that into a new repo called mt-shhhaw-theme-production which I file linked into the live blog’s templates.
As I see it now, the ideal workflow will be making changes locally, pushing them up to bare, pulling them down into the test site, testing, then pulling into the live site and hitting Publish All Templates. That seems about as instant a deploy as MT’s static publishing system allows. Next I’d like to look into setting up hooks to automate the publish process (at least on this blog) and adding query strings to updated static files. Hopefully after that I’ll never have to go into templates from the MT app again.
—
When I first came across it, the concept of a bare repo seemed very SVNish for Git. It really seems like they should allow you to push into standard remote repos, provided you have the right authentication, though I can see how it can wreak havoc if not done cautiously.
Turns out I should have called the remote branch “origin” instead of “bare.” If it can’t find an origin branch, git returns error: refs/reference-tmp/refs/remotes/origin/HEAD points nowhere!