Regarding cuisine vs. Chef Solo... I think it mostly depends on what your scripts do. In my opinion, Fabric/Cuisine make it absurdly easy to execute commands against a remote server and most of the time that's enough for a decent deployment. Chef's execution API is, to put it mildly, clumsy. I cringe every time I have to type something like:
execute "#{virtualenv_dir}/bin/pip install -r #{requirements_file}" do
user deploy_user
group deploy_user
end
IMO Chef shines when you have to move a lot of config files and generate node- and role-specific configs. I feel it's a lot simpler to just have recipe-specific files and templates packaged with the recipe and move them over with commands like cookbook_file and template.
Right now we are using both the technologies. Our stacks are Chef-based since we want people to be comfortable with reading (and possibly modifying) its code. We also reuse a lot of the Opscode recipes which simply do not exist for Fabric/Cuisine. Fabric and Cuisine have their place when we bootstrap a server and prepare the Chef environment and at several odd places where they keep things running together.
execute "#{virtualenv_dir}/bin/pip install -r #{requirements_file}" do user deploy_user group deploy_user end
IMO Chef shines when you have to move a lot of config files and generate node- and role-specific configs. I feel it's a lot simpler to just have recipe-specific files and templates packaged with the recipe and move them over with commands like cookbook_file and template.
Right now we are using both the technologies. Our stacks are Chef-based since we want people to be comfortable with reading (and possibly modifying) its code. We also reuse a lot of the Opscode recipes which simply do not exist for Fabric/Cuisine. Fabric and Cuisine have their place when we bootstrap a server and prepare the Chef environment and at several odd places where they keep things running together.