# Deploy Strategies for HerokuSan

May 12, 2012

If you look at the network graphs of heroku_san on github, you'll see a number of branches where the only change is the deletion of the following line from the deploy task:

If more than a few people are willing to take the effort to fork a gem just so they can delete 1 line, something smells. The reason is that these forkers were using something other than Rails+ActiveRecord+SQL in their project. Some were using Sinatra, others were using Rails, but with CouchDB.

The raison d'être for the heroku_san gem is to make Heroku deploys dirt simple. So, if people are making whole forks to customize the deploy task, we should make it less painful.

## Enter strategies

Strategies are an object oriented programming pattern for creating pluggable execution control. Now, there is a new class of objects that inherit from HerokuSan::Deploy::Base. These objects control how deploys are executed for you. The Rails strategy, HerokuSan::Deploy::Rails does exactly what HerokuSan has always done:

• push to git@heroku.com
• call rake db:migrate
• restart

On the other hand, the Sinatra strategy, HerokuSan::Deploy::Sinatra does nothing more than the base strategy:

• push to git@heroku.com

You can create your own strategies and then configure HerokuSan to use it instead of its default:

## Rails 3 projects

Amend your Rakefile:

## Sinatra (and other Rack based apps)

Amend your Rakefile

Deploy Strategies for HerokuSan - May 12, 2012 - Ken Mayer