Peer Reviews (Code reviews)

Owned by Martin Ndegwa
Last updated: Jul 04, 2019

Every time a feature is updated or a bug is fixed, a Peer review or Code review is required before the code/patch is merged to master.

The Developer is required to:

  • Create a PR(Pull Request) to the parent branch, usually master. However it could any other depending on the project set up e.g. develop branch
  • Assign 1 or 2 reviewers to the PR
  • Notify them. While Github does have notifications for the above actions, it is recommended to notify the reviewers you assigned especially depending on urgency

Check out the OpenSRP guidelines for creating PRs here OpenSRP Developer's Guide#PullRequests(PRs)

The Reviewer is required to: 

  • Ensure all the CI status checks as set up on Github pass e.g. Build, Codacy, Code coverage 
  • Perform a manual review of the code. If anything requires an update, add a comment to the corresponding lines on the file within the Github PR
  • Check out the code on your local work station, deploy and :
    • Test the new feature while referencing the corresponding spec/Github issue
    • Test any other related feature the update might affect
    • Test for any possible backward compatibility breaks

If all the above pass, then the reviewer approves the PR.  Note that though Github does have notifications for the above actions, It is recommended to notify the requesting developer once you are done reviewing incase the update/patch is an urgent one.

The developer requesting the PR then follows these steps:

  • Merge the PR code from the issue branch to master
  • Delete the issue branch

In the case that the update required a release/snapshot, the developer is also required to:

NB: If its a release (as opposed to a Snapshot), then create a Release on Github as described here https://help.github.com/en/articles/creating-releases. (Uploading artefacts with the tags is optional)

       Also check out the OpenSRP guidelines here How to create a release APK