티스토리 뷰

실습 1: SonarCloud와 통합되는 파이프라인 설정

SonarCloud와 통합되어 SonarExamples 코드를 분석하는 새로운 빌드 파이프라인을 설정한다. 

1. 새 Azure DevOps 프로젝트에서 Pipelines 탭 아래의 Pipelines으로 이동 한 다음 Create Pipeline을 클릭하여 새 빌드 파이프라인을 만든다.

여기에 두 가지 옵션이 있다. YAML editor 또는 classic editor를 사용하여 파이프라인을 구성 할 수 있다.

YAML 편집기를 사용하려면 별도로 제공되는 YAML 파일을 사용해야 한다. 옵션 (YAML 또는 CLASSIC) 중 하나를 선택한다.

 

YAML Editor

1. 오늘은 이 기능을 사용하지 않는다. 우리의 경우 이전에 가져온 git repo의 코드를 이 파이프라인과 동일한 계정에서 바로 분석하려고 한다. 따라서 Azure Repos Git을 선택한다.

 

 

2. 다음 화면에서 앞서 가져온 git 저장소 인 SonarExamples를 선택한다.

 

 

3. 이제 YAML 파일 템플릿을 선택한다. 가져온 리포지토리 예제에서 .NET 코드를 빌드하고 분석 할 것이므로 .NET Desktop YAML 템플릿을 선택하여 시작하겠다.

 

 

4. YAML 편집기가 템플릿 YAML 파일과 함께 열린다. 올바르게 구성하려면 다음 예제 파일처럼 보이도록 조정 (또는 교체)해야한다.

# .NET Desktop
# Build and run tests for .NET Desktop or Windows classic desktop solutions.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/windows/dot-net
 
trigger:
- main
 
pool:
  vmImage: 'windows-latest'
 
variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
 
steps:
- task: NuGetToolInstaller@1
 
- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'
 
- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
 
- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

 

필요에 맞게 사용자 정의해야 한다.

4-1. 빌드 태스크를 수정하고 솔루션에 대한 포인터를 변경한다. ** (솔루션이 저장소의 루트에 없으므로 와일드 카드 추가) :

→ variables에서 이미 처리되어 불필요하다.

 

(빈 공란에 커서를 두고 Show assistant를 클릭한다.)

 

4-2. 자신의 정보로 Sonarcloud 준비 태스크를 수정한다. Sonarcloud 이전 창의 정보를 따라 다음을 수행한다.

→ 이미 생성된 것이 없으므로 (있었다면 수정을 진행한다) "Sonar" 라고 검색하여 Prepare Analysis Configuration을 선택한다.

 

4-2-1 서비스 연결을 설정한다.

4-2-2 the values provided on the Sonarcloud window guide로 태스크를 수정한다. 기본 값이 아닌 생성 된 서비스 엔드 포인트와 조직/프로젝트 이름 및 키 값을 사용한다!! 해당 값을 수정 한 후 Add를 클릭한다.

→ SonarCloud 프로젝트 생성 시 제공된 정보와 위에서 설정한 서비스 커넥션 정보를 사용하여 다음을 완성한다.

 

 

파일 변경을 완료하면 Save and Run을 클릭한다.

 

Quality Gate 활성화

 

Quality Gate를 활성화하고 빌드 요약에 분석 보고서의 요약이 포함될 수 있도록 다음 다음 두 개의 태스크를 마지막에 추가하고 다시 실행한다. 



 

 

클래식 편집기 (이전에 YAML 옵션을 선택한 경우 건너 뛴다)

 

1. Use the classic editor을 선택하여 파이프라인을 구성하려면 Where is your code? 페이지에서 클래식 편집기 사용을 선택한다.

 

 

2. Azure Repos Git를 선택하고 Repository에서 SonarExamples를 선택하고 Default branch…에서 master 를 선택한 다음 Continue를 클릭한다.

 

앞서 설치된 SonarCloud 확장 기능은 Maven, Gradle 등을 위한 SonarCloud 지원 사용자 지정 빌드 템플릿을 제공한다. 템플릿은 표준 Azure DevOps 템플릿을 기반으로하지만 추가 분석 관련 태스크와 일부 사전 구성된 설정이 있다.

 

 

3. .NET Desktop with SonarCloud템플릿을 선택한다.

 

템플릿에는 필요한 모든 태스크와 대부분의 필수 설정이 포함되어 있다. 그러나 몇 가지 추가 설정을 제공해야 한다.

 

 

4. Agent pool에서 Azure Pipelines를 선택한 다음 Agent Specification에서 vs2017-win2016을 선택한다.

구성해야 할 세 가지 설정이 있다.

 

 

5. 이전 sonarcloud 가이드에서 SonarCloud 엔드 포인트 토큰을 가져온다. 이는 해당 시스템에서 사용자 계정을 식별하고 다른 서비스 (이 경우 Azure DevOps)가 해당 계정에 연결할 수 있도록 하는 SonarCloud에서 생성 한 토큰이다. (“새 Sonarcloud 서비스 엔드 포인트 추가의 토큰)

 

(SonarCloud 프로젝트 생성 시 제공된 정보와 위에서 설정한 서비스 커넥션 정보를 사용하여 다음을 완성한다.)

 

 

6. [선택 사항]  Publish Quality Gate Result 스텝을 활성화 한다.

 

이 스텝은 릴리즈 파이프라인과 함께 pre-deployment gate를 사용할 필요가 없다. 이 스텝을 사용할 수 있으면 분석 결과의 요약이 작성 Summary 페이지의 확장 탭에 나타난다. 그러나 이것은 SonarCloud의 처리가 끝날 때까지 빌드의 완료를 지연시킬 것이다.

 

 

9. 빌드를 저장하고 대기열에 넣는다. 빌드가 완료되면 다음과 같은 내용이 표시된다.

 

 

10. Publish Quality Gate Result 스텝을 활성화 한 경우 빌드 요약 위에 분석 보고서의 요약이 포함된다.

빌드 요약에서 Detailed SonarCloud Report 링크를 클릭하여 SonarCloud에서 프로젝트를 열거 나 SonarCloud로 이동하여 프로젝트를 본다.

 

품질 게이트 결과를 보려면 첫 번째 보고서를 실행 한 후 “Set New Code Definition”을 선택하고

 

“Previous Version”을 선택해야 한다. 다음 파이프라인 실행은 Quality Gate 결과를 얻을 수 있다.

 

 

이제 SonarCloud에 새 조직을 만들고 분석을 수행하고 빌드 결과를 SonarCloud에 푸시하도록 Azure DevOps 빌드를 구성했다.

 

 

 

실습 2 : SonarCloud 보고서 분석

SonarCloud 대시 보드에서 SonarExamples 프로젝트를 연다. Bugs and Vulnerabilities에서 버그가 발견 된 것을 확인할 수 있다.

 

이 페이지에는 Code Smells, Coverage, Duplications  Size와 같은 다른 메트릭이 있다. 다음 표는 이러한 각 용어를 간략하게 설명한다.

용어 설명
Bugs 코드에서 잘못된 것을 나타내는 문제. 이것이 아직 깨지지 않았다면, 아마도 최악의 순간에 일어날 것이다. 이 문제를 해결해야 한다. 
Vulnerabilities 공격자의 잠재적인 백도어를 나타내는 보안 관련 문제
Code Smells 코드의 유지 관리 관련 문제. 그대로 유지한다는 것은 최상의 유지 보수 담당자가 코드를 변경하는 것보다 시간이 많이 걸리는 것을 의미한다. 최악의 경우 코드 상태에 혼동되어 변경시 추가 오류가 발생한다.
Coverage 단위 테스트와 같은 테스트로 실제로 테스트중인 프로젝트 코드의 비율을 확인하기 위해 코드 범위가 사용된다.  버그를 효과적으로 방지하기 위해 이러한 테스트는 코드의 상당 부분을 연습하거나 'cover' 해야한다. 
Duplications duplications decoration은 소스 코드의 어떤 부분이 복제되는지 보여준다.
Size 명령문, 함수, 클래스, 파일 및 디렉토리 수를 포함하여 프로젝트 내 코드 라인 수를 제공한다. 

 

중요
 : 이 예에서는 버그 수와 함께 신뢰성 등급이라는 문자 C가 표시된다. C는 이 코드에 하나 이상의 주요 버그가 있음을 나타낸다. 신뢰성 등급에 대한 자세한 내용을 보려면 여기를 클릭한다. 규칙 유형에 대한 자세한 내용은 여기를 참조하고 심각도에 대한 자세한 내용은 여기를 참조한다.

 

1. Bugs 수를 클릭하여 버그의 세부 사항을 본다. Issues 페이지가 나타난다.

 

 

2. 코드를 탐색하려면 버그를 클릭한다. Program.cs 파일의 Change this condition so that it does not always evaluate to ‘true’; some subsequent code is never executed. 라는 에러가 확인된다.

 

 

3. 테스트에서 다루지 않는 코드 줄을 확인할 수 있다.

 

샘플 프로젝트는 매우 작으며 기록 데이터가 없다. 그러나 SonarCloud에는 더 흥미롭고 현실적인 결과를 가진 수천 개의 공개 프로젝트가 있다.

 

 

3편에서 계속

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함