Code Review Guidelines

Checklist to be followed during code reviews.

General rules - Mandatory

1. All the branches/commits should be associated with JIRA ID.

2. No direct pushes to develop/ branch - raise PR from feature branch -> develop, code reviewed , then merge to develop.

3. Merge develop to master when ready for production by creating PR from develop -> master

4. Remove direct push access to develop and master.

5. When creating a pull request, move jira status -> code review -> assign to code reviewer(peer reviews also can be done)

6. Test the primary functionality of the PR is working.

7. Understand the context of the user story and its impact.

8. Once review comments are passed, PR is merged, move JIRA status -> done

9. Clean up feature branches as and when required.

10. Master should be always up-to-date with production code.

11. Release branches / release tagging should be followed (particularly for mobile projects).

12. For big features, create a feature branch and create small branches from that feature branch and merge them in feature branch so at the end one feature branch will be merged to develop.

13. Try to create smaller branches and smaller PRs, so that code reviewing will be easy.

14. Commit messages should be relevant to what is done in the code.

git commit -m "[XDS-100] - please use this format for commit messages"

14.Naming Convention of branches:

1. feature/featureName

2. bug/bugName

3. hotfix/hotfixName

4. release/releaseName

5. Use "WIP" for branches with Work in Progress.

Tech Specific - Coding standards, architecture guidelines

iOS:

1. Unit tests

2. Fix warnings - IDE warnings

3. Linting tool warnings/errors fixed for code standards and code quality (swiftlint for iOS)

Android:

PHP:

1.PRs should pass Sonar Cloud quality analysis

JAVA:

1.PRs should pass Sonar Cloud quality analysis