Chef is growing stronger every day and after reading that Engine Yard has decided to drop their Capistrano based deployment process, I found myself thinking about mapping between Capistrano e Chef…

Chef’s stock deploy resource is approximately equivalent to Capistrano’s deploy task (or deploy:migrations, both with the remote cache strategy thrown in): some things are done in a slightly different order, but the results are largely the same. Even if the process is particularly suited to Ruby on Rails applications, it’s general enough to be usable with other type of web applications. Engine Yard’s deploy resource is quite different from Chef’s one, but the principles are the same.

A key difference between Capistrano’s standard recipe and Chef’s stock deploy resource is that the latter is not so flexible as the former: you can tweak the resource behaviour via a given number of attributes and you have another given, small number of spots where you can insert custom code via callbacks; with Capistrano, you can insert callbacks pratically anywhere. When switching from Capistrano to Chef you are obliged to rework your custom deployment recipes, eventually merging or rearranging your callbacks.

So, roughly speaking:

• whatever you ran before deploy or deploy:migrations, before or after update_code and before or after finalize_update in Capistrano, now you must put it in Chef’s before_migrate callback;

• whatever you ran after migrate and before symlink in Capistrano, now you must put it in Chef’s before_symlink callback;

• whatever you ran after symlink and before restart in Capistrano, now you must put it in Chef’s before_restart callback;

• whatever you ran after restart or after deploy:migrations in Capistrano, now you must put it in Chef’s after_restart callback.

Don’t bother adding code equivalent to Capistrano’s deploy:cleanup task: Chef’s stock deploy resource already cleans up after itself, keeping a small, fixed number of deployed releases (5, at the moment).