We've got our own set of rake tasks which I recently extracted into a separate object so I could add tests and make them more modular. They add a few features to the (awesome, stellar, beautiful) heroku deploy process:
* "rake stage" pushes master to staging * "rake deploy" pushes what's on staging to production, even if you've done more work on master * deploy (to staging or prod) sends email to a given list saying what's changed since the last production deploy * generates and deploys a "/version.txt" file with current git hash and database migration version so you can verify what version is on what server * generalizable to other non-production apps (e.g. we use a separate site for user testing) * "rake stage_db" pulls the production DB locally then pushes it to staging There's still some proprietary stuff in there but with enough pressure I could probably find the time to package it up on github... I like Arron's idea of grabbing a bundle on every deploy too. We used to grab the DB on every deploy (also "just in case") but the DB is too big now for that to be feasible. - Alex On Jun 25, 6:47 am, johnb <john.bey...@gmail.com> wrote: > Arron, > > Could you share those rake tasks? Be interested in checking them out > > cheers, > > john > > On Jun 23, 5:58 am, Arron Washington <l33t...@gmail.com> wrote: > > > > > Nobody? > > > OK, I'll share what I do. :3 > > > For an important project hosted on Heroku (that I don't want to go > > down), I tend to wrap everything up in rake tasks that handle > > deployment, caching assets on Amazon S3/Cloudfront, etc. As part of > > these tasks, I also include the ability to roll back to a previous (or > > arbitrary) Git commit. I use the 'git' gem to handle these commands > > internally, and since there's always an official repo that isn't > > hosted by Heroku, it's safe to nuke the Heroku repositories using the > > '--force' flag when required. Once the tasks are developed and the app > > is live, nobody is allowed to do a raw `git push` to the Heroku > > remotes anymore. > > > We keep our environments/staging.rb as close to our environments/ > > production.rb as possible. > > > Deploy tasks also capture a Heroku bundle for each deploy, but I think > > the Heroku bundles also take a snapshot of the database -- data is > > generally not something we're willing to use during an emergency > > recovery, so we don't use the bundles. They're there just in case. > > > On Jun 18, 7:49 pm, Neil Middleton <neil.middle...@gmail.com> wrote: > > > > Following on partly from my earlier email about support: > > > > We have an app that we've deployed a production and staging environment > > > for. > > > The idea being that all deployments go via staging prior to production > > > as a > > > way of testing that Heroku is happy to spin up and 'accept' our > > > application > > > (config is nearly always the issue). > > > > Question is, what steps do people do to prevent themselves from ending up > > > with a production app that's failing to start? I know some users are > > > pushing a large amount of traffic where downtime is unacceptable, so what > > > do > > > you do to protect yourself? How do you recover if things go bad? > > > > For anyone to trust something as different as Heroku, I think you have to > > > know how to get back to a working state asap without outside intervention > > > where possible. -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
