Engine Yard Express deployment questions

[Karl]

Managed to deploy my application in Engine Yard Express but I had a
few questions:

1) I created a database.yml configuration called express that uses
sqlite3, but when I deployed using the deploy.rb, it created my
database within mysql. Where does engine yard express get database
properties from?

2) I had to update gem to 1.3.1 as the default installation was 1.1
which was not compatible with rails. Is this expected?

Coincidentally I was unable to upgrade gem using "gem update --
system", but i found a solution on this post:

http://groups.google.com/group/emm-ruby/browse_thread/thread/9791d6cf303c18cd

3) Since I had cucumber installed within my app, the deployment
process failed due to the missing cucumber rake task. I had to ssh to
my vm installation and manually perform a gem install of cucumber
first. Is there a more seamless way to install all gems as part of
the first deployment?

Thanks.

-karl

[Joel Parker Henderson]

On Tue, Mar 31, 2009 at 12:07 PM, Karl <karl...@gmail.com> wrote:

Managed to deploy my application in Engine Yard Express but I had a
few questions:

1)  I created a database.yml configuration called express that uses
sqlite3, but when I deployed using the deploy.rb, it created my
database within mysql.  Where does engine yard express get database
properties from?

Hi Karl,

I'm an EngineYard customer and may be able to help you somewhat.

Short answer, there's typically a different database.yml on a local setup vs.
on your production setup; this is for security reasons, because it ensures
that your production database password is only on the production server.

EngineYard staff may have created a database.yml file on the production,
so sign in to the production server and look there for it.

2)  I had to update gem to 1.3.1 as the default installation was 1.1
which was not compatible with rails.  Is this expected?

Yes, this is an unfortunate bug in gem, and it
means sometimes you'll think you've upgraded
but haven't really.

Always double-check by doing:
   gem -v

Be sure you're on 1.3.1.

If you're on Ruby 1.9.1, heads up that there's a new bug in gem 1.3.1
that has to do with gem install using the --test flag. There's no fix yet.

There is a similar gotcha bug in capistrano;
if you use it, be sure you're on the latest version.

> 3)  Since I had cucumber installed within my app, the deployment
> process failed due to the missing cucumber rake task.  I had to ssh to
> my vm installation and manually perform a gem install of cucumber
> first.  Is there a more seamless way to install all gems as part of
> the first deployment?

Yes, there are scripts such as Capistrano (typical and can install gems),
Vlad the Deployer (my favorite because it uses rake and is better written),
Sprinkle (scriptable sys admin & we're getting great results from it),
and Chef (more powerful/complex and suitable for larger needs).

Also, the typical way is to put all your gem requirements in
your app's config.rb file, which means that your app will
check to be sure it has all the gems it needs to run.
I recommend specifying the gem version, lib, and source:

   config.gem 'foo-bar', :lib => 'bar', :version => '1.2.3',  :source => 'http://gems.github.com'

People will tell you that you can install your app's gems by doing:

   rake gems:install

However, I have found the gems:install approach to be VERY unreliable.
There are all kinds of tricky problems with it.

Much better is to install the gems yourself (with Cap, Vlad, Sprinkle, Chef, by hand, etc.)
We always use the --test flag to ensure our gems are working correctly,
and we use a bunch of other flags that may help you too:

   sudo gem install foo-bar -v 1.2.3 --source http://gems.github.com --trust-policy HighSecurity --test --no-ri --no-rdoc --no-user-install

Longer term we want to start using Phusion DebGems, which are a smart, secure approach
to mananging gem dependencies at a systems administration level.

Hope this helps!

Cheers,
Joel