Message-ID: <1403606564.405.1417174054118.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_404_223303239.1417174054117" ------=_Part_404_223303239.1417174054117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
While running an analysis, SonarQube raises an issue every time a piece = of code breaks a coding rule. The set of coding rules is defined through th= e quality profile associate= d with the project. Developers can also manually raise issues that cannot be detected by SonarQube (= examples: the implementation of the method does not comply to the functiona= l requirements, the javadoc of the method does not match its implementation= , etc.).
Each issue has one of five severities:
Ideally, the team wouldn't introduce any new issues (any new technical d= ebt). Plugins like Issues R= eport or SonarQube in E= clipse or SonarQu= be in IntelliJ can help developers because they provide the ability to = perform local analyses to check their code before pushing it back to the SC= M. But in real life, it's not always possible to code without any new = technical debt, and sometimes it's not worth it.
So new issues get introduced. SonarQube's issues workflow can help you m= anage those issues. By default, there are seven different things you c= an do to an issue (other than fixing it in the code!): Comment, Assign, Pla= n, Confirm, Change Severity, Resolve, and False Positive. Plugins may add m= ore options, such as Link to JIRA.
These actions break out into four different categories. First up is the = "technical review" category.
Confirm, False Positive, and Change Severity fall into this category, wh=
ich presumes an initial review of an issue to verify its validity. Assume i=
t's time to review the technical debt added in the last review period - whe=
ther that's a day, a week, or an entire sprint. You go through each new iss=
ue and do one of three things:
Once issues have been through technical review, it's time to decide how =
you're going to deal them. You've got up to three choices here, and while t=
he technical review options are mutually exclusive (well, mostly), you may =
find yourself using all three of these on the same issue:
There's only one option under the General category: comment. At any time= during the lifecycle of an issu= e, you can log a comment on it. Comments are displayed in the issue det= ail in a running log. You have the ability to edit or delete the comments y= ou made.
If you've been doing the math, you already know that there's only one op= tion left: Resolve. Use this option to signal that you think you've fixed a= n open issue. If you're right, the next analysis will move it to closed sta= tus. If you're wrong, its status will go to re-opened.
So that's it. That's how SonarQube lets you manage issues: by helping yo= u vet them, organize what to fix now and what to schedule for later, and tr= ack them as your Plan comes together.