Moving from Gerrit to Crucible

Question

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.

Lightsome

I'll forward this question to Sarah Goff Dupont at Atlassian since she just did a two-part blog related to this at blogs.atlassian.com/2012/07/… – Taub

I ended up getting more amazing info that I can currently handle, so it's taking me some time to process it! – Lightsome

Answer 1

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!

Roybal

Answer 2

If you don't mind doing some programming you could use the Jira scripting suit to use Jira workflow transaction to run actual code on your server, and update the issue content / status accordingly. To display Dynamic content (brought from local file or any remote server) you could use the Jira behaviour plugin and by using Javascripts and HTML code.

As I said, it would require some programming, but you could integrate your original workflow with Jira.

A small note- although "XML RPC which Jira still supports but will no longer do any development for" this API is very powerful and have capabilities that lack in some of the other APIs, so even though it won't be future developed you might find it suiting most of your needs as is.

Hope that help.

Lacerate

Answer 3

I've got a ticket open on Bitbucket's tracker right now asking about a something very similar: https://bitbucket.org/site/master/issue/5652/allow-for-pull-requests-to-require

Unfortunately, it seems the answer I've got back from Atlassian is "sorry, we aren't going to do that. Please buy Stash." The problem we have with that is that Stash isn't currently a hosted solution, and we have no plans to set up infrastructure to host it ourselves (in fact, we previously DID, but upon talking to Atlassian ended up migrating to their hosted solutions). I'm not quite sure why they aren't providing this as a "enterprise" feature of Bitbucket, considering they've already done the work in Stash. As it stands all I think I can do is get people to comment on that ticket to show that developers are quite interested in these types of workflows (a feature that would differentiate it from GitHub at that!).

Tiffaneytiffani