I'm working on something that will be way better than using jenkins to do continuous deployment, but here is how we do it today.
This is in reply to https://twitter.com/#!/haraldmartin/status/185683988063588352
What we want: For each revision, build it in steps, don't advance if the previous step failed. So that it can run a chain of steps like: unit_tests -> integration -> deploy staging -> deploy production.
If you just join projects in jenkins, and say rev-a passes in project-a, project-b might get rev-b. That's not good if project-b happens to be deploy-to-production and rev-b is broken.
We use: https://wiki.jenkins-ci.org/display/JENKINS/Join+Plugin And: https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin
We only trigger one job on commit, the "commit" job. It has this config: http://cl.ly/1Z3q2D3I45363m27350h
Then each project has this to only build the correct rev: http://cl.ly/2l3S2c1j3z2Q1N2M2F32
This works, but still one problem. What happens if some step downstream takes a really long time to run, you might want it to skip to the latest ready revision instead of spending hours to catch up?
For this we use a script that cleans out the jenkins build queue (a bit of a hack but very reliable): https://gist.github.com/2250943
On top of this we have a display that shows the revisions as each step go green, but that code is too integrated in our dashboard to make a quick example.