[keredson]

Just to clarify, to me "data migration" is just a fancy name for a one-off script that you run during (or after) a deployment. We don't actually use the rails migration for it. (Mostly because it would overwrite our schema.rb IIRC.) But in general, yep.

[morokhovets]

So how do you manage these scripts? When deployment is multistaged and automated you won't just run them by hand. You need system that runs them automatically and exactly one time at each stage. I can't see why you have to create a system to manage these scripts if there is good enough built-in system for that purpose?

If automated deployment is not your case I strongly recommend it. Since I first time managed autodeploy to work properly I've never looked back. It is SO convenient.

I may be wrong again about your processes and configuration :)

[keredson]

we do auto-deploy, but they aren't required to be run during the deploy process, so we just run them sometime after the deploy. but honestly i can count on one hand the number of these we do a year - i haven't put much effort into streamlining the process. whereas schema changes are quite regular. just had one tonight in fact. output from the deploy log a few mins ago:

  Executing in 3...2...1...

  BEGIN TRANSACTION

  -- column changes for table products
  ALTER TABLE "products" ADD COLUMN "dont_email_on_purchase" boolean

  -- column changes for table searches
  ALTER TABLE "searches" ADD COLUMN "tag_only" boolean DEFAULT 'f'

  COMMIT

  --==[ COMPLETED ]==--

from the one line code change that triggered it:

  1  db/schema.rb
   @@ -543,6 +543,7 @@
  
      create_table "searches", :force => true do |t|
        t.text     "query"
   +    t.boolean  "tag_only",         :default => false
        t.datetime "searched_at"
        t.integer  "user_id"
        t.integer  "page_id"

(well, there were two commits obviously)