Deployment conflict question

[cswebgrl]

Hi.

I tried to deploy new Rails app code to a production server the other
day and took down the live site in production. I'd like to avoid this
in the future. Something happened in the process that affected the
live site. The error log showed that fastthread was not found. I had
to go into the fastthread gem and run setup.rb. Then it told me that
Rails was not installed so I had to do a gem install Rails. Then
there were other gems that were needed by the application and not
found so I had to reinstall those too.

I have my own staging server that this all worked on, but the staging
server is able to serve multiple sites so it is not an exact replicate
of the client's production box. The Apache setup is such that only
one site can be served from this machine - the document root in Apache
is /project/public.

I've got a couple of questions. 1- Any idea why gems would need to be
reinstalled? 2- Can I deploy Capistrano without restarting Passenger
to put the code onto the production server and then once it's all
there, change the document root in Apache then do a deploy with the
Passenger restart?


Thanks,
Cindy

[Joe McDonagh]

Hi Cindy, did the client mix and match operating system-native packages
and rubygems? That can cause problems, and it wouldn't surprise me if it
caused this one.

I'm still kind of a noob with cap, so I'm not sure about question 2...

Have you thought about using virtualization to create real staging
environments for your clients? It's a pretty fundamental flaw if your
staging environment is not an exact replica of the production
environment (save the staged code).

--
Joe McDonagh
Operations Engineer
www.colonfail.com

[Lee Hambley]

Cindy,

Your mileage may vary using the remote dependencies and deploy:check... you should also have a way of managing gems, this can be done through modern rails (2.x+) or with a specific gem called geminstaller.

http://mislav.uniqpath.com/rails/specify-your-dependencies-with-capistrano/

- Lee

2009/7/2 cswebgrl <csch...@gmail.com>

[Cindy Schaller]

Thanks for your response.

 

Any thoughts on question #2 and deploying without the Passenger restart?

 

 

 

---

[Lee Hambley]

Cindy,

You should just be able to replace the deploy:restart task with something like the following:

namespace :deploy

  task :restart do

    run "touch #{current_path}/tmp/restart.txt"

  end

end

2009/7/2 Cindy Schaller <csch...@gmail.com>

[cswebgrl]

>
> Hi Cindy, did the client mix and match operating system-native packages
> and rubygems? That can cause problems, and it wouldn't surprise me if it
> caused this one.
>
> I'm still kind of a noob with cap, so I'm not sure about question 2...
>
>  Have you thought about using virtualization to create real staging
> environments for your clients? It's a pretty fundamental flaw if your
> staging environment is not an exact replica of the production
> environment (save the staged code).
>
> --
> Joe McDonagh
> Operations Engineerwww.colonfail.com

Hi Joe,

I've been thinking about our question regarding "mix and match
operating system-native packages and rubygems". This is a bit
difficult to answer given that I did not set up the original
environment. Do you know if there's a way to figure this out on the
production server? I don't want to throw good after bad by freezing
gems that are already "bad." If I freeze them, download the project
into a dev environment or staging environment, am I just bringing the
mess wherever I go?

I think what we really need is a clean install of the production
server and "start over" from there, but I'm not sure if this is
possible.

Thanks!
Cindy