[스프링] 멀티모듈 jacoco , sonarqube (cloud) 세팅

 

두둥 프로젝트를 진행하면서 sonarcloud 를 활용해서 

pr 간의 테스트 코드 측정 , 머지후 dev브런치의 테스트 커버리지 측정등

ci 단에서 테스트 코드를 돌렸다.

 

아직 전체 테스트커버리지가 20퍼 대 이긴하지만, 중요한 도메인 로직들은

단위테스트는 거의 다 되어있는상태이다.

 

테스트 코드를 돌리면서 정말.. 많이 도움 되었다.

잘못 변경한 부분이나, 빌드 페일등을 방지하면서 안정성 있게 운영했었다.

 

다만 멀티모듈기준으로 초기 세팅하는데 잘 안된 부분들이 있어서

공유하려고한다.

---

목차

1. 전체적인 구성방식

2. jacoco 세팅하기

3. sonarqube 세팅하기

  3.1. 소나 클라우드 관련

  3.2. 그래들 관련

  3.3. 깃헙 액션

---

1. 전체적인 구성방식

 

 

테스트를 돌리면 jacocoTestReports 그래들 태스크를 실행시키면서

build.reports 에 테스트 커버리지 관련 내용들이 나오고,

xml을 sonarcloud 에 전송해서 테스트 커버리지를 측정한다.

또한 정적분석도 소나클라우드 측에서 진행해준다.

 

위 방식으로 흘러가고

- name: test and analyze
  env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
  run: ./gradlew test sonar --info --stacktrace

github ci단에서는 dev 브런치에 머지 리퀘스트가 날라올때 , dev에 푸시가 될때 두번 날려서

디폴트 브런치인 dev 브런치의 테스트 커버리지 측정과 피알 단위의 테스트 커버리지 측정 ,

두개를 측정하게 된다.

 

---

2. jacoco 세팅하기

 

테스트 커버리지 측정을 위해선 jacoco를 세팅해야한다.

제일 바깥 모듈의 gradle에서

subprojects {
	// 다른 부분은 생략
    apply plugin: 'jacoco'
    jacoco {
        toolVersion = '0.8.8'
    }
    jacocoTestReport {
        dependsOn test
        reports {
            html.enabled true // html 설정
            csv.enabled true // csv 설정
            xml.enabled true
            //xml 의 위치 조정
            xml.destination file("${buildDir}/reports/jacoco.xml")
        }
        def Qdomains = []
        for (qPattern in '**/QA'..'**/QZ') { // qPattern = '**/QA', '**/QB', ... '*.QZ'
            Qdomains.add(qPattern + '*')
        }
        afterEvaluate {
            classDirectories.setFrom(
                    files(classDirectories.files.collect {
                        fileTree(dir: it, excludes: [
                        		// 측정 안하고 싶은 패턴
                                "**/*Application*",
                                "**/*Config*",
                                "**/*Dto*",
                                "**/*Request*",
                                "**/*Response*",
                                "**/*Interceptor*",
                                "**/*Exception*"
                                // Querydsl 관련 제거
                        ] + Qdomains)
                    })
            )
        }
    }
    test {
        useJUnitPlatform()
        finalizedBy jacocoTestReport
    }
}

위처럼 jacoco 관련 세팅을 해준다.

빼고싶은 부분은 제거하고,

test 그래들 task를 실행시키면 jacocoTestReport 도 실행된다.

 

subproject 안에 작성된거여서 각 서브 모듈마다 적용이된다.

위와같은 설정을하게되면 test task 를 돌릴시에 테스크 커버리지 측정이된다.

 

---

3. sonarqube 설정하기

---

3.1. 소나 클라우드 관련

소나큐브를 직접 띄워도 되지만, 두둥 프로젝트에서는 sonarcloud를 사용했다.

간단하게 가입하고, 본인의 조직과 레포지토리를 선택한다.

 

그리고 항상 ci로 분석을 진행한다고 선택한다. 즉 자동 분석은 꺼준다.

또한 소나클라우드에서 설정할 값은 없다. 세팅은 다 그래들 쪽에서 해줄거다.

 

Quality Gate만.. 최소 테스트 커버리지 그런것만 팀원들이랑 상의해서 정하면된다.

우리는 ... 최대로 낮췄다 ㅎㅎ...

 

그다음 깃헙 액션 들어가서 두 값을 잘 체크해 둔다.

env 세팅

깃헙 액션의 환경변수를 위와 같이 설정하면 된다.

---

3.2. 그래들 관련

위 env 세팅에서 밑에 Gradle 버튼을 누르면 projectKey 랑 organization을 볼수있다.

복사해서 밑에 그래들을 공통 부분에 작성한다. ( 공통부분이라 함은 subproject 바깥을의미 )

// 공통으로 들어갈 부분
sonarqube {
    properties {
        property 'sonar.projectKey', 'Gosrock_DuDoong-Backend' // 본인 꺼 집어넣으세용
        property 'sonar.organization', 'dudung-gosrock' // 이것두
        property 'sonar.host.url', 'https://sonarcloud.io'
        property 'sonar.sources', 'src'
        property 'sonar.language', 'java'
        property 'sonar.sourceEncoding', 'UTF-8'
        property 'sonar.test.inclusions', '**/*Test.java'
        // 테스트 커버리지에서 빼고싶은거 넣어야함
        property 'sonar.exclusions', '**/test/**, **/Q*.java, **/*Doc*.java, **/resources/** ,**/*Application*.java , **/*Config*.java,' +
                '**/*Dto*.java, **/*Request*.java, **/*Response*.java ,**/*Exception*.java ,**/*ErrorCode*.java'
        property 'sonar.java.coveragePlugin', 'jacoco'
    }
}

subprojects {
    apply plugin: 'org.sonarqube'

    sonarqube {
        properties {
        	// 각 프로젝트마다 적용해야하는부분.
            property 'sonar.java.binaries', "${buildDir}/classes"
            property 'sonar.coverage.jacoco.xmlReportPaths', "${buildDir}/reports/jacoco.xml"
        }
    }
}

공통으로 들어갈 부분과 각 모듈마다 정해야할 부분을 잘 분리해서 작성하면된다.

특히 binaries 와 xmlReportPaths 는 무조건 따로 지정해야 잘된다.

---

3.3. 깃헙 액션

// 풀리퀘 날려올때마다 측정
name: ci
on:
  pull_request:
    branch: 'dev'

jobs:
  spotlessJavaCheck:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: SetUp JDK 17
        uses: actions/setup-java@v2
        with:
          java-version: "17"
          distribution: 'adopt'

      - name: Gradle Caching
        uses: actions/cache@v3
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      - name: Grant execute permission for gradlew
        run: chmod +x ./gradlew

      - name: spotless check
        run: ./gradlew spotlessCheck

      - name: test and analyze
        env:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        run: ./gradlew test sonar --info --stacktrace

// 데브 브런치 기준으로 측정
name: ci
on:
  push:
    branches:
      - dev

간단..하다!

딱히 설명이 필요없을것 같다.

 

위처럼 ci 파일을 두개 만들게되면, 데브브런치 기준, 피알 기준으로 테스트 커버리지 측정이 가능하다.

---

GitHub - Gosrock/DuDoong-Backend: 모두를 위한 새로운 공연 라이프, 두둥!

소스 링크 걸어두니 참고하시길 바란다.!

소스보시면 금방이해하실거다.

테스트 커버리지 측정이 부담스러우시면

ci 단이라도 빌드가 되는지 안되는지 테스트 돌려보시기라도 하면 좋다.

빌드 페일 방지목적으로도 .. 안정성 있게 운영하는데 도움이 되는것 같다.

두둥 프로젝트에서는 추가적으로 소스코드 스타일도 체킹하는데

spotless 관련 설정도 있으시 참고해보면 좋겠다.

 

- 데브브런치 ci

- 풀리퀘 ci

- gradle