Keeping Your Rails Migrations Clean
I’m working my way through a for fun side project using Rails 1.1 and I’ve been using ActiveRecord migrations instead of the older style SQL scripts. I like them a lot because it allows me to continue to stay in Ruby. Still each time you want to make a change to a table you need to create a new migration script.
There’s a downside to migrations. Over time, your schema definition will be spread across a number of separate migration files, with many files potentially affecting the definition of each table in your schema. When this happens, it becomes difficult to see exactly what each table contains.
After a bit of hunting I settled on my current fix. Keep all the changes one per table in their Create ActiveRecord Migration files. Keep all the data migrations in a separate file. When you alter one of them and need to reset your database run two commands:
rake db:migrate VERSION=0 rake db:migrate
Presto, your database is back to a clean state.
Agile Lite
Yesterday my organization invented a new Agile methodology–Agile Lite! You might recognize it as Scrum minus collocation.
- 30 Day Sprints
- Planning Meetings
- Product Backlogs
- Review Meetings
- Sprint Backlog
- Daily Standups
- Scrum Master
- Product Owner
The name is a bit humorous, but as long as we get to run it as an Agile/Scrum project I’m not really very concerned about the actual name we use. The best part these days is the strongest proponents of doing Scrum projects are the customers. They really enjoy the control over the direction of the project it allows them.
Team Room Reality
Approximately two weeks after coming up with a new layout to swap my office into a team room I now have the following:
The vision was to pull out all the cabinets and mount another large whiteboard on the west wall and bring in a couch. This mainly just turns the focus of the room from an office into a meeting room while leaving the space eating cabinets, but it’s 70% of the vision and they only had to remove one desk panel.
SOA 2.0, No!
Apparently all of the hype around SOA wasn’t enough for Gartner and others so now we have SOA 2.0. Apparently you take SOA 1.0 + Event Driven Architecture. Pure Madness.
Checklist for Running Ruby on Rails on Bluehost
Kudos to Bluehost for adding Rails hosting, but you might have found getting more than a trivial example running is an exercise in frustration. The following checklist details at least one successful path to getting a full Rails app up and running. (Much of the basic outline comes from the following Bluehost knowledgebase article, but it tends to leave out some details, especially newer things like ActiveRecord migrations.)
Setup Directories on Bluehost
Bluehost suggests setting up a working directory for your rails projects. Reasonable enough just use the wonderful CPanel ssh terminal and create it at the top level of your home directory:
% cd ~ % mkdir rails % cd rails
Next you want to startup your first rails project. This may seem a bit bizarre, since you may have a perfectly good rails project already. Lets just assume you want to upload the sample project from Agile Web Development with Rails, the Depot project.
% rails depot % cd depot
Point a New Subdomain to Your Rails App
Now it’s time to setup a subdomain for your little application. Bluehost gives you plenty of these so one per rails app is no big deal. We’re just going to assume we’re using example.com so the final subdomain will be depot.subdomain.com. Just go into CPanel and add depot as a new subdomain. Now we want to point to it in our ssh session again:
% cd ~/public_html % ln -s /home/YOUR_USERNAME/rails/depot/public depot
As a test that things are going right so far you can check out http://depot.example.com/ and you see the familiar rails default page. Nice but not exactly what you were hoping for.
Setting Up the Databases
First you need to add a database user. cPanel prepends your own Bluehost username to everything so just be aware. Add the database user by going to cPanel choosing the MySQL databases and adding a user. If you pick ‘rails’ the name will be
1
|
username_rails
|
.
Next, just add two databases dev and prod. You won’t need a test database probably because you won’t be running your unit/functional tests on the Bluehost server. So same MySQL link in cPanel and just name it ‘depotdev’. (You can’t use an underscore since it just ignores it anyway.) Since it appends the username it will become
1
|
username_depotdev
|
. Then you repeat the steps again for the production database and name it ‘depotprod’ so that you have another database
1
|
username_depotprod
|
.
Finally you give the
1
|
username_rails
|
user access to the the two databases
by first selecting
1
|
username_rails
|
from the user pulldown menu and then
1
|
username_depotdev
|
from the database pulldown. Go ahead and give it all permissions and click on ‘Add User to Db’. Repeat for
1
|
username_depotprod
|
.
Configuring the Database Connection
Of course here you’re going to edit
1
|
config/database.yml
|
on your local machine. It should look something like:
development: adapter: mysql database: username_depotdev username: username_rails password: password host: localhost
production: adapter: mysql database: username_depotdev username: username_rails password: password host: localhost
Then FTP the file up and replace
1
|
~/rails/depot/config/database.yml
|
.
Migrating the Database Schema
Migrating your database using ActiveRecord migrations starts with FTPing over everything in your
1
|
depot/db/migrate
|
directory locally. Then log into your server using the cPanel SSH client and run:
% cd ~/rails/depot % rake db:migrate % rake db:migrate RAILS_ENV=production
Both of the migrate commands should show some schema migration logging comments. If not you probably need to check the syntax in your database.yml file for errors. This migrates the schema to both the dev and production instances.
Migrating the Application Code
Next step is to FTP over all of the files in
1
|
depot/app
|
on your local machine to the server at
1
|
~/rails/depot/app
|
.
Since you’re application may need some sample data you can add it through phpMyAdmin, SQL scripts, or a Rails scaffolding.
Switching to a Default Production Environment
Rails by default assumes you’re running in development mode. There are lots of nice ways to change the RAILS_ENV environment variable, but since Bluehost is a hosted solution there is a pretty simple hack that is guaranteed to work. Simply uncomment the following line in your
1
|
config/environment.rb
|
file:
# Uncomment the line below to force Rails # into production mode when you don't # control web/app server and can't set it # the proper way # ENV['RAILS_ENV'] ||= 'production'
Then FTP the file over to your Bluehost account. You’ll probably want to comment out the line in
1
|
environment.rb
|
again for you local development.
Positive Feedback
Just point your web browser at the URL assuming you have controller named ‘store’ and a method named ‘list’.
http://depot.example.com/store/list
Now do a little victory dance or eat some M&Ms, your choice.