5

In a project we have a rather formal code review, which is currently done manually and documented in Excel sheets and Word docs.

We would like to improve the current code review process by integrating it into a Git workflow (utilizing tools like Bitbucket Server, which we already have, Gerrit, etc.).

The current idea is that each developer implements features and bugfixes and creates a pull request. This pull request is reviewed by other developers and then merged into our main development branch or not.

We would like to export all pull requests (which are now the code reviews) to formally document them in an offline document. This code review document is a delivery item for our customer.

Is this a feasible approach at all?

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
Simon
  • 1,774

2 Answers2

1

You can take a look at Phabricator. It is a nice all-in-one software project management application which handles code reviews similar to what you described and does a lot more around software development.

I don't want to recommend a tool to you, but I want to show you what idea they have about code reviews, which I consider solid and practicable.

The entire development process within Phabricator is documented, not only code reviews, because it wires all information by using identifiers that get translated into links automatically and produce references with dates, times and users that are involved in actions.

Here is what a code review in Phabricator looks like (to address your question more specifically):

  1. Developer creates a new branch in local git repository and makes a commit with his changes.
  2. Developer starts arc diff to lint and test the changes and to create a code review (called "differential"). Some metadata can be added at this point.
  3. Phabricator receives the differential and makes it available to other developers in this project.
  4. Other developers can comment the changeset and annotate it. The author can update the differential.
  5. The reviewers can accept or reject the differential.
  6. The author can then abandon the differential or commit it (arc land).
  7. The repository receives the commit and wires it automatically with the differential. And the differential is also wired with the commit and/or the actions that lead to the result.

Phabricator is developed very quickly and is itself developed in an own public instance of Phabricator.

Martin Sugioarto
  • 326
1

Bitbucket Server can certainly do this, it has REST APIs for extracting pull request data). If you want something more specific baked into the product then the plugin SDK is available to generate documents automatically.

As others have suggested, this might a good time to review what your customers need (or think they need) and what other ways that could be captured and delivered. It may be that you're already looking at the best available option, but there might be more streamlined alternatives that save you and them time/money.

Disclosure: I work for Atlassian

Rog
  • 111