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 at > http://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.
