Code Review Version 1.0.

1
SOP-00479 18-Jun-2021
(Standard Operating Procedure)

Objective
Define the standard procedures for the control of code review with Opentext Engineering.

Scope
This SOP covers the aspects of the process that development should follow during a code review.

Roles & Responsibilities

Roles Description Privileges

REVIEWER(S) Person(s) that will perform the review of the Reviews the code
code
Annotates the code with comments to
Typically, a Developer or Architect plays this highlight potential issues in terms of both
role or someone familiar with the materials to security and functional aspects
be reviewed, especially if there are security
concerns
Reviewers must be familiar with the
technology and materials being reviewed.
Reviewers must also have prior training and
knowledge in secure coding techniques
Can be the same Person as the Moderator
Cannot be the Author

MODERATOR / Person who moderates the review between Moderates the review process between
MAINTAINER an author and the reviewer(s) the Author and Reviewer(s) to ensure
that all findings/potential issues are
Person usually has led or management
resolved
responsibilities (i.e., Scrum Master, Lead
Engineer, Quality Lead, Product Owner, Summarizes the findings of the review
Development Manager, Director, VP, Dev from various reviewers
Lead) that has the authority to sign off the
Provides sign-off and closes the review
code.
session
Can be the same Person as the Reviewer
Performs merges to master/production
Cannot be the Author branch in Source Code Revision Control
System

AUTHOR Owner/author of the code being reviewed. Initiates review process

Anyone can request things to be reviewed Responds to comments from the
reviewers: This may include creating a
defect in the defect tracking system and
making necessary changes to the code
to meet requirements

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 1 of 4
 Code Review Version 1.0.1
SOP-00479 18-Jun-2021
(Standard Operating Procedure)

Tools Supported
ReviewBoard https://codereview.otxlab.net
Merge Requests internal to Gitlab https://gitlab.opentext.net
Crucible http://wcu-dtsfshprd01.lab.opentext.com:8060/ (currently being deprecated please use other
systems) Contact [email protected] for help in migration

Overall guidelines
• No code changes should be submitted for build without a code review from at least one other person
that is not the author.
• All code reviews should be performed using the pre-commit review model where all code changes are
reviewed before it goes into the mainline from which a production build is created.
o In the future, as our source code tools allow, all main branches will be locked down and only
Moderators/Maintainers will be able to merge commits.
• All code reviews must contain a statement explicitly stating that the changes were reviewed and that
there were no security issues found.
• Code review is performed over small, logically complete pieces of code such as a feature, task, bug fix,
or improvement. Avoid large code reviews where possible.
• If there is a security issue found in the code review process, a Jira ticket needs to be created to address
it with the proper labels, etc. This issue must be addressed before the merge can take place and
included in the review comments.
• A summary must be provided by the moderator/maintainer in the closing of a review. This summary
should contain the status of the following categories:
o General Security findings
o OWASP

Optional Recommendations
The closing summary should also contain the status on any PCI, FedRAMP, HIPAA, or other specialized
compliance or audit issues contained in the code changes for those teams with special compliance
requirements. A Jira ticket should be created to track the issues from the review to be sure that they are
addressed, and they should be given high priority.

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 2 of 4
 Code Review Version 1.0.1
SOP-00479 18-Jun-2021
(Standard Operating Procedure)

Code review steps in ReviewBoard

1. Make a change to your local source tree.
2. Create a review request for your new change.
3. Publish the review request and wait for your reviewers to see it.
4. Wait for feedback from the reviewers.
5. If reviewers have requested changes:
a. Update the code in your tree and generate a new diff.
b. Upload the new diff, specify the changes in the Change Description box, and publish.
c. Jump back to step 4.
6. If reviewers approve
a. Submit your change to the repository.
b. Click Close ‣ Submitted on the review request action bar.

Code review steps in Gitlab

1. Write code and push it to a separate branch.
2. Create a merge request.
1. A merge request is meant for merging code from one branch to another. The main merge request
parameters (specified when creating a merge request) are:
1. Source branch
2. Target branch
3. Title
4. Description
5. Assignee
3. Wait until your request is accepted or declined with comments about necessary fixes
4. Take part in discussions about fixes. (GitLab allows you to respond to comments.)
5. Make fixes.
6. Push changes to your branch.
7. Open a new merge request if the last one was closed. If the merge request wasn’t closed, it will
automatically update till the last commit at push.
8. Report implemented fixes by commenting on the merge request or in some other way (by messenger or
directly).
9. Once the merge request is approved the maintainer completes the Merge Request and the code is merged
into the protected branch. (If applicable be sure to delete the source branch when the merge request is
committed)
This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 3 of 4
 Code Review Version 1.0.1
SOP-00479 18-Jun-2021
(Standard Operating Procedure)

Addendum
Example items to look for in a Code Review:
https://confluence.opentext.com/display/EA/Code+Review+Checklist+Examples

Approval
The following approvals are required for this document:
Common Engineering Management
Engineering Architecture Team
Management Representative of the PDS or designate
As of the effective date, this procedure is the standard and supersedes any previous versions.

Revision History
Rev # Date Author Description

1.0.0 25-May-2021 Joshua Wojcik Original

Ben Tse
David Wink

1.0.1 18-Jun-2021 Carmie Adkins Trivial update to add Joshua Wojcik and Ben Tse as
original authors

This paper copy is not controlled. Please check the QM Dashboard on the Corporate Intranet for the most current version.
Open Text Confidential. For Internal Use Only. Do Not Distribute.
Page 4 of 4