Deploy vs Publish

There are many ways to deploy a new version of a web site. If it’s a web app, you normally want to use a complete deployment solution like Capistrano or Moonshine. But if you need to update a static HTML site or a simple PHP site, you usually just need to upload the changed files. This is often referred to as publishing as opposed to deployment. There are obviously several ways of doing this. Many file transfer apps have synchronization features. Publishing features can also be found in many editors/IDEs.

The Pain of Publishing

I’m a simple man. All those fancy publish/sync features always seem to be a hassle or else they’re built-in to a less-than-ideal coding environment (I’m looking at you, Coda and Espresso). Editing in Textmate and dock-sending to Transmit is about as fancy as I get. No sync. Just uploading files. The problem is, it’s hard sometimes to keep track of all the updated files that need to be uploaded once a new page is added, feature is complete, etc. Git knows what’s changed (if you’re not using Git or some other SCM, you should be), but going through the logs is a pain.

Gitup and Go

So, yesterday, I wrote a Ruby script to do simple publishing. It’s called Gitup. You tell Gitup which Git commits you want to publish, and it finds all of the changed files and sends them to Transmit. If you have Transmit’s dock send feature set up, Transmit will upload the files to the appropriate server and directory. Gitup will even let you preview the list of files that it plans on uploading.

It’s super-simple and quick. Much quicker than any ‘publish’ feature I’ve seen.

Examples

Send files modified in the last commit to Transmit (Gitup will let you know how many files will be sent and offer you the option to view a list of the files or abort.):

gitup

Send files modified in the last 3 commits to Transmit:

gitup -3

Send files modified in the last 3 commits to Transmit immediately (no prompting or anything):

gitup -s -3

Send files modified since yesterday to Transmit:

gitup --since=yesterday

Send files modified since Monday to Transmit (quotes are required):

gitup --since="last monday"

Send files since the specified commit to Transmit:

gitup dcd2c68..

Open files added/updated between the two specified commits in Textmate:

gitup --application=Textmate dcd2c68..bf75dd6

Disclaimer

Please note that Gitup is brand new. It could be buggy. I’m just sayin’.

If you have a Media Temple (dv) vps server account with Ruby¹ installed and root/sudo access, you can use my handy-dandy script to create instant email aliases for any of your hosted domains.

Usage²:

sudo ./alias.rb email_alias@hosted-domain.com recipient@anydomain.com

That’s it. 5 seconds and you have a new email alias. No Plesky mess involved.

I even aliased my alias script in my .bashrc file:

alias ealias='sudo ~/alias.rb'

The Backstory (and how the script works):

I use a lot of email aliases. I rarely give out my real email address. I usually create an alias that forwards to my real address. For example, if Amazon.com thinks my email address is amazon (@ my domain.com). That way, if I ever start getting spam, I know who gave away my address, and I can just delete the alias.

I use Media Temple’s Dedicated Virtual (dv) hosting plan. The Plesk control panel is kinda limited (and a pain) when it comes to creating lots of email aliases. I’ve yet to find a way to create an alias that forwards to an external email address, and any alias creation takes a crapload of mouse clicks. So, I decided to figure out a simpler way. After looking under hood, I discovered qmail. I didn’t know a thing about qmail, but I was willing to do some research to get to a solution for my alias thing. It turns out, qmail has kind of a neat way of dealing with aliases: for each domain, there is a directory. Each file in this directory represents an email alias³. The files are named thusly: ‘.qmail-alias’ where alias is the actual name part of the alias address. The contents of the file consist of the actual recipient addresses (prefixed by & and separated by newlines). So, a file called .qmail-amazon in /var/qmail/mailnames/postpostmodern.com that contains my real email address, prefixed by an ampersand, would be all that is needed for a functioning alias. All my script does is parse the input to figure out the name of the file, the contents of the file and where to put the file. Then, of course, it just creates the file.

The nice thing about qmail’s system is that the files are utilized instantly. There is no reloading of alias info or anything. It just works.

Oh, and adding a bash alias like this:

alias emails='sudo ls -a /var/qmail/mailnames/hosteddomain.com/'

will give you a list of existing aliases.

1. Yes, I could have used Bash or something, but I’m more comfortable with Ruby, okay? ↑ back up there
2. Please adjust the shebang line for your ruby installation. And don’t forget to chmod the script so it’s executable (755)! ↑ back up there
3. There are also subdirectories for each real email account. ↑ back up there