Home/ Questions/Q 9138263
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T09:14:01+00:00

I’m moving from Capistrano to Chef to deploy a Rails app (with deploy_revision ),

  • 0

I’m moving from Capistrano to Chef to deploy a Rails app (with deploy_revision), and an issue of best practice (or common practice) is unclear to me. I haven’t found much through Googling around.

With Capistrano and the “push” model, when deploying an application across a number of servers, it’s straightforward to recognize when there has been a deployment failure and to rollback the deployment across all servers at once. Capistrano also puts up a maintenance page on each app server, then doesn’t take that maintenance page down unless I’ve either successfully deployed to all servers or rolled back the deployment.

With Chef and the “pull” model, each server may be fetching its updates at a slightly different time. I might wind up with the database server updating the application code and running database migrations several minutes earlier than the application servers. So I really don’t have a great way of identifying a failure and ensuring that the build is rolled back to the last successful deployed version (on all servers).

I know that I have some options here:

  1. Don’t daemonize chef-client. Run it nightly or hourly with cron. (I still can’t roll back across all of my servers in the event that some are successful and just one hits a problem.)
  2. Don’t daemonize chef-client. Don’t use deploy_revision. Run it via knife ssh or capistrano-chef. (I am now back to a “push” model instead of a “pull” model, which is part of the appeal of Chef.)
  3. Daemonize chef-client and write custom recipes that talk to each other. (Not enthusiastic about it.)
  4. Relax. Don’t worry about it. Let the errors happen and then fix them. (Not thrilled here, either.)

I could start building any of these, but before I invest a lot of time in building, I was hoping to learn what has worked for large deployments in the field. What have you done?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Pull is suited to addressing the problem of configuration drift. For deployment on demand (and potential rollback), push is better. Check these out (I haven’t used them):

    https://github.com/etsy/deployinator

    http://www.rackspace.com/blog/rackspace-open-sources-dreadnot/

    • 0