Message-ID: <1750781321.333.1432612404628.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_332_1863803609.1432612404628" ------=_Part_332_1863803609.1432612404628 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 associated with th= e project. Developers can also manually = raise issues that cannot be detected by SonarQube (examples: the i= mplementation of the method does not comply to the functional 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 Report or = SonarQube in Eclipse&nb= sp;or SonarQube in IntelliJ can help= developers because they provide the ability to perform local analyses to c= heck their code before pushing it back to the SCM. But in real life, i= t's not always possible to code without any new technical debt, and sometim= es 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.= p>
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 issue, y= ou can log a comment on it. Comments are displayed in the issue detail in a= running log. You have the ability to edit or delete the comments you 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.