71. SonarCloud로 코드 품질 지속적으로 향상 3편

실습 3 : 풀 요청 통합 설정

pull request가 생성 될 때 실행되도록 SonarCloud 분석을 구성하려면 다음 두 부분이 있다.

• SonarCloud 프로젝트에 액세스 토큰을 제공해야 Azure DevOps에 PR 의견을 추가 할 수 있다.
• PR 빌드를 트리거하려면 Azure DevOps에서 브랜치 정책을 구성해야 한다.

 

1. Azure DevOps에서 Personal Access Token을 생성한다.

→ (이전 실습에서 이미 수행하였으므로 불필요 하다.)

 

2. pull requests를 분석하도록 SonarCloud 구성한다. 

• SonarCloud의 Sonar Examples 대시보드로 이동한다. 
• Administration, General Settings를 클릭한다.

 

• Pull Requests 탭을 선택한다.
• Provider를 드롭다운하여 Azure DevOps Services로 설정한다. 
• Personal access token을 붙여넣고 Save를 클릭한다.

 

 

3. Azure DevOps에서 프로젝트에 대한 브랜치 정책을 구성한다.

• Azure DevOps의 SonarExamples 프로젝트로 이동한다.
• Repos, Branches 을 클릭하여 브랜치 리스트틀 확인한다. 
• master의 설정 링크 (“…”)를 클릭하고 Branch policies을 선택한다.

 

• Build Validation 옆에 있는 +를 클릭하여 새 빌드 정책을 추가한다.
• Build definition드롭 다운에서 이전에 작성한 빌드 정의를 선택한다.
• Display name을 SonarCloud analysis로 설정한다.
• Save를 클릭한다.

 

master 브랜치를 대상으로 하는 pull request를 만들 때 Azure DevOps가 SonarCloud 분석을 트리거하도록 구성되었다.

 

 

4. 새로운 pull request를 생성한다. 

이제 파일을 변경하고 새 요청을 작성하여 pull request가 분석을 트리거하는지 확인해야 한다.

• sonarqube-scanner-msbuild/CSharpProject/SomeConsoleApplication/Program.cs의 코드 파일로 이동하여 Edit을 클릭한다.

• 다음 스크린 샷과 같이 빈 메소드를 코드에 추가 한 다음 Commit…을 클릭한다.

나타나는 대화창에서

• 브랜치 이름을 master에서 branch1로 변경한다.
• Create a pull request 확인란을 선택한다.
• Commit을 클릭한 후 다음 화면에서 Create을 클릭하여 Pull Request를 제출한다.

 

 

pull request 통합이 올바르게 구성된 경우 UI는 분석 빌드가 진행 중임을 표시한다.

 

 

5. Pull Request 분석 결과를 검토한다.

결과는 분석 빌드가 성공적으로 완료되었지만 PR의 새 코드가 코드 품질 검사에 실패했음을 나타낸다. 발견된 새로운 문제에 대한 의견이 PR에 게시되었다.

pull request 요청에서 변경되거나 추가된 코드의 유일한 문제만 보고된다. Program.cs 및 기타 파일의 기존 문제는 무시된다.

 

6. 코드 품질 검사에 실패한 경우 pull request를 차단한다.

이 시점에서 코드 품질 검사에 실패한 경우에도 pull request를 완료하고 변경사항을 커밋 할 수 있다. 그러나 코드 품질 검사를 통과하지 않는 한 커밋을 차단하도록 Azure DevOps를 구성하는 것은 간단하다.

• master 브랜치의 Branch Policy 페이지로 이동한다 (master 브랜치는 풀 요청이 병합되기를 원하는 브랜치이므로 여기에서 정책을 조정해야 한다.
• Add status policy을 클릭한다.

이제 사용자는 모든 문제가 해결되었거나 SonarCloud에서 문제가 confirmed 또는 resolved 된 것으로 표시되었으므로 코드 품질 검사에 성공할 때까지 pull request를 병합 할 수 없다.

 

 

 

실습 4: 지속적 배포 시나리오에서 SonarCloud Quality Gate 상태 확인 (미리보기)

** 면책 조항 : 이 기능은 미리보기로 제공되며 최종 버전을 반영하지 않을 수 있다. 자세한 내용은 이 실습 끝에 있는 참고 사항을 참조한다. **

 

Azure DevOps용 SonarCloud 확장 버전 1.8.0부터 배포 파이프라인에 사전 배포 게이트를 사용할 수 있다. Quality Gate가 실패한 경우 배포하려는 아티팩트에 대해 SonarCloud Quality Gate의 상태를 확인하고 배포를 차단할 수 있다.

 

전제 조건 :

• 빌드 파이프라인에서 Publish Quality Gate Result를 활성화 한다.
• 릴리스 파이프라인에 피드를 제공하기 위해 이 파이프라인에 아티팩트를 빌드하고 게시한다.

 

설정 :

1. Pipelines 에서 Releases를 클릭한다.

2. New Pipeline를 클릭한다.

3. 템플릿 선택에서 원하는 템플릿을 선택한다. 이 실습에서는 Empty job을 선택한다.

 

 

4. Stage 속성을 닫는다.

5. Stage 1에서 pre-deployment conditions을 클릭한다.

 

 

6. Gates 옆에 Enabled를 클릭한다.

7. + Add를 클릭 한 다음 SonarCloud Quality Gate status check을 선택한다.

 

 

8. 이 실습에서 가장 빠른 결과를 얻으려면 이 스크린 샷에 따라 평가 옵션을 설정하는 것이 좋다 (Microsoft 설명서에 따라 게이트 평가 흐름의 작동 방식 참조).

 

9. 이 패널을 닫는다.

10. 이제 좌측의 Add an artifact을 클릭한다.

11. 현재는 빌드 아티팩트만 지원된다. 이슈의 프로젝트와 소스 (빌드 파이프라인)를 선택한다. 별명은 빌드 파이프라인에 게시된 이슈의 이름과 일치해야한다. 

12. Add를 클릭한다.

13. CD 트리거를 설정한다.

 

 

14. 이제 파이프라인을 저장할 수 있다.

16. 빌드 파이프라인 섹션으로 돌아가 아티팩트를 작성하는 파이프라인 빌드를 트리거한다.

17. 빌드가 완료되고 성공하면 CD가 자동으로 트리거 된다.

 

 

18. Releases 페이지로 이동한다.

18. 몇 분 후 (이 실습의 8 단계에서 설정 한대로) Quality Gate 확인이 수행되어야하고 (스테이지에서 'go / nogo'를 얻기 위해 두 번 이상) 녹색이면 다음과 같아야 한다.

 

그렇지 않아 실패한 경우 아래 중요한 메모를 읽고 어떻게 발생했는지와 녹색의 Quality Gate를 얻는 방법을 찾는다.

 

이 기능에 대한 중요 참고 사항

• 릴리스 게이트가 작동하려면 빌드 파이프라인에서 Publish Quality Gate Result 태스크를 활성화 해야한다.
• Quality Gate가 실패 상태인 경우 이 상태가 초기 상태로 유지되므로 사전 배포 게이트를 통과 할 수 없다. SonarCloud에서 수정된 현재 문제 또는 다른 문제를 해결하기 위해 다른 커밋을 사용하여 다른 빌드를 실행해야한다.
• 릴리스 파이프라인에서 배포 전 게이트의 현재 동작은 기본적으로 1 일 동안 5 분마다 상태를 확인하는 것이다. 그러나 빌드에 대한 Quality Gate가 실패한 경우 실패한 상태로 남아 있으므로 상태를 다시 확인할 필요가 없다. 이를 알면 게이트가 최대 6 분까지 실패한 후 시간 초과를 설정하여 게이트를 위에서 설명한대로 두 번만 평가하거나 릴리스 자체를 취소 할 수 있다.
• 릴리스의 기본 빌드 아티팩트 관련 Quality Gate 만 검사된다.
• 빌드 중에 여러 분석을 수행하면 모든 관련 품질 게이트가 확인된다. 이들 중 하나의 상태가 WARN, ERROR 또는 NONE이면 릴리스 파이프라인의 품질 게이트 상태가 실패한다.

 

 

 

요약

Azure DevOps Services를 위한 SonarCloud 확장 기능을 사용하면 CI/CD 파이프라인에 자동 테스트를 포함시켜 코드 의미, 테스트 범위, 취약성을 포함한 기술 부채 측정을 자동화 할 수 있다. 또한 분석을 Azure DevOps pull request 프로세스에 통합하여 문제가 병합되기 전에 발견 될 수 있다.