# Environments and updating production applications

**URL:** <https://www.ruby-forum.com/t/environments-and-updating-production-applications/58439>\
**Category:** Rails\
**Created:** [April 21, 2006, 5:53pm UTC](https://www.ruby-forum.com/t/environments-and-updating-production-applications/58439 "2006-04-21T17:53:40Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![stepheneb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/71e660/32.png) [@stepheneb](https://www.ruby-forum.com/u/stepheneb)\
**Post date:** [April 21, 2006, 5:53pm UTC](https://www.ruby-forum.com/t/environments-and-updating-production-applications/58439/1 "2006-04-21T17:53:40Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![stepheneb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/71e660/32.png) [@stepheneb](https://www.ruby-forum.com/u/stepheneb)\
**Post date:** [April 21, 2006, 6:59pm UTC](https://www.ruby-forum.com/t/environments-and-updating-production-applications/58439/2 "2006-04-21T18:59:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![stepheneb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/71e660/32.png) [@stepheneb](https://www.ruby-forum.com/u/stepheneb)\
**Post date:** [April 21, 2006, 8:03pm UTC](https://www.ruby-forum.com/t/environments-and-updating-production-applications/58439/3 "2006-04-21T20:03:16Z")

</div>

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.) 🙂
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. 🙂

Come on in, the water is fine!

–  
– Tom M.

---

<div class="post-metadata">

**Author:** ![stepheneb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/71e660/32.png) [@stepheneb](https://www.ruby-forum.com/u/stepheneb)\
**Post date:** [April 22, 2006, 7:29pm UTC](https://www.ruby-forum.com/t/environments-and-updating-production-applications/58439/4 "2006-04-22T19:29:36Z")

</div>

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
