Carnegie Mellon University Website Home Page
 
Spring 2008  |  Mini 3

Lecture 14 - February 27

Moving from Development to a Production Environment

So the first thing we need to do is move off localhost (127.0.0.1). To do that, you first need to know the IP address of your server. You can each use your laptop to serve up your application, so open a Windows Command Prompt and issue the command ipconfig (if this doesn't work, just point a browser at whatismyip.org).

So now we know what our IP address is. In order to allow people to access our server, we'll need to cut a (small) hole in the Windows Firewall. So go to Control Panel->Windows Firewall->Advanced, go to Network Connection Settings, click Settings and then click Add in the Services pane. The description can be any text description (web server demo), the IP address is your IP, and the port (internal and external) is 3000.

Once you've allowed the web to see you on port 3000, cd into the web_app directory of your choice (we used login_demo) and tell Rails that you want to serve the app on that IP. This is done with the command:
    ruby script\server -p 3000 -b <your-IP-address>
The -p switch indicates the port, and the -b switch indicates the IP address to bind the app to.

You should now be able to point a browser at http://<your-IP-address>:3000/login and see the login_demo web app.

This is all well and good, but WEBrick, the server library that Rails uses, is still running in development mode. This means that if, for example, I mis-type a controller name in the URL, I'll see the router-error page, and if I mess up in some other way, I'll see the white-and-gray error message page (along with the source that generated the error).

So first, let's have the opening page redirect to something more application-specific than the standard Rails spash page. To do this, we go to the web_app directory of our choice and edit the config/routes.rb file. At the bottom of that file, you will un-comment the
    map.root :controller => 'welcome'
line and change welcome to the controller of your choice. As the line above the line you're editing reminds you, don't forget to delete public/index.html (the standard splash page). Stop the server and re-start and you should see the view associated with whatever controller you selected.

We still want to not display the debugging pages when the user does something wrong (we'd rather see a 404-error page, for example, instead of the routing error debugging page, if the user mis-types a URL). So we need to start the server with the -e production switch. We'll also need a production version of the database for it to work with, and unfortunately, there's no easy way to simply copy a MySQL database.

To copy a MySQL database, we need to dump the entire database and then re-load it with the new name. Dumping the database is done with the command:
    mysqldump -u root stock_competition_development > stock_dev.sql
This command dumps the database and the sequence of commands run against it to generate its current state and redirects the output of the dump to the file, stock_dev.sql. You then need to go into MySQL and create the production database:     mysql -u root
    create database stock_competition_production
And then you can read your development database back in (and copy it to the production version) by issuing the command:
    mysql -u root stock_competition_production < stock_dev.sql

One last thing. In order for us to be able to run your app, we'll need a copy of your database, so please dump your stock database with the collowing command:
    mysqldump -u root stock_competition_development > [andrew-id].sql
and submit this SQL file along with your web app when you hand in.