[BitBucket/Jira] How to enforce distinct sets of Reviewers?

Jonathan Moebius

Hi all,

we are working in a gitflow setup (with feature-branches being merged into master).

In our setup, were we want every piece of code being reviewed by two people. Step one is the ordinary code review, which can be done by anyone who wants to take the challange. This is done on Jira-Task-Level. Step two is a review of all changes prior to the merge with develop. Second stage review is only allowed by a certain group of people. This is done on the level of a feature branch.

The reviews have different focus: Whereas the first is more like general coding quality, the second is an assesment, that the changes do not interfere with our general architectural ideas.

Up to now we have realized this setup with coderevies on the commit-level during the first stage and a pull request directed at the special reviewers in the second stage.

This is not optimal for several reasons. One is, that each commit has to be reviewed individually during first stage, which makes it hard to spot issues which arise between two different commits. Also, if code-reviews are not successful, it is sometimes difficult to asses, which changes were already reviewsd and which ware new.

Ideally, we would like the comfort-functionality of the pull-request mechanism in bitbucket on the level of a jira-task. Is something like that possible? Has anyone similar requirements and found a way to implement it with the jira/bitbucket stack?

 

Kind regards,

Jonathan

Julius Davies _GitBoost_com_

 

I presume "develop" receives all the feature branches, and it's periodically merged into "master"?

Have you considered running pull-requests both for all the feature branches merging into "develop", and also for the periodic merges from "develop" into "master"?

Using a combination of our free Control Freak plugin combined with Bitbucket's own config might work nicely.  I think the following setup would come pretty close to what you described:

- Install Control Freak.

- For your particular repository setup Control Freak to require Pull Requests for "develop" and "master" and to require at least 1 approval for merges into "develop" and "master".

- Also setup Control Freak to require Jira references in commit messages for merges into "develop" and "master".  This way all commits on the feature branches must reference at least one Jira ticket.

- Using Bitbucket's own "Branch Permissions" config set "master" to be read-only ("prevent all changes") EXCEPT for the list (or group) of people that do 2nd phase reviews.  Anyone can still create a pull-request into "master" but only people in exemption list can click the "merge" button.

- Finally, setup Bitbucket's "Default Reviewers" config.  Set "Source Branch" to any to keep things flexible, and set "Target Branch" to "master".  Put in your list of people for the list of reviewers and set the minimal approvals to at least 1.

 

I believe the above combination of config would come together to achieve the control you described, but there are some subtleties:

- Notice that merges into "develop" require 1 approval from anyone, and require a pull-request, but otherwise they are pretty wide open.  Control Freak is handling this.

- But merges into "master" are much more constrained, since they must pass all the Control Freak controls above AS WELL as the "Branch Permissions" and "Default Reviewers" controls.

- Because Control Freak is already requiring all commits into "develop" to have a valid Jira reference, Control Freak is smart enough to skip this check when it checks pull-requests going from "develop" --> "master", since every commit on "develop" has already passed this check.

 

FYI - the "Default Reviewers" feature appeared in Bitbucket Server 4.8.

Note: I don't think there's currently a way to block pull-request creation of pull-requests into "master" than come from other branches aside from "develop".  Hopefully your phase 2 reviewers group would keep on a eye on that and reject those if people tried to create them by mistake.  (Of course sometimes there's a good reason to merge from a different source branch, too).