I guess the reason the guys behind roots kept the Capistrano script is that it is a more mature piece of software then Ansible. Remember also that an important idea behind the “roots philosophy” is the 12 factor app. Meaning Capistrano is in line with the philosophy as a mature and tested piece of software, while Ansible is quite young and at times buggy. There are other benefits to Capistrano over Ansible (as I have understood it) such as being able to roll back a deploy etc.
There’s two good philosophies that often contradict:
Use the best tool for each problem
Minimize tools (and complexity) by standardizing on one
We went with Capistrano because it’s good at what it does, and specialized for deployments. Downside to it is obviously having to know and deal with the Ruby/Gems ecosystem.
Ansible can easily, and maybe should, do your deployments. I’ve thought about this and looked into it. And it may be something we do in the future. There’s a guy who created roles in Ansible that pretty much replicate Capistrano exactly. https://github.com/nicolai86/ansible-rails-deployment is kind of Rails specific but in the README it’s just a wrapper for two more generalized roles he’s made.
I quite enjoy the Ansible approach to things and am going to explore using it instead of Capistrano for a few reasons:
– it gives excellent output + logs when executing
– I find it far easier than Chef / Puppet to create and mix roles / playbooks
– Eliminate not only another tool, but another language (Ruby) that has irked me in the past.
– Reading more about Ansible Architecture seems like this is a growing track of use