SonarQube를 구현하고 엄청난 잠재력을 실현한 방법

우리는 National Settlement Depository의 DPO 시스템(Alameda 예탁소 및 청산 회계 시스템에 추가)의 기존 개발 프로세스에 대한 코드 품질의 지속적인 분석 및 측정을 위해 SonarQube 플랫폼을 구현한 경험을 공유하고 싶습니다.

국립결제예탁소(모스크바 거래소 기업 그룹)는 금융 인프라의 핵심 기업 중 하나로 50조 루블이 넘는 러시아 및 외국 발행인의 증권을 보관하고 회계 처리합니다. 시스템에서 수행되는 작업량이 증가하고 기능이 지속적으로 확장됨에 따라 시스템의 고품질 소스 코드를 유지해야 합니다. 이 목표를 달성하기 위한 한 가지 도구는 SonarQube 정적 분석기입니다. 이 기사에서는 우리 부서의 기존 개발 프로세스에 SonarQube 정적 분석기를 원활하게 구현한 성공적인 경험을 설명합니다.

학과에 대해 간략하게

우리의 역량에는 NSD 고객에 대한 지불, 전자 문서 관리(EDF), 거래 저장소 메시지 처리(장외 거래 등록), 고객과 NSD 간의 전자 상호 작용 채널 등의 모듈이 포함됩니다. 일반적으로 운영 활동의 기술적 측면에서는 수행해야 할 작업이 많습니다. 우리는 요청에 따라 작업합니다. 운영 담당자의 신청서는 분석가에 의해 처리됩니다. 분석가는 고객의 요구 사항을 수집하고 이를 프로그램에 어떻게 적용해야 하는지에 대한 비전을 제시합니다. 다음은 표준 계획입니다. 코드 개발 – 테스트 – 시험 운영 – 생산 회로에 대한 코드를 직접 고객에게 전달합니다.

왜 SonarQube인가?

이는 코드 품질 관리를 위한 플랫폼을 구현하는 우리 부서의 첫 번째 경험입니다. 이전에는 코드 검토만 수행하여 수동으로 수행했습니다. 그러나 작업량이 증가함에 따라 이 프로세스의 자동화가 필요합니다. 또한 팀에는 내부 개발 규정을 잘 알지 못하고 실수를 더 많이 하는 경향이 있는 경험이 부족한 직원도 포함되어 있습니다. 코드 품질을 제어하기 위해 정적 분석기를 구현하기로 결정했습니다. SonarQube는 이미 일부 NSD 시스템에서 사용되었기 때문에 긴 선택의 여지가 없었습니다. 이전에는 다른 부서의 동료들이 이를 사용하여 Alameda 시스템(NSD의 자체 예탁 및 청산 회계 시스템), CFT(회계 유지 관리, 대차대조표, 필수 및 내부 보고 준비를 위한 정보 시스템), 다른 시스템. 실험을 위해 SonarQube 무료 버전부터 시작하기로 결정했습니다. 그럼 우리의 경우로 넘어 갑시다.

구현 프로세스

우리는 가지고있다.:

• TeamCity의 자동 시스템 조립;
• GitLab의 기능 브랜치에서 마스터 브랜치로 MergeRequest를 통해 코드를 업로드하는 프로세스가 구성되었습니다(GitHub Flow에 따른 개발 프로세스).
• 일정에 따라 DPO 시스템의 코드를 분석하도록 구성된 SonarQube.

우리의 목표: DPO의 CI/CD 프로세스에 자동 코드 분석을 구현합니다.

구성해야 함: 메인 브랜치에 대한 각 MergeRequest와 함께 정적 분석기를 사용하여 코드를 자동으로 확인하는 프로세스입니다.

저것들. 대상 그림은 다음과 같습니다. 개발자가 기능 분기에 변경 사항을 업로드하자마자 코드의 새로운 오류에 대한 자동 검사가 시작됩니다. 오류가 없으면 변경 사항이 승인되고, 그렇지 않으면 오류를 수정해야 합니다. 이미 초기 단계에서 우리는 코드에서 특정 수의 오류를 식별할 수 있었습니다. 시스템에는 매우 유연한 설정이 있습니다. 개발자의 특정 작업, 각 시스템 및 프로그래밍 스타일에 맞게 구성할 수 있습니다.

SonarQube에서 QualityGate 설정

QualityGate 분석은 우리가 인터넷 깊이에서 읽은 내용입니다. 처음에 우리는 더 복잡하고 어떤 면에서는 완전히 정확하지 않은 다른 접근 방식을 사용했습니다. 먼저 SonarQube를 통해 스캔을 두 번 실행했습니다. 기능 브랜치와 기능 브랜치를 병합할 브랜치를 스캔한 후 오류 수를 비교했습니다. 이 방법은 안정적이지 않았으며 항상 올바른 결과를 얻지 못했습니다. 그러다가 SonarQube를 두 번 실행하는 대신 오류 수에 제한을 설정하고(QualityGate) 업로드한 브랜치만 분석하여 비교할 수 있다는 것을 알게 되었습니다.

현재 우리는 여전히 다소 원시적인 코드 검토를 사용하고 있습니다. SonarQube는 Delphi를 포함한 일부 프로그래밍 언어와 호환되지 않습니다. 현재는 우리 시스템의 PLSql 코드만 분석합니다.

그것은 다음과 같이 작동합니다 :

• 우리는 프로젝트의 PL/SQL 코드만 분석합니다.
• SonarQube에는 커밋으로 인해 오류 수가 증가하지 않도록 QualityGate가 구성되어 있습니다.
• 첫 번째 실행 시 오류 수는 229였습니다. 커밋 중에 더 많은 오류가 있으면 병합이 허용되지 않습니다.
• 또한, 오류가 수정되면 QualityGate를 재구성하는 것이 가능해집니다.
• 테스트를 통한 코드 적용 등 분석을 위한 새로운 포인트를 추가할 수도 있습니다.

업무 계획 :

스크립트의 주석은 기능 분기의 오류 수가 증가하지 않았음을 보여줍니다. 그래서 모든 것이 괜찮습니다.

병합 버튼을 사용할 수 있게 됩니다.

스크립트의 주석에서 기능 분기의 오류 수가 허용 가능한 것보다 많아졌음을 알 수 있습니다. 그래서 모든 것이 나쁘다.

병합 버튼은 빨간색입니다. 현재 잘못된 코드로 인한 변경 사항 업로드를 금지하는 것은 아니지만 이는 담당 개발자의 재량에 따라 수행됩니다. 앞으로는 이러한 커밋이 기본 분기에 추가되는 것을 방지할 수 있습니다.

오류에 대한 독립적인 작업

다음으로, SonarQube는 엄격한 기준에 따라 분석하기 때문에 시스템에서 감지된 모든 오류를 확인해야 합니다. 그가 오류라고 생각하는 것은 실제로 우리 코드에서는 오류가 아닐 수도 있습니다. 따라서 이것이 실제로 오류인지, 아니면 당사의 조건에서 수정할 필요가 없는지 확인하고 메모해야 합니다. 이렇게 하면 오류 수를 줄일 수 있습니다. 시간이 지남에 따라 시스템은 이러한 뉘앙스를 이해하는 방법을 배웁니다.

우리는 무엇에 왔는가

우리의 목표는 우리의 경우 코드 검토를 자동화로 전환하는 것이 바람직한지 이해하는 것이었습니다. 그리고 그 결과는 기대에 부응했습니다. SonarQube를 사용하면 필요한 언어로 작업할 수 있고 상당히 유능한 분석을 수행하며 개발자 팁에서 배울 수 있는 잠재력이 있습니다. 전반적으로 우리는 SonarQube를 사용한 첫 경험에 만족하며 이 방향으로 더욱 발전할 계획입니다. 앞으로는 코드 검토에 더 많은 시간과 노력을 절약하고 인적 요소를 제거하여 더 나은 결과를 얻을 수 있을 것으로 기대합니다. 아마도 그 과정에서 우리는 플랫폼의 단점을 발견하게 될 것이고, 반대로 이것이 큰 잠재력을 지닌 멋진 일이라는 것을 다시 한번 확신하게 될 것입니다.

이 리뷰 기사에서 우리는 SonarQube 정적 분석기에 대해 이야기했습니다. 질문이 있으시면 댓글에 적어주세요. 이 주제에 관심이 있다면 새 출판물에서 모든 것을 올바르게 설정하고 이러한 검사를 수행하는 코드를 작성하는 방법에 대해 자세히 설명할 것입니다.

텍스트 작성자: 아타냐

출처 : habr.com