Hi all,
Thanks for your input. As a result, I've revised the steps, listed
below. Note: there are no assumptions here -- I have written down
absolutely everything I intend to type. Have I captured it all? If I
have, and it works, I might summarise it in a blog post when I'm done.
Thanks again,
Steven.
Here goes:
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 drominay-staging
B. heroku db:pull sqlite://backup.db --app drominay-production
C. heroku db:push sqlite://backup.db --app drominay-staging
D. heroku rake db:migrate --app drominay-staging
E. rake db:restart --app drominay-staging
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 drominay-production
C. heroku rake db:migrate --app drominay-production
On Apr 15, 4:21 am, Jared Brown <[email protected]> wrote:
> 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.
