deprec is good, but needs taming.

Sharad Jain, Friday, January 23, 2009 @ 5:59 pm

I recently had to work on some deployment tasks and used deprec gem to check out how it can help. deprec is one of the most admired gem outside of pure rails application deployment arena. It is one of the most successful attempts at demonstrating how capistrano can be used as a more generic deployment tool and not just for deploying rails apps.

However, there are a few design choices that I think warrants more thought if I were to continue to use it successfully for all my deployment needs.

• Deprec modifies your global settings: Deprec modifies your default capistrano environment to always load itself under all environments (for details: look at how it modifies your ~/.caprc inside /bin/depify command). With this, it effectively adds before/after hooks (extentions) to your default rails deployment tasks like deploy:setup, deploy:symlink. The extensions may or may not be acceptable in a particular scenario. For example, it tries to be nice and update user's group/permission to allow for smooth deployment. It may not be acceptable to me as an admin and I may like such one-time task to be manual. At the very least, I need to validate that those extensions are valid for all my deployed apps. I think, deprec should not modify .caprc in this way. Limiting it to non-rails apps, where one would use 'depify' command instead of 'capify' would probably be acceptable.
• Pick and choose the extensions I need: Deprec provides a lot of recipes out of the box. However, including them all (require 'deprec') may not be what you need, at least not always. It should be possible, even with given structure, to just include the recipes that you need. And additionally, it should be possible to enable/disable tasks that each recipe offers. This is true of any "library" and there is a danger of doing too little or too much. It will have to be an iterative process for this to result in a library that is appealing to wider audience.

This observation is in no-way a thumbs-down for deprec. It is a step further and an exemplary concrete implementation of capistrano's potential as a generic deployment tool.

Related posts:

1. Automated Deployments Rock
2. Rails Development on Windows: Native or Virtualize
3. What makes Ruby/Rails Development Fun
4. Project Website Part 5: Morph in 11 steps or so
5. jRails: Ruby on Rails with the Prototype guts ripped out

Comments (4)

ruby on rails

Comments: 4 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Your first point is reasonable and has been fixed in deprec-2.0.1. Get it with:

   sudo gem install deprec

   Newly created ~/.caprc does not load Rails recipes.

   This solves the problem of Capistrano’s default deploy tasks having ‘before’ and ‘after’ tasks added when you’re deploying a project that isn’t setup to use deprec.

   Existing users can update their existing ~/.caprc, replacing:

   require ‘deprec’

   with:

   require ‘deprec_minus_rails’

   I’d love to hear if this solves your first problem. deprec-users@googlegroups.com

   Is the second issue you raised causing you any problems or is it a ‘nice to have’?

   - Mike

   Comment by Mike Bailey, Thursday, February 19, 2009 @ 9:07 am

2. 

   @Mike,
   Sorry, I was away with my first newborn.
   The 2nd issue is not a problem per se. It’s just a thought that deprec is now manageable but may eventually grow into a rich however unrelated sets of functionalities. That is no different for any general purpose library and can be easily refactored.
   Thanks for stopping by.

   Comment by Sharad Jain, Saturday, February 28, 2009 @ 8:09 pm

3. 

   I generally add only recipes that I need and can’t see it getting too big. If you want to work on a neat solution for excluding recipes I’d be willing to look at including it.

   Congratulations on the newborn!

   Comment by Mike Bailey, Monday, March 2, 2009 @ 7:30 am

4. 

   Thanks a ton Mike, this solved my problem EXACTLY! I’ve been looking for a fix for months now.

   Comment by Todd Dickerson, Monday, April 20, 2009 @ 9:32 am

Leave a comment