views:

83

answers:

1

Hi Everyone,

I know this may seem trivial to some, other won't see the point, however - for me this would be great:

I am trying to work out how to quickly and efficiently commit updates to my Rails app, switch to an under construction style page while I restart the rails app and then test the changes, then when I am happy, switch back to the live public version.

At the moment, I follow the following pattern:

  • 1, make changes to app
  • 2, commit using Versions App for Mac to BeanstalkApp
  • 3, deploy revision from BeanstalkApp to server
  • 4, login to server and restart apache
  • 5, wait a few seconds and then start to double check everything is A-OK

If it helps, I am using Passenger on a Turnkey Rails image VPS.

Thanks in advance for any advice, etc.

Thanks,

Danny

+3  A: 

You have a few options:

  • Create a subdomain for 'testing' and deploy it to your production server and when it's vetted you can push it to your production code location.

You'll need to be able to add a subdomain to your DNS record to point to the same IP address as your main production server. You'll then also need to add a new VirtualHost with ServerName subdomain.host.com and DocumentRoot /data/host.com/testing/public so that it loads that code.

I have personally done BOTH approaches. I prefer approach #1 but it's personal preference and the level of access you have to your hosts.

Matt S
Thanks, Matt. As it's a VPS server I have complete control - not always a good thing!If I went for the first option, created a subdomain for testing etc. would you suggest using the public/live database? Most problems I face are during the migrations etc. therefore I want to try and limit the downtime of the app while I "check" things.
dannymcc
As you'll likely need to migrate I'd suggest a 'staging' database. YOu can use a multitude of tools to duplicate your database (depending on size of course) for this purpose. Theoretically staging should only ever be ahead or equal to production (in the way of structure). If you need frequent syncs with production that's a whole other poject :).It's always better to have a separate database which you test on and once everything is good to go you push to prod. (by push i mean rerunning your migrations).
Matt S
Currently, I have a local sqlite3 database and a staging (read: production) server with mysql database. Because of the different types of database I havent been able to duplicate the content. Am I reading correctly that ideally I should have to absolutely identical setups so that if I run rake db:migrate on the staging it would definitely work on the production one?
dannymcc
Nope. I typically develop with an SQLite database locally so I can see that data duplication isn't easy. What I would do though is have another database on your mysql server called <name of db>_staging. Configure your rails app to point at the staging db when in 'staging mode' (quite easy as I'm sure you know). To create this databsae the first time you can use phpMyAdmin for example to duplicate the database entirely.
Matt S
Ahh I see, Im more than comfortable with the database side of things then, is there a quickfire way to start a copy of the application in staging mode?
dannymcc
If you use the subdomain method which means a separate vhost in apache you can pass the argument in <VirtualHost> element to tell passenger to start in whatever environment you want. I believe it's `RailsEnv`. At least I think that's what you were asking.
Matt S
Yeah thats exactly what I was asking for. Thanks, you have been a great help!
dannymcc