How often do you update the gems on an unreleased project?

I've got several side projects that are either still in dev or live for friends and family. The exception (modulecounts.com) is pretty trivial.

At work, in a larger organization, it seems like we always make rules against updating gems too often. It becomes a story that's scheduled for a particular sprint. It has to be coordinated with Ops to make sure they'll be ready to update the production environment, etc.

All that coordination overhead is gone when I'm the only dev, but there's still risk in updating gems. Maybe those new versions won't work quite right.

So... is it better to do it all the time? Start each dev session with "gem update" and go from there? Or should I wait until I'm about to go live and do one big update, hoping that any time lost on the back end is made up for by not having lost time in little increments throughout development?

What do you do? What's the happy medium?

The benefit of updating gems more often is that you get improvements. For example, security improvements or speed improvements. Also, it means that your code is more up-to-date, it's usually easier to find documentation for newer gem versions. Also, keeping your gems up to date means that you are using the newer versions of APIs, for example Facebook or Twitter. Using newer APIs can mean speed improvements and staying ahead of deprecations. Of course, as you point out, there are downsides to this, and it's important to keep that in mind. Here are a couple of pointers I like to follow:

1. Understand the newer gem version you are using. Read the release notes. If you are using well documented gems you should be able to find out what is new in this release of the gem and if you are going to have to deal with deprecations.
2. Use gem versions in your Gemfile. My favorite operator is ~>. ~> 2.1 means >= 2.1 but < 2.2, this means you can ensure that your gems stay up to date without having to worry as much about deprecations because you can remain within specific gem versions. This often means you'll continue to receive security updates for a specific gem version while retaining the same command and function formats.
3. Don't upgrade immediately on critical projects. It's best to wait a little when new gem versions are released before you upgrade. Test the new gem version in your development branch or wait to see if others find errors. Stay up to date on a new gem version's progress.
4. Write tests. Don't test gems directly, but make sure that your code that depends on gems is working as you expect it to. The more coverage you can get here, especially for critical functionality, the easier it is to tell if a new gem version is still operational.
5. Test your application after you upgrade a gem. It's often nice to create a new git branch and update a gem in that branch to ensure that your code is still operational. You might even keep a branch alive for multiple development cycles or sprints while it is being tested or while you are upgrading your code, only merging it back into your master branch once you feel confident that the gem upgrade was a good choice.

My preference is really to stay as up-to-date with gems as I can, while making sure that my development is not very hindered by continually upgrading. I try to upgrade on a schedule that works for my team, for example every two weeks, while keeping an eye out for security upgrades. It also helps to have an automatic way to setup your production environment. Bundler is great for this, because your Gemfile.lock can ensure that your production environment is running the same gems as your development environment.