A Simple Code Review Workflow in Unfuddle TEN

Apr 6, 2017 Joshua W. Frappier

You should include code review in your development workflow

It can be intimidating to get started with git merge requests and code review and integrating them into your existing workflows. But as your projects and your team grow, having these built into your processes can significantly aid your development. Here are a few benefits you will see:

  • Code review facilitates knowledge sharing across your team.
  • Code review helps you maintain a more unified and consistent code base.
  • Code review helps you make better estimates.
  • Code review prevents technical debt from creeping into your projects.
  • Code review allows you to take more vacations.
  • Code review will save your team a lot of time in the long-run.

While it may sound complicated, Unfuddle TEN makes it very easy to get started with code review in your team. Here's how it works.

Using Branches in Git

You probably track bugs, issues, and upcoming features for your products in your tasks. That's great! But are you using branches in your git repository to maintain a healthy workflow? Many teams make code changes right in the master branch of their repositories. They then close the task and move on. This can cause many problems and make it more difficult to undo changes to the code.

The taskboard

Rather than working only in master, code review depends on branching. Before working on any new task, a developer should first create a branch and make all relevant modifications in that branch. When the work is complete, then the developer should create a merge request on the task in Unfuddle TEN.

Merge Requests

Merge requests give your team the opportunity to review and comment on the work BEFORE it gets merged into the master branch.

For example, if we are working to resolve a bug in our product, such as the one below:

A task representing a bug

We would first create a branch called "12-bat-gloves-bug" and make the necessary changes in that branch. When finished, we push our branch up to the repository in Unfuddle TEN. Then we create a merge request from the task in Unfuddle TEN, specifying the branch where we did our work.

Creating a merge request

Now the task has some new tabs that show the files and changes included in the merge request. Our team members can now easily see that this task has an open merge request waiting for review.

An open merge request

Now, it's time for the team to help out. Team members have the opportunity review each change and make comments right inline in the code. These are some of the types of issues a code reviewer might look for:

  • Does the code look correct?
  • Does the code conform to the project's style guidelines?
  • Are there any obvious logical errors?
  • Does the code meet the requirements of the original specification?
  • Were any necessary tests written and were they sufficient?
  • Do we need to update any other areas of the code to conform to these changes?

The team can comment on any of the lines in the changed files. These comments will appear inline with the code, but they will also appear on the task activity tab.

Code review comments

Making Modifications

Code review discussions will often lead to modifications to the code. Any necessary updates should be made in the same branch in which the original work was done. Once the new changes are pushed up to the Unfuddle TEN repository, they will automatically be included in the merge request. Conversation can continue until the team reaches consensus on the code and it is ready to merge.

Merging

So we've finished our code review and have decided that the code is good! Alright! Now, we need to merge the code into master. We can do this using our git client, as normal. Or we can perform the merge right within the Unfuddle TEN task:

Finally, once the merge is complete, we can delete the branch where we did our work.

And that's it. You just rocked code review!