분석 과정에서 SonarQube는 소스 코드가 코딩 규칙을 위반할 때마다 이유를 생성합니다. 프로젝트와 연관된 코딩 규칙 셋은 품질 프로파일(Quality Profile)에서 정의합니다.

이슈는 다음 다섯가지 심각도로 분류합니다:

1. BLOCKER 
   프로덕션 상태의 어플리케이션의 행동에 영향을 미칠 가능성이 높은 버그를 가진 이슈로 memory leak, unclosed JDBC connection 등이 포함됩니다. 이 코드들은 반드시 즉시 수정해야 합니다.
2. CRITICAL
   프로덕션 상태의 어플리케이션의 행동에 영향을 미칠 가능성이 낮은 버그 혹은 보안상의 오류를 가진 이슈로 empty catch block, SQL injection 등이 포함됩니다. 이 코드들은 반드시 즉시 리뷰해야 합니다.
3. MAJOR
   개발자의 생산성에 영향을 미칠 가능성이 높은 품질 오류를 가진 이슈로 uncovered piece of code, duplicated blocks, unused parameter 등이 포함됩니다.
4. MINOR
   개발자의 생산성에 영향을 미칠 가능성이 다소 있는 품질 오류를 가진 이슈로 lines should not be too long, "swtich" statements should have at least 3 cases 등이 포함됩니다.
5. INFO
   버그 혹은 품질 오류에 해당하지 않는 이슈들입니다.

이상적인 경우, 개발팀은 모든 타입의 신규 이슈(신규 기술 부채)를 유입시켜서는 안됩니다. SonarLint for Eclipse, SonarLint for IntelliJ 및 SonarLint for VisualStudio 등을 활용해 개발자들은 SCM에 코드를 푸시하기 전 로컬 코드를 분석을 수행할 수 있습니다. 그러나 모든 경우에 신규 기술 부채가 추가되지 않는다는 것은 비현실적일 수 있으며, 때로는 그럴만한 가치가 없기도 합니다.

때문에 새로운 이슈들이 출현하게 됩니다. 

이슈 컨텍스트 이해 하기

때로 이슈들은 그 자체로 명확하게 이해됩니다. 예를 들어, 여러분의 팀이 네이밍 컨벤션으로 camelCase를 사용하기로 협의했다면, My_variable과 같은 변수 이름은 이슈로 취급되며, 이 이슈의 컨텍스를 이해하는 데는 큰 노력이 필요하지 않습니다. 하지만 이슈가 발생된 이유를 이해하기 위해 컨텍스트를 반드시 이해해야만 하는 경우도 있습니다. 그렇기 때문에 SonarQube는 주요한 이슈 위치(이슈 메시지가 표시됨) 뿐만 아니라, 부수적인 이슈의 위치를 함께 표시합니다. 예를 들어, 부수적인 이슈의 위치는 해당 메소드의 인지 복잡도(Cognitive Complexity)를 증가시키는 부분을 마크하기 위해 사용됩니다.

하지만, 이슈에 영향을 미칠 수 이는 코드 위치를 리스팅하는 것만으로는 컨텍스트를 이해하는 데 충분하지 않는 경우가 있습니다. 예를 들어, 어떤 코드 경로에서 하나의 널 포인터가 역참조 되는 경우, 이를 이해하기 위해서는 이슈 흐름(issue flows) 정보가 필요합니다. 각 흐름은 부수적인 이슈들의 순서로, 실제 문제가 발생한 코드 위치의 정확한 경로를 의미합니다. 코드 상에 따양한 경로가 존재할 수 잇기 때문에 SonarQube는 다중 흐름(multiple flows)를 지원합니다.

이슈 수정

SonarQube는 강력한 issue workflow를 제공합니다. 수정 가능한 이슈 정보는 7가지 입니다:

• Comment
• Assign
• Confirm
• Change Severity
• Resolve
• Won't Fix
• False Positive

위의 기능들은 세 가지로 분류됩니다. 가장 먼저 "테크니컬 리뷰(Technical Review)" 분류를 살펴봅니다:

테크니컬 리뷰

테크니컬 리뷰는 이슈의 유효성을 판단하는 과정이 진행되어야 함을 의미하며, 다음이 이에 해당합니다:

• Confirm
• False Positive
• Won't Fix
• Change Severity
• Resolve

바로 직전 리뷰 기간--일간, 주간, 스프린트 전체가 될 수도 있습니다--에 추가된 기술 부채를 리뷰한다고 가정해봅니다. 신규 이슈를 검토하고 다음 중 한 가지 분류로 설정합니다:

• Confirm - 기본적으로 "맞습니다. 이건 문제네요"라고 확인했음을 의미합니다. 이 과정을 통해 "Open" 상태는 "Confirmed" 상태로 변경횝니다.
• False Positive - 컨텍스트 상에서 이슈를 검토한 후, "문제"이기는 하지만 실제 이슈는 아니라고 판단했음을 의미합니다. 이 경우 "False Positive"로 설정 후 리뷰를 진행합니다. 본 설정 수행을 위해 해당 프로젝트에 대한 Administer Issues 권한이 필요합니다.
• Won't Fix - 컨텍스트 상에서 이슈를 검토한 후, 실제 이슈이기는 하나 실제로는 수정이 필요하지 않다고 판단했음을 의미합니다. 다시 말해, 승인한 기술 부채가 됩니다. 이 경우 "Won't Fix"로 설정 후 리뷰를 진행합니다. 본 설정 수행을 위해 해당 프로젝트에 대한 Administer Issues 권한이 필요합니다.
• Change Severity - 첫 두 옵션 사이의 중간에 위치해 있는 상태의 이슈, 즉, 실제로 문제이기는 하지만 코딩 규칙에서 기본적으로 규정한 만큼 심각하지는 않은--혹은 그보다 더 심각할 수도 있는--이슈를 의미합니다. 사용자는 원하는 대로 심각도록 변경할 수 있습니다. 드롭다운 메뉴를 통해 심각도를 즉시 변경할 수 있지만, 실제 심각도는 다음번 분석을 수행한 후 적용됩니다. 본 설정 수행을 위해 해당 프로젝트에 대한 Administer Issues 권한이 필요합니다.
• Resolve - "Open" 상태의 이슈를 수정했다고 생각한 경우, "Resolve" 상태로 변경할 수 있습니다. 올바르게 수정이 완료된 경우 다음번 분석과정에서 해당 이슈는 "Closed" 됩니다. 그렇지 않은 경우 "Re-Opened" 됩니다.

리뷰 과정에서 많은 이슈들을 "False Positive" 혹은 "Won't Fix"로 설정했다면, 적용된 코딩 규칙들 중 일부는 사용자의 개발 컨텍스트에 적합하지 않음을 의미합니다. 이 경우 품질 프로파일에서 해당 코딩 규칙을 완전히 제외시키거나, 이슈 배제(issues exclusion) 기능을 사용해 해당 이슈들이 특정 부분(혹은 특정 객체 타입)에서 표시되지 않도록 할 수 있습니다. 마찬가지로 심각도 변경이 많은 경우에도 품질 프로파일에서 코딩 규칙 업데이트 여부를 고려해야 합니다.

책임 분담

테크니컬 리뷰가 진행되었다면, 이제 이슈를 해결할 담당자를 결정해야 합니다. 기본적으로 이슈들은 가장 최근의 커미터(이슈가 판별된 시기 기준)에게 할당되지만, 수동으로 담당자를 재지정할 수 있습니다. 이메일 알람 수신 기능을 사용하는 담당자는 이슈 할당시 이메일 알림을 받을 수 있고, 이슈 할당 내용은 내 이슈(My Issues) 리스트 및 내 계정(My Account) 스페이스 등 이슈 정보를 표시하는 모든 영역에 나타납니다.

일반

이슈와 관련된 모든 라이프사이클 과정에서 해당 이슈에 대한 주석을 추가할 수 있습니다. 주석은 issue detail에 표시됩니다. 사용자는 본인이 작성한 주석을 편집/삭제할 수 있습니다.

일괄 변경

위의 모든 변경 작업은 "Bulk Change" 옵션을 사용해 다수의 이슈에 일괄 적용할 수 있습니다.

기타

• 이슈는 코딩 규칙을 기준으로 판단하며, 코딩 규칙들은 품질 프로파일을 통해 관리합니다. 품질 프로파일은 모든 사용자가 볼 수 있으나, 프로파일을 수정하기 위해서는 특정한 권한을 가지고 있어야 합니다.