Environments and updating production applications


#1

Hi All,

I’ve only been using Rails for a short time (working through the
‘Agile…’ book) but it’s already caught my interest so much i’m loathed
to go back to the PHP day job…

There are a few things i’m slightly unsure about. First thing is
environments. Am I right in thinking that environments are just
concerning the state an application is in? i.e. development would have
more debugging etc.

The other thing is concerning updates and fixes to a live site. The
application would be in production at that stage. If i needed to edit
source code, i assume i can just change the code on-the-fly. If i
needed to add a new column to a table for some reason, how would i
update the models to reflect the new schema?

I think with a lot of this it’s my approach to things that may be the
problem. Learning rails is opening my mind up to a lot of concepts
that, while i really like, i’m not familier. I’d apprieciate any
comments on the above.

Cheers!

Steve


#2

Stephen B. wrote:

Hi All,

I’ve only been using Rails for a short time (working through the
‘Agile…’ book) but it’s already caught my interest so much i’m loathed
to go back to the PHP day job…

I know form experience, after doing some rails it make you really not
like PHP work.

There are a few things i’m slightly unsure about. First thing is
environments. Am I right in thinking that environments are just
concerning the state an application is in? i.e. development would have
more debugging etc.

Rails deafults to 3 environments, each of which should use a different
database.

DEVELOPMENT: As the name implies this is what you develop in. It has a
few advantages. First of all, almost all of your code is reloaded on
every request, meaning you can change things, refresh, and see tha
chnages without rebooting the server program. It also has robust error
reporting. If your app blows up you get a screen with the error and a
stack trace to help you debug.

PRODUCTION: This is what you run your app in when its live and launched.
Your code is cached, meaning its loaded when the server boots, and then
left in memory. This is much faster than reloading the entire framework
on each request, but it will not reflect change made to the code while
running, which for a live webapp is fine. Also errors are handled with
standard error codes and the guts of the application are not exposed.
So if you go to a page that doesn’t exist, you simply get “404” instead
of a routing error with a stack trace you would get in development mode.

TEST: Used for tests. Tests created in your test directory are run via
“rake” from command line. You usually wont ever have a webserver
running an app in test mode.

The other thing is concerning updates and fixes to a live site. The
application would be in production at that stage. If i needed to edit
source code, i assume i can just change the code on-the-fly. If i
needed to add a new column to a table for some reason, how would i
update the models to reflect the new schema?

Since sites in production mode used cached code you can’t just change
the code and reload. My process for updating a live site is usually as
follows.

Commit to subversion some change
svn up
rake migrate RAILS_ENV=production
killall lighttpd
lighttpd -f /home/lighttpd/lighttpd.conf

We simply update the code, run any pending migrations, then reboot the
webserver. The app should only be unavailable for a few seconds.

I think with a lot of this it’s my approach to things that may be the
problem. Learning rails is opening my mind up to a lot of concepts
that, while i really like, i’m not familier. I’d apprieciate any
comments on the above.

Cheers!

Steve


#3

On Apr 21, 2006, at 8:50 AM, Stephen B. wrote:

There are a few things i’m slightly unsure about. First thing is
environments. Am I right in thinking that environments are just
concerning the state an application is in? i.e. development would
have more debugging etc.

That, and as pointed out, different databases.

The other thing is concerning updates and fixes to a live site. The
application would be in production at that stage. If i needed to
edit source code, i assume i can just change the code on-the-fly.
If i needed to add a new column to a table for some reason, how
would i update the models to reflect the new schema?

I think with a lot of this it’s my approach to things that may be
the problem. Learning rails is opening my mind up to a lot of
concepts that, while i really like, i’m not familier. I’d
apprieciate any comments on the above.

You’re already up-to-your elbows, might as well go all
the way in with migrations and Capistrano.

Migrations allow you to systematically make DB structure
and content changes in a programmatic and non-manual way.

Capistrano allows remote control of your server(s), so
with a single command on your development platform you
can do things like:

  1. stop app
  2. Put up a stop page
  3. Update code from repository (if you’re not using
    version control, it’s time to start. You’ll thank
    me later.) :slight_smile:
  4. run migrations
  5. Take down start page
  6. restart app

With test driven development, there shouldn’t be much
need to edit code in production. Famous last words. :slight_smile:

Come on in, the water is fine!


– Tom M.


#4

That’s great - thanks for the replies. I’ve never used version control
or even seperation of development and production platforms - it tends to
be hack-on-the-fly :0) I’m ready to move on to something more stable
and it seems like Rails encorages best practice in so many ways.

Steve