Do not deploy when you don't need to!

Maybe you want to test all the fucking time, but you really don't want to deploy in the same manner. Let's say like when you do a git push origin refactoring_localized_mess_into_plugin. (Note: Do instruct your trigger-happy co-workers not to merge such stuff into the deploy branch.) You want to deploy only when there's some new stuff in the deploy branch and in this case only.

Updated Pushr does just that now. The check for „new stuff“ isn't as fine-grained (checking only for output of git fetch origin) as one would like, but seems to be working just fine. But wait! Sometimes you want to „force deploy“, particulary when a Mongrel goes crazy and isn't properly started after deploy. You can still do that in the web interface with the new force option.

This solved main gripe we've been having with Pushr, being forced to shut it down during some particularly „push heavy“ moments. Now it can stay up all night, not sending application to 500 Service unavailable due maintenance territory every 10 minutes. If you're not particularly crazy, you merge or commit into deploy branch only couple of times per day, so you should be fine.

I knew Pushr would need something like this from the start, but thanks goes to forker Jesse Wolf for kicking it firmly into my head and getting to it quickly.

Standard HTTP Basic authentication

While the previous authentication by token was „just fine“, it was really weird to authenticate the web interface in this way. And because Github recently got support for HTTP basic authentication for it's post-receive hooks, Pushr now supports HTTP authentication for it's web-service and web-interface parts. Thanks to support for HTTP-Auth Basic in Rack and thus in Sinatra-based applications, it was very trivial to implement.

More Capistrano configuration

While conventions really do help us achieving at least something in everyday life, sometimes less is simply less. Credit goes again to Jesse Wolf for kicking me into it -- Pushr now assumes you want to do cap deploy:migrations, unless you say otherwise. Why you would want to say otherwise, you ask?

There's one big reason: maybe you're not as hard-core as some, and want to deploy only staging/preview versions of your apps automatically. In such case, you certainly have Capistrano configured to work in „multi-stage“ mode. And you deploy different stages (configured in different files in your config/deploy directory) by calling cap production deploy or cap staging deploy. Now you can make that choice with Pushr.

One important note: from the beginning I wanted Pushr to be only a thin veil around Capistrano, which I love very much and which is unbelievably powerful and configurable (how else, you may ask, when you know it's author? :) That's why I very probably won't implement any logic belonging to Capistrano in Pushr, and think that things like „multi-app“ support really go in completely different direction. You should check Integrity for stuff like that.

Running Thin

Pushr now runs on Thin in production just the same time you unwrap it's foil. If you know Thin, you know it means it's very, very fast, stable and easy to configure. Pushr's Rake tasks were updated to reflect that, so you can now rake start and rake stop Thin on the server with most convenience.

My big thanks to everyone who linked to the announcement post and especially to those who have forked Pushr on Github! Send more ideas, „likes“ and „don't likes“ my way!