SQ Official Doc Link: https://docs.sonarqube.org/display/SONAR/Issues

Table of Contents

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

이슈는 다음 다섯가지 심각도 중 하나를 가집니다:

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

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

때문에 새로운 이슈들이 출현하게 됩니다. SonarQube가 제공하는 이슈 워크플로우를 사용해 여러분은 이슈들을 관리할 수 있습니다. SonarQube는 이슈 관리를 위한 일곱가지 기능(이슈를 직접 코드에서 수정하는 것이 아니라!)을 제공합니다:

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" 옵션을 사용해 다수의 이슈에 일괄 적용할 수 있습니다.

Other

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

Browser not supported