지속적인 통합, GitHub Actions 및 Sonar Cloud에 대해 알아야 할 모든 것

저는 Mozilla 프로젝트가 시작되었을 때 CI(지속적 통합)라는 개념을 처음 접했습니다. 프로세스의 일부로 기본적인 빌드 서버가 포함되어 있었는데 이는 당시로서는 혁명적인 일이었습니다. 저는 빌드하고 연결하는 데 2시간이 걸리는 C++ 프로젝트를 유지 관리하고 있었습니다.

잘못된 코드가 프로젝트에 커밋되어 복합적인 문제를 일으키는 클린 빌드를 거의 거치지 않았습니다.

그 옛날과 비교하면 많은 것이 변했습니다. CI 제품은 어디에나 있으며 Java 개발자로서 우리는 이전과는 전혀 다른 풍부한 기능을 누리고 있습니다. 하지만 너무 앞서나가고 있어요… 기본부터 시작하겠습니다.

지속적인 통합은 코드 변경 사항이 자동으로 구축되고 빈번하고 일관된 방식으로 테스트되는 소프트웨어 개발 방식입니다.

CI의 목표는 가능한 한 빨리 통합 문제를 파악하고 해결하여 프로덕션에 버그 및 기타 문제가 발생할 위험을 줄이는 것입니다.

CI는 종종 코드 통합부터 프로덕션 배포까지 전체 소프트웨어 제공 프로세스를 자동화하는 것을 목표로 하는 CD(지속적 전달)와 함께 사용됩니다.

CD의 목표는 새 릴리스와 핫픽스를 배포하는 데 필요한 시간과 노력을 줄여 팀이 고객에게 더 빠르고 자주 가치를 제공할 수 있도록 하는 것입니다.

CD를 사용하면 CI 테스트를 통과한 모든 코드 변경 사항은 배포 준비가 완료된 것으로 간주되므로 팀은 언제든지 자신 있게 새 릴리스를 배포할 수 있습니다. 이 게시물에서는 지속적인 전달에 대해 논의하지 않겠지만, 논의할 내용이 많기 때문에 다시 언급하겠습니다.

저는 이 개념의 열렬한 팬이지만 모니터링해야 할 사항이 몇 가지 있습니다.

지속적인 통합 도구

강력한 지속적 통합 도구가 많이 있습니다. 다음은 일반적으로 사용되는 몇 가지 도구입니다.

• Jenkins : Jenkins는 가장 널리 사용되는 CI 도구 중 하나로, 다양한 프로그래밍 언어와 빌드 도구를 지원하는 광범위한 플러그인과 통합을 제공합니다. 오픈 소스이며 빌드 파이프라인을 설정하고 관리하기 위한 사용자 친화적인 인터페이스를 제공합니다.

  
  

  이는 Java로 작성되었으며 종종 제가 사용하는 "사용 도구"였습니다. 하지만 관리하고 설정하는 것이 번거롭습니다. 다소 부족한 사용자 경험을 정리하는 "Jenkins as a service" 솔루션도 있습니다.

• Travis CI : Travis CI는 GitHub와 잘 통합되는 클라우드 기반 CI 도구로 GitHub 기반 프로젝트에 탁월한 선택입니다. GitHub Actions보다 이전 버전이므로 GitHub의 많은 오픈 소스 프로젝트의 기본값이 되었습니다.

• CircleCI : CircleCI는 다양한 프로그래밍 언어와 빌드 도구를 지원하는 클라우드 기반 CI 도구입니다. 사용자 친화적인 인터페이스를 제공하지만 가장 큰 판매 포인트는 구축 및 전달 속도입니다.

• GitLab CI/CD : GitLab은 CI/CD 기능이 내장되어 있는 널리 사용되는 소스 코드 관리 도구입니다. GitLab 솔루션은 유연하면서도 간단합니다. GitLab 영역 외부에서도 업계의 관심을 얻었습니다.

• Bitbucket Pipelines : Bitbucket Pipelines는 소스 코드 관리 도구인 Bitbucket과 원활하게 통합되는 Atlassian의 클라우드 기반 CI 도구입니다. Atlassian 제품이므로 원활한 JIRA 통합과 매우 유연하고 기업 지향적인 기능을 제공합니다.

곧 다룰 GitHub Actions에 대해서는 언급하지 않았습니다. CI 도구를 비교할 때 고려해야 할 몇 가지 요소가 있습니다.

• 사용 용이성: 일부 CI 도구에는 간단한 설정 프로세스와 사용자 친화적인 인터페이스가 있어 개발자가 빌드 파이프라인을 더 쉽게 시작하고 관리할 수 있습니다.

• GitHub, GitLab, Bitbucket 등 소스 코드 관리(SCM) 도구와 통합됩니다. 이를 통해 팀은 빌드, 테스트 및 배포 프로세스를 더 쉽게 자동화할 수 있습니다.

• 다양한 프로그래밍 언어 및 빌드 도구 지원: 다양한 CI 도구는 다양한 프로그래밍 언어 및 빌드 도구를 지원하므로 개발 스택과 호환되는 도구를 선택하는 것이 중요합니다.

• 확장성: 일부 CI 도구는 복잡한 빌드 파이프라인을 가진 대규모 조직에 더 적합한 반면, 다른 CI 도구는 단순한 요구 사항을 가진 소규모 팀에 더 적합합니다.

• 비용: CI 도구는 무료 오픈 소스부터 고가의 상용 도구까지 가격이 다양하므로 예산에 맞는 도구를 선택하는 것이 중요합니다.

• 기능: 다양한 CI 도구는 실시간 빌드 및 테스트 결과, 병렬 빌드 지원, 내장 배포 기능과 같은 고유한 기능을 제공합니다.

일반적으로 Jenkins는 다재다능하고 광범위한 플러그인 라이브러리로 유명하므로 복잡한 빌드 파이프라인을 가진 팀에 널리 사용됩니다. Travis CI 및 CircleCI는 사용하기 쉽고 인기 있는 SCM 도구와의 통합으로 알려져 있어 중소 규모 팀에 적합한 선택입니다.

GitLab CI/CD는 통합 CI/CD 기능을 제공하므로 소스 코드 관리를 위해 GitLab을 사용하는 팀에게 인기 있는 선택입니다. Bitbucket Pipelines는 플랫폼과 원활하게 통합되므로 소스 코드 관리를 위해 Bitbucket을 사용하는 팀에게 좋은 선택입니다.

클라우드 대 온프레미스

에이전트 호스팅은 CI 솔루션을 선택할 때 고려해야 할 중요한 요소입니다. 에이전트 호스팅에는 클라우드 기반과 온프레미스라는 두 가지 주요 옵션이 있습니다.

• 클라우드 기반 : Travis CI, CircleCI, GitHub Actions 및 Bitbucket Pipelines와 같은 클라우드 기반 CI 솔루션은 클라우드의 자체 서버에서 에이전트를 호스팅합니다. 즉, 기본 인프라 관리에 대해 걱정할 필요가 없으며 클라우드의 확장성과 안정성을 활용할 수 있습니다.

• 온프레미스 : Jenkins와 같은 온프레미스 CI 솔루션을 사용하면 자체 서버에서 에이전트를 호스팅할 수 있습니다. 이를 통해 기본 인프라를 더 효과적으로 제어할 수 있지만 서버를 관리하고 유지하는 데 더 많은 노력이 필요합니다.

CI 솔루션을 선택할 때 팀의 특정 요구 사항과 요구 사항을 고려하는 것이 중요합니다.

예를 들어 크고 복잡한 빌드 파이프라인이 있는 경우 Jenkins와 같은 온프레미스 솔루션이 더 나은 선택일 수 있습니다. 기본 인프라를 더 잘 제어할 수 있기 때문입니다.

반면, 간단한 요구 사항을 가진 소규모 팀의 경우 설정 및 관리가 쉽기 때문에 Travis CI와 같은 클라우드 기반 솔루션이 더 나은 선택이 될 수 있습니다.

에이전트 상태 유지

상태 저장은 에이전트가 빌드 간에 데이터와 구성을 유지하는지 여부를 결정합니다.

• 상태 저장 에이전트 : Jenkins와 같은 일부 CI 솔루션은 상태 저장 에이전트를 허용합니다. 즉, 에이전트는 빌드 간에 데이터와 구성을 유지합니다. 이는 데이터베이스를 사용하거나 장기 실행 테스트를 실행하는 경우와 같이 빌드 간에 데이터를 유지해야 하는 상황에 유용합니다.

• 무상태 에이전트 : Travis CI와 같은 다른 CI 솔루션은 무상태 에이전트를 사용합니다. 즉, 각 빌드마다 에이전트가 처음부터 다시 생성됩니다. 이는 각 빌드에 대한 깔끔한 상태를 제공하지만 데이터베이스나 클라우드 스토리지와 같이 외부에서 지속형 데이터 및 구성을 관리해야 함을 의미하기도 합니다.

CI 지지자들 사이에서는 최선의 접근 방식에 관해 활발한 논쟁이 벌어지고 있습니다. 상태 비저장 에이전트는 깨끗하고 재현하기 쉬운 환경을 제공합니다. 나는 대부분의 경우에 이를 선택하고 이것이 더 나은 접근 방식이라고 생각합니다.

상태 비저장 에이전트는 설정 속도가 느리기 때문에 비용이 더 많이 들 수 있습니다. 클라우드 리소스에 대한 비용을 지불하므로 해당 비용이 합산될 수 있습니다. 그러나 일부 개발자가 상태 저장 에이전트를 선호하는 주된 이유는 조사 기능 때문입니다.

상태 비저장 에이전트를 사용하면 CI 프로세스가 실패할 때 일반적으로 로그 외에는 조사 수단이 남지 않습니다.

상태 저장 에이전트를 사용하면 머신에 로그인하여 해당 머신에서 수동으로 프로세스를 실행할 수 있습니다. 그 덕분에 실패한 문제를 재현하고 통찰력을 얻을 수도 있습니다.

제가 함께 일했던 회사에서는 Azure가 상태 저장 에이전트를 허용했기 때문에 GitHub Actions 대신 Azure를 선택했습니다. 이는 실패한 CI 프로세스를 디버깅할 때 중요했습니다.

나는 그 의견에 동의하지 않지만 그것은 개인적인 의견이다. 버그를 조사하여 얻은 이익보다 잘못된 에이전트 정리 문제를 해결하는 데 더 많은 시간을 소비한 것 같습니다. 그러나 그것은 개인적인 경험이고 내 똑똑한 친구들 중 일부는 이에 동의하지 않습니다.

반복 가능한 빌드

반복 가능한 빌드는 환경이나 빌드가 수행되는 시간에 관계없이 빌드가 수행될 때마다 정확히 동일한 소프트웨어 아티팩트를 생성하는 기능을 의미합니다.

DevOps 관점에서 소프트웨어 배포의 일관성과 안정성을 보장하려면 반복 가능한 빌드를 갖는 것이 필수적입니다.

간헐적인 오류는 어디에서나 DevOps의 골칫거리이며 추적하기가 어렵습니다.

안타깝게도 쉽게 해결할 수 있는 방법은 없습니다. 우리가 원하는 만큼 일부 허술함은 상당히 복잡한 프로젝트에 영향을 미칩니다. 이를 최대한 최소화하는 것이 우리의 임무입니다. 반복 가능한 빌드에는 두 가지 차단 장치가 있습니다.

• 종속성 - 종속성을 위해 특정 버전을 사용하지 않으면 작은 변경이라도 빌드가 중단될 수 있습니다.

• 불안정한 테스트 - 뚜렷한 이유 없이 가끔씩 실패하는 테스트는 최악입니다.

종속성을 정의할 때 특정 버전에 집중해야 합니다. 버전 관리 체계는 다양하지만 지난 10년 동안 표준 3자리 의미 체계 버전 관리가 업계를 장악했습니다.

이 체계는 CI에 매우 중요합니다. 예를 들어 maven을 사용하면 빌드의 반복성에 큰 영향을 미칠 수 있기 때문입니다.

 <dependency> <groupId>group</groupId> <artifactId>artifact</artifactId> <version>2.3.1</version> </dependency>

이는 매우 구체적이며 반복성에 적합합니다. 그러나 이는 빨리 구식이 될 수 있습니다. 버전 번호를 LATEST 또는 RELEASE 로 바꾸면 자동으로 현재 버전을 얻을 수 있습니다. 빌드가 더 이상 반복 가능하지 않기 때문에 이는 좋지 않습니다.

그러나 하드코딩된 3자리 접근방식 역시 문제가 있다. 패치 버전이 버그에 대한 보안 수정을 나타내는 경우가 많습니다. 이 경우 최신 버전이 아닌 최신 마이너 업데이트로 업데이트하고 싶을 것입니다.

예를 들어 이전 사례에서는 2.4.1 이 아닌 2.3.2 버전을 암시적으로 사용하고 싶습니다. 이는 사소한 보안 업데이트 및 버그에 대한 일부 반복성을 상쇄합니다.

그러나 더 좋은 방법은 Maven Versions Plugin을 사용하고 mvn versions:use-latest-releases 명령을 주기적으로 호출하는 것입니다. 이렇게 하면 버전이 최신으로 업데이트되어 프로젝트를 최신 상태로 유지합니다.

이는 반복 가능한 빌드의 간단한 부분입니다. 어려움은 색다른 테스트에 있습니다. 이는 일부 프로젝트에서 실패한 테스트의 "합리적인 양"을 정의하고 일부 프로젝트에서는 실패를 인정하기 전에 빌드를 여러 번 다시 실행하는 일반적인 고통입니다.

테스트 결함의 주요 원인은 상태 누출입니다. 이전 테스트에서 남은 미묘한 부작용으로 인해 테스트가 실패할 수 있습니다. 이상적으로는 테스트가 자체적으로 정리되어 각 테스트가 독립적으로 실행되도록 해야 합니다.

완벽한 세상에서는 완전히 격리된 새로운 환경에서 모든 테스트를 실행하지만 이는 실용적이지 않습니다. 이는 테스트를 실행하는 데 너무 오랜 시간이 걸리고 CI 프로세스를 위해 많은 시간을 기다려야 함을 의미합니다.

다양한 격리 수준으로 테스트를 작성할 수 있습니다. 때로는 완전한 격리가 필요하고 테스트를 위해 컨테이너를 가동해야 할 수도 있습니다. 그러나 대부분의 경우 그렇지 않으며 속도의 차이가 상당합니다.

테스트 후 청소는 매우 어렵습니다. 때로는 데이터베이스와 같은 외부 도구의 상태 누출로 인해 불안정한 테스트 실패가 발생할 수 있습니다. 실패의 반복성을 보장하기 위해 테스트 사례를 일관되게 정렬하는 것이 일반적인 관행입니다. 이렇게 하면 향후 빌드 실행이 동일한 순서로 실행됩니다.

이것은 뜨거운 논쟁의 여지가 있는 주제입니다. 일부 엔지니어들은 이것이 버그가 있는 테스트를 조장하고 무작위 순서의 테스트를 통해서만 발견할 수 있는 문제를 숨긴다고 믿습니다. 내 경험에 따르면 실제로 테스트에서는 버그가 발견되었지만 코드에서는 발견되지 않았습니다.

내 목표는 완벽한 테스트를 구축하는 것이 아니기 때문에 알파벳 순서와 같이 일관된 순서로 테스트를 실행하는 것을 선호합니다.

테스트 실패 통계를 유지하는 것이 중요하며 단순히 재시도를 누르지 마십시오. 문제가 있는 테스트와 실패에 대한 실행 순서를 추적함으로써 문제의 원인을 찾을 수 있는 경우가 많습니다.

대부분의 경우 실패의 근본 원인은 이전 테스트의 잘못된 정리로 인해 발생하므로 순서가 중요하고 일관성도 중요합니다.

개발자 경험 및 CI 성능

우리는 CI 도구가 아닌 소프트웨어 제품을 개발하기 위해 왔습니다. CI 도구는 프로세스를 개선하기 위해 여기에 있습니다. 불행하게도 CI 도구 사용 경험이 너무 실망스러워 실제로 코드를 작성하는 것보다 실행 계획에 더 많은 시간을 소비하게 되는 경우가 많습니다.

종종 변경 사항을 병합하기 위해 CI 검사를 통과하는 데 며칠이 걸렸습니다. 가까이 다가갈 때마다 다른 개발자가 변경 사항을 먼저 병합하고 내 빌드를 중단했습니다.

이는 특히 팀이 확장되고 변경 사항을 병합하는 것보다 CI 대기열에서 더 많은 시간을 소비함에 따라 뛰어난 개발자 경험에 기여합니다. 이러한 문제를 완화하기 위해 우리가 할 수 있는 일이 많이 있습니다.

• 테스트 중복 감소 - 과잉 테스트는 적용 범위 도구를 통해 감지할 수 있는 일반적인 증상입니다.

• 불안정한 테스트 제거 - 테스트를 삭제하거나 비활성화하는 것이 문제가 된다는 것을 알고 있습니다. 가볍게 하지 마세요. 그러나 코드를 디버깅하는 것보다 테스트를 디버깅하는 데 더 많은 시간을 소비한다면 그 가치는 논쟁의 여지가 있습니다.

• CI 프로세스를 위해 추가 또는 더 빠른 시스템을 할당합니다.

• CI 프로세스를 병렬화합니다. 일부 빌드 유형과 일부 테스트를 병렬화할 수 있습니다.

• 프로젝트를 더 작은 프로젝트로 분할합니다. 이것이 반드시 마이크로서비스를 의미하는 것은 아닙니다 .

궁극적으로 이는 개발자의 생산성과 직접적으로 연결됩니다. 그러나 이러한 종류의 최적화를 위한 프로파일러는 없습니다. 우리는 매번 측정해야 합니다. 이것은 힘들 수 있습니다.

GitHub 작업

GitHub Actions는 GitHub에 내장된 CI/CD(지속적 통합/지속적 전달) 플랫폼입니다. 에이전트의 자체 호스팅을 어느 정도 허용하지만 상태 비저장입니다. 오픈 소스 프로젝트에서는 무료이고 비공개 소스 프로젝트에서는 상당한 무료 할당량이 있기 때문에 이에 집중하고 있습니다.

이 제품은 해당 분야에서 상대적으로 새로운 경쟁자이며 앞서 언급한 대부분의 다른 CI 도구만큼 유연하지 않습니다. 그러나 GitHub 및 상태 비저장 에이전트와의 긴밀한 통합 덕분에 개발자에게는 매우 편리합니다.

GitHub Actions를 테스트하려면 새 프로젝트가 필요합니다. 이 경우 여기에 표시된 구성으로 JHipster를 사용하여 생성했습니다.

여기서는 GitHub Actions 사용을 보여주는 별도의 프로젝트를 만들었습니다. 어떤 프로젝트에서든 이를 따를 수 있습니다. 이 경우에는 Maven 명령어를 포함하지만 개념은 매우 간단합니다.

프로젝트가 생성되면 GitHub에서 프로젝트 페이지를 열고 작업 탭으로 이동할 수 있습니다.

우리는 다음과 같은 것을 보게 될 것입니다:

오른쪽 하단에서 Maven 프로젝트 유형이 포함된 Java를 볼 수 있습니다. 이 유형을 선택하면 다음과 같이 maven.yml 파일 생성으로 이동합니다.

불행하게도 GitHub에서 제안한 기본 maven.yml에는 문제가 있습니다. 이 이미지에서 볼 수 있는 코드는 다음과 같습니다.

 name: Java CI with Maven on: push: branches: [ "master" ] pull_request: branches: [ "master" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up JDK 11 uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' cache: maven - name: Build with Maven run: mvn -B package --file pom.xml # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive - name: Update dependency graph uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6

마지막 세 줄은 종속성 그래프를 업데이트합니다. 하지만 이 기능은 실패했거나 적어도 나에게는 실패했습니다. 이를 제거하면 문제가 해결되었습니다. 나머지 코드는 표준 YAML 구성입니다.

코드 상단 근처의 pull_request 및 push 줄은 풀 요청과 마스터에 대한 푸시 모두에서 빌드가 실행된다는 것을 선언합니다. 이는 커밋하기 전에 풀 요청에 대한 테스트를 실행할 수 있음을 의미합니다. 테스트가 실패하면 커밋하지 않습니다.

프로젝트 설정에서 실패한 테스트로 커밋하는 것을 허용하지 않을 수 있습니다. YAML 파일을 커밋하고 나면 끌어오기 요청을 생성할 수 있으며 시스템이 빌드 프로세스를 실행합니다. Maven의 "패키지" 대상은 기본적으로 테스트를 실행하므로 여기에는 테스트 실행이 포함됩니다.

테스트를 호출하는 코드는 끝 부분에 "run"으로 시작하는 줄에 있습니다. 이는 사실상 표준 Unix 명령줄입니다. 때로는 셸 스크립트를 만들어 CI 프로세스에서 실행하는 것이 합리적일 때도 있습니다.

모든 YAML 파일과 다양한 CI 스택의 구성 설정을 처리하는 것보다 좋은 셸 스크립트를 작성하는 것이 더 쉬운 경우도 있습니다.

나중에 CI 도구를 전환하기로 선택하면 이식성이 더 높아집니다. 여기서는 maven이 현재 요구 사항에 충분하므로 필요하지 않습니다.

여기에서 성공적인 풀 요청을 볼 수 있습니다.

이를 테스트하기 위해 “/api” 엔드포인트를 “/myapi” 로 변경하여 코드에 버그를 추가할 수 있습니다. 이로 인해 아래와 같은 오류가 발생합니다. 또한 커밋 작성자에게 오류 이메일이 전송됩니다.

이러한 오류가 발생하면 오른쪽에 있는 "세부 정보" 링크를 클릭할 수 있습니다. 여기에 표시되는 오류 메시지로 바로 연결됩니다.

안타깝게도 이는 일반적으로 문제 해결에 도움을 주지 않는 쓸모없는 메시지입니다. 그러나 위로 스크롤하면 다음과 같이 일반적으로 편리하게 강조 표시되는 실제 오류가 표시됩니다.

실패가 여러 번 발생하는 경우가 많으므로 더 위로 스크롤하는 것이 좋습니다. 이 오류에서는 여기에서 볼 수 있는 AccountResourceIT의 394 행에 있는 어설션이 실패했음을 알 수 있습니다. 행 번호가 일치하지 않는다는 점에 유의하세요. 이 경우 394 행은 메소드의 마지막 행입니다.

 @Test @Transactional void testActivateAccount() throws Exception { final String activationKey = "some activation key"; User user = new User(); user.setLogin("activate-account"); user.setEmail("[email protected]"); user.setPassword(RandomStringUtils.randomAlphanumeric(60)); user.setActivated(false); user.setActivationKey(activationKey); userRepository.saveAndFlush(user); restAccountMockMvc.perform(get("/api/activate?key={activationKey}", activationKey)).andExpect(status().isOk()); user = userRepository.findOneByLogin(user.getLogin()).orElse(null); assertThat(user.isActivated()).isTrue(); }

이는 Assert 호출이 실패했음을 의미합니다. isActivated() false 반환하고 테스트에 실패했습니다. 이는 개발자가 문제의 범위를 좁히고 근본 원인을 이해하는 데 도움이 됩니다.

너머로

앞서 언급했듯이 CI는 개발자 생산성에 관한 것입니다. 우리는 단순히 컴파일하고 테스트하는 것보다 훨씬 더 많은 것을 할 수 있습니다. 우리는 코딩 표준을 시행하고, 코드를 린트하고, 보안 취약점을 탐지하는 등 다양한 작업을 수행할 수 있습니다.

이번 예시에서는 강력한 코드 분석 도구(linter)인 Sonar Cloud를 통합해 보겠습니다. 프로젝트에서 잠재적인 버그를 찾아 코드 품질을 향상시키는 데 도움이 됩니다.

SonarCloud는 개발자가 코드를 지속적으로 검사하고 분석하여 코드 품질, 보안 및 유지 관리 가능성과 관련된 문제를 찾아 수정할 수 있는 클라우드 기반 버전의 SonarQube입니다. Java, C#, JavaScript, Python 등과 같은 다양한 프로그래밍 언어를 지원합니다.

SonarCloud는 GitHub, GitLab, Bitbucket, Azure DevOps 등과 같은 널리 사용되는 개발 도구와 통합됩니다. 개발자는 SonarCloud를 사용하여 코드 품질에 대한 실시간 피드백을 받고 전반적인 코드 품질을 향상시킬 수 있습니다.

반면 SonarQube는 소프트웨어 개발자를 위한 정적 코드 분석 도구를 제공하는 오픈 소스 플랫폼입니다. 코드 품질 요약을 표시하고 개발자가 코드 품질, 보안 및 유지 관리 가능성과 관련된 문제를 식별하고 수정하는 데 도움이 되는 대시보드를 제공합니다.

SonarCloud와 SonarQube는 모두 유사한 기능을 제공하지만 SonarCloud는 클라우드 기반 서비스이므로 구독이 필요한 반면, SonarQube는 온프레미스 또는 클라우드 서버에 설치할 수 있는 오픈 소스 플랫폼입니다.

단순화를 위해 SonarCloud를 사용하겠지만 SonarQube는 잘 작동할 것입니다. 시작하려면 sonarcloud.io 로 이동하여 가입하세요. 이상적으로는 GitHub 계정을 사용하세요. 그러면 다음과 같이 Sonar Cloud를 통해 모니터링할 저장소를 추가할 수 있는 옵션이 제공됩니다.

새 페이지 분석 옵션을 선택하면 GitHub 저장소에 대한 액세스 권한을 부여해야 합니다. 다음 단계는 여기에 표시된 대로 Sonar Cloud에 추가하려는 프로젝트를 선택하는 것입니다.

선택하고 설정 과정을 진행한 후에는 분석 방법을 선택해야 합니다. GitHub Actions를 사용하므로 여기에 표시된 대로 다음 단계에서 해당 옵션을 선택해야 합니다.

이것이 설정되면 다음 이미지와 같이 Sonar Cloud 마법사 내의 최종 단계로 들어갑니다. 우리는 복사할 수 있는 토큰을 받고(항목 2는 이미지에서 흐리게 표시됨) 곧 이를 사용하게 됩니다.

"Maven"이라고 표시된 버튼을 클릭하면 나타나는 Maven과 함께 사용하기 위한 기본 지침도 있습니다.

GitHub의 프로젝트로 돌아가서 프로젝트 설정 탭으로 이동할 수 있습니다(상위 메뉴의 계정 설정과 혼동하지 마세요). 여기에서는 다음과 같이 "비밀 및 변수"를 선택합니다.

이 섹션에서는 여기에서 볼 수 있듯이 새로운 저장소 비밀, 특히 SonarCloud에서 복사한 SONAR_TOKEN 키와 값을 추가할 수 있습니다.

GitHub Repository Secrets는 개발자가 API 키, 토큰, 비밀번호 등 GitHub 저장소와 관련된 민감한 정보를 안전하게 저장할 수 있게 해주는 기능입니다. 이러한 정보는 저장소에서 사용되는 다양한 타사 서비스 또는 플랫폼에 대한 액세스를 인증하고 승인하는 데 필요합니다. .

GitHub Repository Secrets의 기본 개념은 코드나 구성 파일에 정보를 공개적으로 노출하지 않고도 기밀 정보를 관리하고 공유할 수 있는 안전하고 편리한 방법을 제공하는 것입니다.

개발자는 비밀을 사용하여 중요한 정보를 코드베이스와 별도로 유지하고 보안 침해 또는 무단 액세스가 발생할 경우 해당 정보가 노출되거나 손상되지 않도록 보호할 수 있습니다.

GitHub 저장소 비밀은 안전하게 저장되며 저장소에 대한 액세스 권한이 부여된 승인된 사용자만 액세스할 수 있습니다. 비밀은 리포지토리와 연결된 워크플로, 작업 및 기타 스크립트에서 사용할 수 있습니다.

안전하고 안정적인 방식으로 비밀에 액세스하고 사용할 수 있도록 코드에 환경 변수로 전달될 수 있습니다.

전반적으로 GitHub Repository Secrets는 개발자가 저장소와 관련된 기밀 정보를 관리하고 보호할 수 있는 간단하고 효과적인 방법을 제공하여 프로젝트와 프로젝트에서 처리하는 데이터의 보안과 무결성을 보장하는 데 도움을 줍니다.

이제 이를 프로젝트에 통합해야 합니다. 먼저 이 두 줄을 pom.xml 파일에 추가해야 합니다. 자신의 이름과 일치하도록 조직 이름을 업데이트해야 합니다. 이는 XML의 섹션으로 들어가야 합니다.

 <sonar.organization>shai-almog</sonar.organization> <sonar.host.url>https://sonarcloud.io</sonar.host.url>

우리가 만든 JHipster 프로젝트에는 이미 SonarQube 지원이 있으므로 이 코드가 작동하려면 pom 파일에서 제거해야 합니다 .

그런 다음 maven.yml 파일의 "Build with Maven" 부분을 다음 버전으로 바꿀 수 있습니다.

 - name: Build with Maven env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=shai-almog_HelloJHipster package

그렇게 하면 SonarCloud는 다음과 같이 시스템에 병합된 모든 풀 요청에 대한 보고서를 제공합니다.

버그, 취약점, 냄새, 보안 문제 목록이 포함된 보고서를 볼 수 있습니다. 이러한 문제를 모두 클릭하면 다음과 같은 내용이 표시됩니다.

문제가 문제가 되는 이유, 해결 방법 등을 정확하게 설명하는 탭이 있습니다. 이는 팀에서 가장 가치 있는 코드 검토자 중 하나의 역할을 하는 매우 강력한 도구입니다.

이전에 본 두 가지 추가 흥미로운 요소는 적용 범위 및 중복 보고서입니다. SonarCloud는 테스트의 코드 적용 범위가 80%일 것으로 예상합니다(풀 요청에서 코드의 80% 트리거). 이는 높은 수치이며 설정에서 구성할 수 있습니다.

또한 DRY(Don't Repeat Yourself) 원칙을 위반했음을 나타낼 수 있는 중복 코드를 지적합니다.

마지막으로

CI는 프로젝트 흐름을 개선할 수 있는 많은 기회가 있는 거대한 주제입니다. 버그 탐지를 자동화할 수 있습니다. 아티팩트 생성, 자동화된 전달 등을 간소화합니다. 하지만 제 생각에는 CI의 핵심 원칙은 개발자 경험입니다.

우리의 삶을 더 쉽게 만들기 위해 여기에 있습니다.

잘못 수행되면 CI 프로세스는 이 놀라운 도구를 악몽으로 만들 수 있습니다. 시험을 통과하는 것은 헛된 일이 됩니다. 최종적으로 병합할 수 있을 때까지 계속해서 다시 시도합니다. 느리고 혼잡한 대기열 때문에 병합하는 데 몇 시간이 걸립니다.

도움이 될 것으로 예상되었던 이 도구는 우리의 적이 되었습니다. 이런 일은 있어서는 안 됩니다. CI는 우리의 삶을 더 쉽게 만들어주어야 합니다. 그 반대가 아닙니다.