Installing and configuring SonarQube with Azure DevOps/TFS

8 min read Our team follows a process adapted from Microsoft’s Release Flow [see: https://blogs.msdn.microsoft.com/devops/2018/04/19/release-flow-how-we-do-branching-on-the-vsts-team/], in which we create a branch off develop (our long-running mostly-stable product), do our work, commit it (with the PBI/Bug number in a comment), push the branch, then go into TFS and create a pull request. TFS will suggest a shortcut link to create a PR for the branch you just pushed to your default branch (in our case develop); or you can click the New pull request button and choose your source and target branches.


Code Quality using SonarQube

4 min read Code quality, best practices and standards are often the distinction between projects that are maintainable, secure and scale well, and projects that need to be rewritten every year. We were in the latter category unfortunately for quite a long time, despite everyone preaching best practices and within a group of quite smart individuals. The problem is we all had our own idea of what best practices to apply, what standards to follow and how we defined quality. We had to find a way to track and improve, then we discovered SonarQube.

SonarQube is a static code analysis tool.

It uses language-specific analyzers and rules to scan code for mistakes, some patterns that are known to introduce security vulnerabilities, and code smells [According to Wikipedia and Robert C. Martin “Code smell, also known as bad smell, in computer programming code, refers to any symptom in the source code of a program that possibly indicates a deeper problem.] …