We currently use Gerrit, for a team of about a dozen and some developers.
This is our current workflow:
1. Developers branch from master
2. Developers work on their local branch
3. Developers push to gerrit, which gatekeeps the master branch by containing the pushed commit in refs/for/master. (If you didn't know, gerrit is also a repository manager.)
4. Gerrit invokes Jenkins, runs unit tests (and Selenium tests) on the changeset. If it fails, the commit is kicked back to the developer. Else, Jenkins +1s the commit.
5. Reviewer looks over commit and +1s it
6. Senior reviewer looks over commit and +2s it and the changeset gets merged into refs/head/master (i.e. the actual branch)
We love this workflow; it's great. It's brought wonderful and much needed process and discipline to our development and made a to-do list out of our previously overlooked and ignored code-review bottleneck and everyone is happier for it.
x - Intermission - x
We're now looking to move our task management over to Jira. While I was setting it up, I also set up Crucible since it seems like the natural integration to get code review to be part of the whole shebang. What I'm not able to do is reproduce our workflow above that we've come to love. With the Jira/Crucible integration, since we no longer have our repository gatekeeping everything (and we don't want to pay for Atlassian's Stash), we would be pushing code to Bitbucket. We can no longer work directly on master since bad code would no longer be "gate-kept" but merged into master by the developer before it passed any tests or code review. The only solution to keep it out of the master branch seems to be forks. Okay, that's annoying but I could roll with that. But how do I get the commit from a developer's fork to get merged into the master branch after it passes code review? That's what I would like to hear from people who have done anything even remotely similar, or know how to accomplish it given my situation.
The alternative to all of this is to try and force an integration between Jira and Gerrit using https://github.com/hobbs/jirret but that uses XML RPC which Jira still supports but will no longer do any development for.
Vic, to grab changes from a developer's fork and bring them into the master code line of the original repo, you can use pull requests in Bitbucket. They are complimentary to the Crucible code reviews you're doing. If forking is a pain, you could try creating an "integration" branch in your repo, and have devs push code there frequently (even before their ready for a peer review). That branch becomes kind of a soup where integration issues can surface and get worked out, without polluting master. Some of the dev teams at Atlassian use an integration branch, and also take advantage of Bamboo's support for automatically applying your CI scheme to new branches, and automated merging between branches with each build. Typically, you'd have Bamboo merge your dev branch to integration every time you push code to the dev branch. Really helpful for finding the conflicts early.
The blog Matt linked to describes this kind of workflow in much greater detail. The basic workflow can be successful regardless of what CI tool you use (tho Bamboo does have really nice support for it and great JIRA integrations).
I hope this helps!