Don't Forget: When you do the db:migrate through heroku you will need to use the --app flag.
This one got me the first time as it is not well documented on Heroku. There really should be a Doc on Heroku.com that runs through this as this question is asked frequently. Jared On Apr 14, 11:50 am, Nicolás Sanguinetti <[email protected]> wrote: > On Wed, Apr 14, 2010 at 9:06 AM, steven_noble <[email protected]> wrote: > > Hi all, > > > I'm about to set up a staging server on Heroku and I'm hoping you can > > check my logic before I do anything stupid. > > > At present, I have a production app on Heroku: > > > drominay-production > >http://drominay-production.heroku.com > >http://www.drominay.com > > > I am the sole developer. The latest version of the code is on my Mac, > > which backs up continuously to TimeCapsule and to Dropbox. I also push > > the entire code-base to Heroku whenever I'm happy with the state of > > the code: > > > git add . > > git commit -a -m "here's what's new" > > git push heroku master > > > So far, I haven't had a reason to teach myself how to branch the code > > in git. I just build one feature at a time, commit regularly, and push > > the entire code base when it's ready. > > > My goals are: > > > 1. Continue to store the latest version of the code locally > > 2. Whenever I'm happy with the state of the code, push to a new app, > > drominay-staging, for a final check > > 3. Copy the database from drominay-production to drominay-staging to > > ensure the final check is robust > > 4. Prevent the public from accessing drominay-staging, while creating > > a separate code base > > 5. Minimize complications > > > Here's what I propose to do: > > > 1. Create drominay-staging > > > A. heroku create > > B. heroku rename drominay-staging --app 77-green-bears-or-whatever- > > heroku-names-it-originally > > > 2. Lock drominay-staging without creating two code bases > > > A. heroku config:add RACK_ENV=staging --app drominay-staging > > B. Surround most of declarative_authorization's rules for the > > guest role with conditions like 'unless RACK_ENV == "staging"' > > > 3. Test the current code and live database on drominay-staging > > > A. git push heroku master --app drominay-staging > > You would have a different remote for the staging app, so you'd > actually just do `git push heroku-staging` or something like that. > --app is not a valid git switch :) > > > B. heroku rake db:migrate -app drominay-staging > > C. heroku db:pull sqlite://backup.db -app drominay-production > > D. heroku db:push sqlite://backup.db -app drominay-staging > > You should first push production's database to staging, and then run > the migrations on staging (so step B should come after step D), or > else whatever changes you do to existing tables will be overwritten by > the db:push. > > Also, after doing a rake db:migrate you need to run `heroku restart`. > > Cheers > > > > > 4. Backup live database and then push code base to live app > > > A. heroku db:pull sqlite://backup.db -app drominay-production > > B. git push heroku master --app drominay-production > > C. heroku rake db:migrate -app drominay-production > > > If I do this, am I in for any nasty surprises? > > > There looks like lot's of opportunities for nasty surprises, so I > > guess the next step is for me to turn this into a few trusty rake > > tasks. > > > Many thanks in advance, > > > Steven. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Heroku" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
