6 Answers
6

We use Integrity. It is a pretty simple solution - it won't do everything under the sun, but it's quite easy to set up and handles the most common use cases/features. It's also pretty easy to hack on, if you want it to do more.

Integrity states:

Heroku is the easiest and fastest way to deploy Integrity.

However:

NOTE
It isn’t possible to access repositories over SSH on Heroku

This is because your Integrity app will need an SSH key. It's not impossible, but definitely a few hoops to jump through. You'll need to give Integrity a private key and put it in the app, and then hack Integrity to use that ssh key when it initiates the git clone.

Of the things you listed, the automatic deploy is probably the thing most people would not expect their CI server to do (and Integrity does not provide out of the box). You'll need to configure git to use that ssh key and initiate a git push from the proper location (the checked out repository).

Unfortunately I don't know the details of how to do this--we actually run Integrity on a VPS.

There are many tools in the market that do this. SnapCI offers deployment pipelines that let you push every commit through tests and then subsequently into staging and production as different stages of a deployment pipeline. We also have full support for test parallelization, building branches and pull-requests.

to preface I am one of the founders of Codeship (https://codeship.io), which is a service that supports exactly this.

But more on topic, basically there are 2 different ways I think this could be implemented (please keep in mind that all branch names I use are arbitrary and can be named totally different):

staging/production in one go

Whenever you push to your master or a specific deploy branch you run your tests and if all of them pass you first deploy to your staging app, run separate tests (Selenium or sauce labs is great for that) and if that works out including migrations you push to your production app.

This is great as the latest version is always available in production and we use this cycle for a long time now. Works great for us. The downside is that pushing to a staging heroku app takes some time. If you want to run the migrations against a copy of your production data this takes even more time. It's not an eternity, but it takes a couple of minutes.

staging/production as separate steps

You could have separate staging/production branches which are deployed to the respective heroku applications. This has the advantage of being faster and you can control when to release certain parts. Especially for applications where you want external feedback before deploying to production this works great.

We support all of that at Railsonfire, but we are currently working on a new version of our service which is way better. We integrate really well with Heroku so you don't have to think about that (but still have the option to do it yourself in any way you want)

This reads a bit too much like an advertising "call to action" to be appropriate as an answer here.
–
Andrew Barber♦Nov 29 '12 at 0:05

Sorry @AndrewBarber if this came over a little to advertisy, but I wanted to address a few different ways how to do continuous deployment effectively. I thought that as he specifically asked for hosted providers (he did so below with Hudson) telling him a little about our service might be ok.
–
Florian MotlikNov 29 '12 at 11:36

I would definitely get rid of all the stuff related to your contact information; that's what pushes it from questionable to well over-the-top, in my opinion. I don't think you are intending to 'spam', and you're a new user here, so I'm not flagging anything now. I'll do some edits that I think fix this post itself, but I would also recommend reading the FAQ on Self-Promotion for more general guidance, too.
–
Andrew Barber♦Nov 29 '12 at 11:38