Developer Guide Best practice when coding with AICS

GitHub Workflow

This section will demonstrate the best practices for issues, pull request, and code reviews.

Issue

Open new issues whenever you have new features, to-do tasks, or bug-fix requirement. The issues can be assigned to assignees, who are working on specific issues and pull requests. Assignees are mainly responsible for making the discussion forward, assigning someone to fix it, merging PR or close the issues at the end.

Pull request

The following image is a full demonstration of the whole lifecycle of a pull request. This pull request is passing a few status checked, including travis-ci’s jobs and code quality check by sonar cloud. After the review team has reviewed, it’s ready to be merged.

You can open a Pull Request at any point during the development process. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change.

Sonar Cloud Scanning

Every Pull Request must be scanned by Sonar Cloud and pass the quality gate

Pull Request Quality Gate

Release Process Quality Gate

  • Formula is here
  • The final score must higher than 4.0
  • Please check Repo Tab in SES Dashboard

Closing issues by keywords

By including certain keywords in the first comment of the pull request, you are able to associate issues with code. For example, to close an issue numbered 4, you could use the phrase fixes #4.

Warning : The keywords will take effect only when it is included in the **first comment** of your pull request. If you forgot to write it, you can still edit the first comment.

When your Pull Request is merged, the related issues are also closed. For more keywords, check out Closing issues using keywords.

References

Some useful links to understand branch-based workflow: