이 글은 Why did my coverage just drop?! 을 번역한 글입니다
업그레이드 이후, 실질적인 코드 변동이 없음에도 불구하고 분석 결과 Coverage 지표가 현저하게 떨어지는 현상 때문에 일부 사용자들이 놀랐습습니다. 믿지 않으실 수 있겠지만, 이는 버그가 아니라 기능의 추가로 인한 것입니다. 이 기능은 실행 가능한 라인(Executable Lines)라고 부릅니다.
Executable Lines는 새롭게 도입된 메트릭으로써, 하나의 파일에서 단위 테스트에 의해 실행되는 코드 라인의 수를 의미하며 coverage percentage 결과에 많은 영향을 줍니다 – 이 지표는 total coverage 계산 시의 분모로 활용되기 때문입니다. 이해를 돕기 위해 100라인의 코드를 각각 가진 두 개의 파일이 있다고 가정해보겠습니다. A 파일은 단위 테스트로 완전히 커버되었고, B 파일은 단위 테스트가 없는 상태입니다. Coverage 엔진은 (엔진에 따라 다를 수 있지만) 아마도 파일 A 만을 대상으로 coverage 정보를 수집해 coverage 100%로 계산을 할 것입니다. Executable Lines 메트릭을 도입하기 이전에는 coverage report에 의존해 coverage를 계산해야 했으므로, 실제 coverage는 50%임에도 불구하고 두 파일에 대해 coverage 100%로 결과를 표시했습니다. Executable Lines 메트릭을 사용함으로써, coverage report에 누락된 파일들의 정보를 모아 보다 실질적인 coverage 지표를 계산할 수 있게 되었습니다.
실질적인 coverage 지표는 coverage 값이 존재하지 않는 프로젝트의 경우에도 매우 중요합니다. 프로젝트 레벨에서 볼 때, Executable Lines 도입을 통해 coverage 정보가 '-'에서 '0%'로 표시됩니다. 해당 프로젝트의 품질 게이트는 이미 coverage 지표를 무시하도록 설정되어 있을 것이므로, 실질적인 차이는 없을 것입니다. 그러나 해당 프로젝트를 포트폴리오나 어플리케이션 레벨로 통합하게 되면, 단위 테스트가 전혀 존재하지 않는 프로젝트의 존재유무를 알 수 있게 됩니다.
이 시점에서 굳이 새로운 메트릭이 필요한지에 대한 궁금증을 가지실 수 있을 겁니다. 그냥 Lines of Code를 사용해도 충분하지 않은가?하고 말입니다. 그것은 코든 코드 라인이 실행 가능하지는 않기 때문입니다. 예를 들면 중요한 하나의 구문(a statement)이 Line of Code에 포함될 수는 있지만, 단위 테스트에 의해 커버해야 하는(혹은 커버할 수 있는) 필요는 없을 수 있기 때문입니다. 클래스 선언(class declarations), 인터페이스 선언(interface declarations), 변수 선언(variable declarations) 등도 이에 포함도리 수 있습니다. 실제로 우리는 developer guide를 통해 Lines of Code에는 해당하지만 Executable Lines에는 해당하지 않는 코드 종류에 대해 언급해 왔습니다.
물론, 이로 인한 사이드 이펙트도 존재합니다. 우선 SonarQube의 coverage percentage가 여러분이 사용하는 coverage report의 그것과 일치하지 않을 수 있습니다. 기존의 coverage report는 위에서 언급한 바와 같이 일부분적인 관점에서 생성되었기 때문입니다. 이와 함께, 기존 coverage report가 코드 베이스의 특정 부분을 무시하도록 설정해 둔 경우라 할지라도... SonarQube는 해당 부분을 무시하지 않게 되므로, 해당 부분을 무시하도록 exclusions 설정을 한차례 추가로 수행해 주셔야 합니다.
최신 SonarQube를 사용하는 경우, 아래 기술할 각 언어 분석기의 최신 버전은 Executable Lines 메트릭을 지원합니다. 혼란스러울 수 있는 부분은 이들이 분석기를 업그레이드 하는 것이 아니라, 플랫폼을 업그레이드 한다는 점입니다. 하지만 릴리스 되는 모든 플랫폼은 릴리스 당시 최신의 분석기를 포함하므로, 마이그레이션은 자동으로 이루어질 것입니다.
Executable Lines 메트릭을 지원하는 구체적인 분석기 엔진 버전은 아래와 같습니다:
- SonarC# 6.0
- SonarCFamily 4.9
- SonarJava 4.4
- SonarJS 2.20
- SonarPHP 2.9.2
- SonarPLSQL 3.0
- SonarPython 1.9
- SonarSwift 2.1
위에 기술되지 않은 다른 분석기 역시 "곧" Executable Lines 메트릭을 지원할 예정입니다.
이 글은 https://blog.sonarsource.com/changing-our-pricing-model-to-boost-adoption 을 번역한 글입니다
새로운 LTS 버전 및 에코시스템에서는 이전 LTS 버전에서 기대했던 새로운 기능들과 개선 사항들을 추가했습니다. 예를 들어, TypeScript 분석 지원, DataFlow 분석, Cognitive Complexity 및 Branch Analysis 등이 이에 속합니다. 대부분의 기능들이 오픈 소스 플랫폼에서 제공되며, 일부 기능은 유료 기능을 제공됩니다.
이번 변경을 준비하면서, 6.7 버전의 릴리즈와 함께 가격 정책을 변경하기 좋은 시기라고 판단했습니다. 이와 함께 지난 수년 동안 받은 피드백을 반영하였습니다:
- 소규모의 SonarQube 인스턴스를 관리하기에는 비용이 너무 높다
- 유료 서비스 제공 방법이 너무 파편화 되어 있다
- SonarQube 인스턴스의 규모와 관계없이 동일한 비용을 지불하는 것은 비합리적이다
- SonarQube 를 사용하고 있는 전세계 90,000 여개의 기업 중 극히 일부만이 그 비용을 감당할 수 있을 것이다
- SobarQube 및 SonarCloud 에디션의 가격을 공유하고 싶다
이러한 피드백을 반영해, 우리는 두 가지 중요한 결정을 내렸습니다:
- 유료 서비스를 Developer, Enterprise 및 Data Center 에디션의 3가지로 단순화했습니다. 플러그인들은 각 에디션에 포함되어 있으며, 별도로 판매되지 않습니다,
- 유료 서비스 비용은 코드 볼륨(LoC)에 비례하여 책정하였으며, 확신하건데 이 지표가 가격을 결정하기에 가장 최적의 지표라고 생각합니다(사용자, 라인, 이슈, 신규 이슈 수 등 많은 지표들을 사용할 수 있지만 말입니다...).
이번 가격 정책 변경을 통해 더 많은 기업들이 쉽게 SonarQube 및 SonarCloud 서비스를 사용할 수 있도록 하고자 합니다. 결과적으로 C++ 언어로 개발하는 소규모의 기업은 120유로(년간)로 SonarQube 서비스를 사용할 수 있습니다--역자 주: 지난 LTS 버전까지 C++ 별도 플러그인 가격은 7500유로(년간)였음. 지금까지 새로운 가격 정책에 만족한다는 피드백을 많이 받았습니다.
물론 지금과 같이 완전한 무료 버전의 서비스도 제공합니다. 공식 웹사이트의 가격 정책을 참조하시기 바랍니다 ^^