bundler and future updates

Posted: February 9th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: , , , | No Comments »

There was a new post about bundler which addresses a few of the issues that I’ve been having as part of my install.

When running bundle install in the future, Bundler will use packed gems, if available, in preference to gems available in other sources.

This will be nice and solve my issue of re-installing all the gems on each deploy.

You will want to run bundle unlock to remove the lock, then bundle install to ensure that the new dependencies are installed on your system, and finally bundle lock again to relock your application to the new dependencies.

We will add a command in a near-future version to perform all these steps for you (something like bundle install –relock).

This will also replace the unlock, update, lock steps I’ve got in the callbacks.rb for my deploy scripts. Not a huge deal, but fewer commands is better.

The combination of these two updates should speed up the deploy a lot.


rails 3, bundler, git and dreamhost

Posted: February 8th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: , , , , | No Comments »

UPDATE: How to setup your Dreamhost shell account update available here.

Now that rails 3 has hit beta, I decided to see if I could get it running on my dreamhost account. I’m already running a few rails applications using bundler 0.8.1, so the forced upgrade to 0.9.3 (as of this writing) is actually a point of pain, since both versions cannot co-exist.

If you’re not running an old version of bundler, this should be an easy update. If you are, it gets complicated to the point that for now, it’s not worth updating since bundler 0.9.3 still seems to have issues with rails 2.3.x.

The first thing I did was to install the bundler gem in your usual location for dreamhost. This isn’t going to be a “how do I set up rails and custom gems for dreamhost?” post as those resources exist on the web already.

On dreamhost:
gem install bundler

Now you want to setup your rails 3 application, get it into a git repository and push it there. The main point of this post is to include my deploy files which are based on the github ‘git’ deploy strategy, which is really nice. I’ve added in some code for jammit as my asset packager, and some custom bundler callbacks.

I’ve included a gist below with my deploy code. Make sure the files are in the proper directories.


merb, dreamhost, capistrano and git

Posted: February 18th, 2009 | Author: jgeiger | Filed under: ruby | Tags: , , , | 1 Comment »

I’ve been trying to use merb a bit more just to get prepared for the forthcoming rails/merb merger.

For what I’ve been doing, dreamhost has been really nice. Shell login, unlimited domains/transfer/storage with the ability to compile your own software has been a really nice thing for a low cost provider.

For this to work, you need to install git on your dreamhost account.
Nice step by step walkthrough
Official Wiki Entry

I’m not going to get into the details of using git or merb, since there are resources out there already. From here I’m going to focus on the setups for capistrano, and how to set it up to deploy your merb application from a git repository on your dreamhost account.

Here is the main capistrano configuration file which lives inside the config directory of my merb application.

deploy.rb

The configure script includes the utility methods to create the shared directories, link the database.yml and unpack the merb gems.

deploy/configure.rb

Once this is setup properly, you can just type “cap deploy” and it will use the git repository setup on your dreamhost account. If you have setup SSH keys, you won’t have to type your password. (You have setup SSH keys, right?)

There is one trick that I figured out, that may or may not be a good idea. For me right now, I’m ok with doing it.

Even if you have an SSH key setup to log into your shell account, it will still end up needing to SSH into itself to check out the git repository. (This is a tradeoff for the ability to move the git repository anywhere else, such as github.com, without changing a lot of the configuration) If you don’t do this, you need to enter your password in the middle of the deploy. I just created another SSH key for the username, put it into ~/.ssh and added the id_rsa.pub into the authorized keys. The deploy now works with nothing more than “cap deploy”.