Create sonarqube.md (#132)

* Create sonarqube.md

* Update sonarqube.md

* Update sonarqube.md

Updated in light of feedback received from a team we ran an experiment with: to use the SonarQube Way, and to fail the builds.

* updated quality checks to include more detail around sonarqube, moved sonarqube to tools folder

* code review fixes

* code review fixes 2

Co-authored-by: snehal vahule <[email protected]>
Co-authored-by: David Lavender <[email protected]>
Co-authored-by: David Lavender <[email protected]>

Author: 3 people

.DS_Store

@@ -21,7 +21,7 @@ Everything (including [infrastructure](../practices/cloud-services.md)) should b
   * All code is version controlled.
   * The mainline branch (e.g. `master`) is protected: no force-pushes are allowed and code reviews, tests and any other automated checks must pass before pull/merge requests can be merged. Administrators should be subject to the same rules.
   * In general, squash merges are preferred for cleaner history. This does rely on merges being small, as should be the practice in any case.
-* Code changes should be automatically checked for code quality using tools like [SonarQube](https://www.sonarqube.org) (as well as via IDE plugins).
+* Code changes should be automatically checked for code quality using tools like [SonarQube](../tools/sonarqube.md) (as well as via IDE plugins).
 * Code should be automatically scanned for secrets or other sensitive data (see [security](../practices/security.md) for details)
 * Prefer well structured and expressive code over extensive documentation to avoid documentation getting out of date.
 * Design the interface prior to the implementation and choose vocabulary to make it coherent. This includes external interfaces (e.g. REST API) and internal interfaces of classes, method signatures etc.