Stephen Bartholomew
2006-Apr-21 15:50 UTC
[Rails] Environments and updating production applications
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
Alex Wayne
2006-Apr-21 17:00 UTC
[Rails] Re: Environments and updating production applications
Stephen Bartholomew 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-- Posted via http://www.ruby-forum.com/.
Tom Mornini
2006-Apr-21 18:00 UTC
[Rails] Environments and updating production applications
On Apr 21, 2006, at 8:50 AM, Stephen Bartholomew 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: 0) stop app 1) Put up a stop page 2) Update code from repository (if you''re not using version control, it''s time to start. You''ll thank me later.) :-) 3) run migrations 4) Take down start page 5) 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 Mornini
Stephen Bartholomew
2006-Apr-22 17:28 UTC
[Rails] Environments and updating production applications
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 Tom Mornini wrote:> On Apr 21, 2006, at 8:50 AM, Stephen Bartholomew 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: > > 0) stop app > 1) Put up a stop page > 2) Update code from repository (if you''re not using > version control, it''s time to start. You''ll thank > me later.) :-) > 3) run migrations > 4) Take down start page > 5) 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! >