This document describes several forms of Crucible Workflow in detail. Depending on the size of your team, there are four different ways that a development team could use Crucible for code reviews. Choose the workflow which suits your team.

 

Lightweight Code Commenting with Crucible (individual)

  1. Author commits new work.
  2. Author creates the review, and adds comments using the easy web interface.
  3. Author summarizes and closes the review, saving the code comments in Crucible's database, which is stored outside the repository.

    Diagram: Workflow for Lightweight Code Commenting

One-to-One Reviews (Agile Pair)

  1. Author creates the review.
  2. Author invites reviewer to take part in the review.
  3. Reviewer creates comments on the code.
  4. Author responds to reviewer comments.
  5. Follow-up comments are made if necessary.
  6. Reviewer finishes own review process.
  7. Author summarizes and closes the review.

    Diagram: Workflow for One-to-One Reviews



For more information on one-to-one reviews, see The Crucible workflow. The workflow process in Crucible is covered in detail within this document.

One-to-Many Reviews Without a Moderator (Agile Team)

  1. Author creates the review.
  2. Author invites reviewers to take part in the review.
  3. Reviewers make comments on the code.
  4. Author responds to reviewer comments, follow-up comments are made if necessary.
  5. Reviewers complete their reviews.
  6. Author summarizes and closes the review.

    Diagram: Workflow for One-to-Many Reviews




 

Formal Group Reviews (CMM Team)

  1. Author creates the review.
  2. Moderator invites reviewers to take part in the review.
  3. Reviewers make comments on the code.
  4. Author responds to reviewer comments.
  5. Follow-up comments are made if necessary.
  6. Each discussion point is settled by the Moderator.
  7. Moderator summarizes and closes the review.

    Diagram: Workflow for Formal Group Reviews


    To see a simple example of how to use Crucible with two people, see The Crucible workflow.

Attachments:

Lightweight code commenting (text/xml)
One to One Review (application/gliffy+xml)
Moderated review (text/xml)
Lightweight code commenting.png (image/png)
Moderated review.png (image/png)
one-to-one-review (application/gliffy+xml)
one-to-one-review.png (image/png)
Lightweight code commenting (text/xml)
Lightweight code commenting.png (image/png)
Lightweight code commenting (text/xml)
Lightweight code commenting.png (image/png)
one-to-one-review (application/gliffy+xml)
one-to-one-review.png (image/png)
one-to-one-review (application/gliffy+xml)
one-to-one-review.png (image/png)
Lightweight code commenting (application/gliffy+xml)
Lightweight code commenting.png (image/png)
Moderated review (application/gliffy+xml)
Moderated review.png (image/png)
One to One Review.png (image/png)

Comments:

How does the moderator settle the discussion point as mentioned in formal group review flow above?

Posted by somooi at Feb 25, 2013 08:24

"Author invites reviewer"

The "invites" word seems a bit weak.  From what I can tell, the author is effectively assigning the review to reviewers.

From a Lean-Agile perspective, the workflow should not assign (i.e., "push") reviews onto others.  Rather, folks should join (i.e., "pull") reviews based on the review backlog.

Posted by admin126 at Apr 02, 2013 20:18

Could you please fix the diagram links?  They say "Unknown macro: gliffy".

 

Posted by at Aug 20, 2013 17:39

Unfortunately, the Gliffy plugin is currently disabled on confluence.atlassian.com.

Posted by pwatson at Aug 21, 2013 00:30

 

How do you set up a review of multiple peoples code ensuring that they get emailed about comments? i.e. one team wants another team to review code but the comments should not go to a central author but instead to the person who made the changes? Or a number of people made changes before the code went into review?

Posted by at Oct 01, 2013 15:19