-
정적 코드 분석 도구 Sonarqube 도입 제안웹 개발 2024. 2. 24. 09:37반응형
1. SonarQube 소개
- SonarQube는 오픈 소스 플랫폼으로, 소프트웨어 개발 프로세스의 여러 단계에서 코드의 품질을 관리하고 개선하는 데 사용됩니다. 이는 정적 코드 분석을 통해 코드 품질을 평가하고 지속적인 통합 및 개선을 지원합니다.
- 20개 이상의 프로그래밍 언어에서 버그, 코드 스멜, 보안 취약점을 발견할 목적으로 정적 코드 분석으로 자동 리뷰를 수행하기 위한 지속적인 코드 품질 검사용 오픈 소스 플랫폼이다. 소나소스(SonarSource)가 개발하였다. 소나큐브는 중복 코드, 코딩 표준, 유닛 테스트, 코드 커버리지, 코드 복잡도, 주석, 버그 및 보안 취약점의 보고서를 제공한다.
(https://ko.wikipedia.org/wiki/소나큐브)
비교 정적 분석 동적 분석 점검 대상 프로그램 소스 코드 실제 애플리케이션 평가 기술 기존의 패턴 비교 HTTP 메세지의 변경 점검 점검 단계 애플리케이션 개발 시점 애플리케이션 운영 시점 결과 소스의 라인별 결과 표시 요청 / 응답에 따른 결과 1.1 소나 큐브 구성
- SonarQube 는 아래와 같은 구성을 갖습니다.
- SonarQube Server : SonarQube Scanner 로 업로드한 소스 코드 분석
- SonarQube Database : SonarQube 분석 결과 저장
- SonarQube Scanner : SonarQube 분석을 위해 소스 코드 업로드
!! 여기서 잠깐!! 소나큐브 스캐너란
- 소나큐브 플랫폼과 프로젝트의 소스 코드 간의 인터페이스를 제공하는 도구입니다. 이 도구는 소나큐브 서버로부터 프로젝트 설정을 받아 소스 코드를 분석하고 분석 결과를 서버에 전달
- 프로젝트 설정 로드
: 소나큐브 서버에서 프로젝트 설정을 로드하여 로컬에서의 분석을 위한 준비를 합니다. - 소스 코드 분석
: 프로젝트의 소스 코드를 분석하여 코드 품질, 보안 취약점, 코드 스멜 등을 식별합니다. - 분석 결과 전송
: 분석 결과를 소나큐브 서버로 전송하여 대시보드 및 보고서에 표시될 수 있도록 합니다. - 분석 환경 구성
: 분석을 위해 필요한 환경을 설정하고 분석에 필요한 의존성을 관리합니다. - 소나큐브 스캐너를 jenkins 나 github 등을 이요해서 구성할 수 있고, 마찬가지로 docker image 를 받아서 사용할 수 있지만, 다양한 빌드 도구(Maven, Gradle, Ant) 와 통합되어 소나큐브 분석이 자동으로 실행되도록 설정할 수도 있다.
- 프로젝트 설정 로드
2. SonarQube 설치
2.1 사전 요구 사항
- Java Development Kit (JDK) 설치
- 데이터베이스 (예: MySQL, PostgreSQL, 등) 설치
- SonarQube 서버 다운로드
2.2 설치 단계
- Docker image pull 및 실행
1docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqubecs - docker에서 SonarQube 컨테이너가 백그라운드에서 실행되며, 호스트의 9000번 포트를 통해 SonarQube 웹 인터페이스에 접속할 수 있습니다.
- Docker는 이미지가 로컬에 없는 경우 자동으로 Docker 허브 또는 다른 이미지 레지스트리에서 해당 이미지를 가져옵니다. 따라서 sonarqube 이미지가 로컬에 없는 경우 Docker는 자동으로 Docker 허브에서 해당 이미지를 pull하게 됩니다. 그런 다음에는 pull된 이미지를 사용하여 컨테이너를 시작하고 실행합니다.
2.2 Bitbucket 환경 구성
>> 우리는 Bitbucket 환경이라 해당 내용으로 작성하였습니다.
찾아보니 해당 내용으로 구성할 수 있었는데.. 우리 팀 개발 환경에는 Bamboo CI/CD 를 사용하지 않고 있고,
Bitbucket 에 내장된 CI/CD 를 사용하기 위해 bicbucket pipelines 를 직접 사용하고 있다.그래서 piplelines 에 docker 환경을 구성할 수 있어서 sonarqube 서버를 구성하여 해당 내용을 채우면 될 것이다.!!
Sonarqube 서버 구성을 위해.. 또 관련 부서에 요청해야 한다... ㅎㅎ;;
3. SonarQube 설정
3.1 프로젝트 추가
- 소스 코드를 SonarQube에 연결하고 분석을 실행하기 위해 프로젝트를 추가합니다.
12345678910111213141516plugins {...id 'org.sonarqbue' version '4.4.1.3373'}sonarqube {properties {property "sonar.host.url", "http://localhost:9000/"property "sonar.login", "squ_7fb2d32e25657fe979273e43e3083cac77b3161f"property "sonar.coverage.jacoco.xmlReportPaths", "${projectDir}/reports/jacoco/test/jacocoTestReport.xml"property "sonar.language", "java"property "sonar.sourceEncoding", "UTF-8"property "sonar.sources", "src/main/java"}}cs 3.2 정적 분석 실행
- SonarScanner를 사용하여 프로젝트를 분석하고 SonarQube에 결과를 제출합니다.
4. SonarQube 사용
4.1 대시보드 확인
- SonarQube 대시보드를 통해 프로젝트의 코드 품질 및 보안 문제, 새로운 버그 및 코딩 규칙 준수 상태 등을 확인할 수 있습니다.
- overall code 는 전체 코드, new code 는 새로 개발된 코드.
** Issue Serverity
- Blocker : 운영 환경에서 소프트웨어의 동작에 영향을 줌, 가능성이 높은 버그
Memory Leak, unclosed JDBC connection 등 반드시 즉각 수정되어야 하는 버그 - Critical : 운영 환경에서 응용 프로그램의 동작에 영향을 줄 가능성이 낮은 버그 또는 보안 결함을 나타내는 문제
빈 Catch Block, SQL 인젝션 등으로 즉각 리뷰가 필요함 - Major : 개발자의 생산성에 영향을 줄 수 있는 품질 결함
중복 코드 블록, 사용되지 않은 파라미터 - Minor : 개발자 생산성에 약간 영향을 줄 수 있는 품질 결함
- Info : 버그 혹은 품질 결함이 아닌 단순 정보성
- Reliablility & Vulnerablilities Rating & Security Review
- A : 0
- B : 1개 이상의 Minor
- C : 1개 이상의 Major
- D : 1개 이상의 Critical
- E : 1개 이상의 Blocker
- Maintainablilitiy Rating
- 유지보수성 측정 > 유지보수와 관련된 이슈를 수정하는데 걸리는 시간
- 수정비용 / 개발비용
(소스코드 한줄이 0.06K 로 산정, 전체 소스코드 대비 수정 해야 할 소스 코드) - A : 5% 이하
- B : 6 ~ 10%
- C : 11 ~ 20%
- D : 21 ~ 50%
- E : 50% ~
- Bugs
- 일반적으로 잠재적인 버그 혹은 실행시간에 예상되는 동작을 하지 않는 코드를 나타낸다.
- Bugs 의 High/Low 는 아래의 조건에 따라 결정된다.
- Impact : 어플리케이션을 중단시킬 영향을 주는가? 저장된 데이터에 손상을 줄 수 있는가?
- Vulnerabilities
- 해커들에게 잠재적인 약점이 될 수 있는 보안상의 이슈를 말한다.
- SQL 인젝션, 크로스 사이트 스크립팅과 같은 보안 취약성을 찾아낸다.
- Vulnerabilities의 High/Low 는 아래의 조건에 따라 결정된다.
- Impact : 이 취약점을 악용하여 사람 혹은 자산에 심각한 피해를 주는가?
- Likelihood : 해커가 이 취약점을 악용할 가능성은 얼마나되는가?
- Security Hotspots
- 취약성이 존재하는지 여부를 평가하기 위해 수동 검토가 필요한 보안에 민감한 코드에 대한 정보
- Code Smell
- 심각한 이슈는 아니지만 베스트 프렉티스에서 사소한 이슈들로 모듈성(modularity),
- 이해 가능성(understandability), 변경 가능성(changeability), 테스트 용의성(testability), 재사용성(reusability) 등이 포함된다.(=유지관리에 관련해서 코드에서 더 심오한 문제를 일으킬 가능성이 있는 프로그램 소스 코드)
- Code Smell 의 High/Low 는 아래의 조건에 따라 결정된다.
- Impact : 코드스멜로 인해 유지보수자(개발자)가 버그를 만들 수 있는가?
- Likelihood : Worst 케이스가 일어날 가능성은 얼마나되는가?
- Duplications
- 코드 중복은 코드의 품질을 저해시키는 가장 큰 요인 중 하나이다.
- Unit Test
- 단위테스트 커버리지를 통해 단위 테스트의 수행 정도와 수행한 테스트의 성공/실패 정보를 제공한다.
- Complexity
- 코드의 순환 복잡도, 인지 복잡도를 측정합니다.
- Size
- 소스코드 사이즈와 관련된 다양한 지표를 제공합니다.
4.2 보고서 및 알림
- SonarQube는 분석 결과를 기반으로 사용자에게 보고서 및 알림을 제공하여 코드 품질을 지속적으로 개선할 수 있도록 도와줍니다.
- 새로 작성된 코드
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455public class SonarQubeTest {public static void main(String[] args) {double num1 = 10.0;double num2 = 0.0;try {double result = num1 / num2;System.out.println("결과: " + result);} catch (ArithmeticException e) {System.out.println("0으로 나눌 수 없습니다.");}}}class Calculator {public void calculatorTest() {Scanner scanner = new Scanner(System.in);System.out.println("계산할 첫 번째 숫자를 입력하세요:");double num1 = scanner.nextDouble();System.out.println("사용할 연산자를 입력하세요 (+, -, *, / 중 하나):");char operator = scanner.next().charAt(0);System.out.println("계산할 두 번째 숫자를 입력하세요:");double num2 = scanner.nextDouble();double result;switch (operator) {case '+':result = num1 + num2;break;case '-':result = num1 - num2;break;case '*':result = num1 * num2;break;case '/':if (num2 != 0) {result = num1 / num2;} else {System.out.println("0으로 나눌 수 없습니다.");return;}break;default:System.out.println("올바른 연산자를 입력하세요.");return;}System.out.println("결과: " + result);}}cs - Reliability 의 D 등급의 1 Bugs 내용
- 9 개의 Maintainability
!! 하지만 역시나 개발에선 무조건적인 건 없다.!!!
위는 Querydsl 로 작성된 조회문인데.. inMemberId() 메소드에 대해 nullPointException 을 이야기하고 있지만, 사실 해당 where 절이 null 이면 전체 조회로 되기 때문에 개발자가 의도한 내용으로 볼 수 있습니다.
아마.. sonarqube 로 현재 사용중인건 java 코드 분석이기 때문에.. 이러한 프레임워크에 대한 내용까지 포함되어 제시해줄 순 없는 것 같습니다.
4.3 품질 게이트 설정
- SonarQube를 사용하여 품질 게이트를 설정하여 특정 품질 기준을 충족하지 못하는 경우 빌드를 실패하도록 구성할 수 있습니다.
5. 마무리
5.1 정기적인 분석 실행
- SonarQube를 사용하여 정기적으로 코드를 분석하고 품질을 모니터링하여 프로젝트의 지속적인 개선을 유도할 수 있으니 이후 서버 구성을 하여 품질 게이트 설정하는 방향으로 가져가도 좋겠다는 생각을 하였습니다.
- 현재 Pull Request 에 테스트 코드 커버리지 측정과 마찬가지로 해당 내용의 기준을 정해 빌드 실패와 같은 내용으로 내부 개발 프로세스를 가져갈 예정.~~!~ 바램~!~!
반응형'웹 개발' 카테고리의 다른 글
Pageable 을 파헤치자. (39) 2024.04.29 자바 HashTable 과 HashMap (0) 2024.03.28 User-Agent 정보 가져오기 (0) 2024.03.20 @RequestBody, @ResponseBody ?? (2) 2024.01.27 Flyway (0) 2022.12.15