失敗する前提でデプロイする

うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか．
たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある．
tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる．
デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした．

デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る．

ヒント：戻すときは以下のコマンドを実行しましょう
cap -S revision=deploy/2014-01-31-15-17 deploy

実装方法としては，こんな感じに，デプロイ前に最新のタグを取っておくという感じ．

latest_tag = `git tag`.split("\n").sort.last
# (ここでデプロイしてタグ切る)
puts "ヒント：戻すときは以下のコマンドを実行しましょう"
puts "cap -S revision=#{ latest_tag } deploy"

こういうのは機械が案内してくれると安心できる．
失敗する前提というと悲観的な感じがするけど，たとえばシートベルトとか，楽しい旅なのに車がぶつかる前提というのは悲観的で不謹慎とか言う人いなくて，車ぶつかって死ぬのと生きてるのなら生きてるほうが得だと思う．
GitHubのRelease機能を使えばもうちょっとかわいくできるかもしれない．GitHubにRelease機能できる前からタグ切る運用してる．
Blue Green Deployしてれば，前のインスタンスにつけかえるだけなので，もっと簡単に戻せると思う．

追記

ブクマで、deploy:rollbackじゃだめなのっていうコメントがついてた。それでロールバックできるならそれで良いと思う。それ以上のことはしてない。うちのチームでは変にCapistrano改造して使っていて、deployタスクも手で書いたのを使ってる。なので、rollbackとか、使えないつもりで、手でこういう仕組みを作ってしまった。
便利な生態系が提供されていたら、なるべくそれに乗っかるべき、という話だと思う。レールに乗りたい。

さらに追記

今日思ったけど、deploy:rollbackは、開発者向けのインターフェイスで、そのなかではレールに乗っかった人向けにあれこれやっていて、うちのdeployは高速化のために複数プロセスを立てて全部終わるまで待つとかやっていていかにもレールに乗れないか、慣れてたら、いや、それくらいのレールの外れ方なら、まだdeploy:rollbackに乗れる、とか述べることができるけど、ハックしてdeployを並列化した時点で、効率化のためにレールから外れてるので、普通の人には戻れないと思う。今戻れるとしたら、偶然内部の実装がまだ互換性を保っているということだと思う。これも詭弁で、deployを書き換えているのだから、ある日どこが壊れても文句言えない。