64 Embedded World www.embeddedworld.co.kr 65

UEST ARTICLEG

적용예시: Jenkins와 PRQA 도구

Part 1 : CI System인 Jenkins

최근 조사에 따르면 무료 또는 상용화된 CI 도

구 중 Jenkins는 가장 유명한 도구로 알려지고

있다. Jenkins는 Hudson CI 시스템이 전신이며,

Jenkins를 통해 가장 Active한 시스템을 갖출 수

있었다.

Jenkins는 MIT 라이선스에 따라 무료로 사용가

능하며, 다른 오픈 소스와 마찬가지로 기술지원

을 받을 수 있는 유료버전도 있다. 물론 Jenkins

는 오픈 소스 프로젝트이지만 핵심 코드에 대해

서는 핵심 인원만 관리를 하고 있으며 프로그램

설계자인 코슈케카와구치가 그 중 한 인물이다.

시스템 개요

Jenkins는 Java 언어로 작성되었으며, 작은 코

어와 Built-in 웹 서버로 구성되어 있다. Jenkins

를 사용하는 대부분의 사용자는 웹 브라우저에

서 사용이 가능하며 클라이언트 PC에 설치해야

할 SW는 없다.

좋은 CI 시스템의 중요한 특성 중 하나는 어떤 기

업이든지 비즈니스 요구사항을 충족할 수 있도록

유연하게 변경 가능하다는 점이다. Jenkins는 커스

터마이징이 가능하고 확장성을 가질 수 있는 중요

한 2가지 아키텍처 특성을 가지고 있는데 Master/

Slave 두 개로 나눠지는 Build 아키텍처와 Plugin

이다.

Master / Slave 아키텍처

Jenkins는 물론 보통은 Master와 Slave로 설정되

지만 PC 한대에서 운용이 가능하다. 코드가 Build

혹은 테스트가 된 후에 Master는 그것을 관리하

고 사용자와 인터페이스를 제공한다. Jenkins에

서 각 작업은 ‘Job’이라고 부른다. 하나 또는 그

이상의 Slave는 실제 Build와 테스트를 수행한다.

Build 과정(최종 바이너리 코드, 패키지, 테스트

결과 등등)에서 중요한 결과는 Slave에서 Master

로 옮겨져 저장된다. 오브젝트 파일과 같은 중간

파일은 Slave에 남겨진다. (그리고 주기적으로 삭

제된다.) Master는 모든 Build의 결과를 기록하고

추적성을 확보한다.

Slave 머신은 특별한 것이 아니다. 개발과 테스

트 도구가 설치되어 있는 상용화된 보통의 PC다.

Slave 머신은 Master와는 다른 운영체제에서 실

행할 수 있다. 여러 개 플랫폼에서 작성된 코드일

경우 중요하다. 또한 Slave는 하드웨어에 직접 연

결할 수 있어 임베디드 코드와 같은 경우 실제 장

비에서 다운로드 받고 테스트 할 수 있다. Slave

는 반드시 물리적 장치가 있어야 하는 것은 아니

다. 가상 머신이 점차 활용되며 클라우드 기반 솔

루션은 점차 효과적인 옵션으로 되어가고 있다.

플러그인

Jenkins에서 실행되는 대부분의 작업들은 플러

그인에서 실행된다. Jenkins 코어는 플러그인 설

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 2

지난 호에서는 SW 공학에 있어 지속적인 통합(Continuous Integration)의 개념과 원리에 대해 알아보았다. SW 개발 주기

를 어떻게 간소화하고 정적 분석이 어떻게 적용되는지에 대해 설명하였다면 이번 호에서는 특정 도구를 통해 실제로 어떻

게 적용되는지 알아보겠다. Jenkins CI와 PRQA의 정적 분석 도구들(QA•C, QA•C++ and QA•Verify)을 이용하여 이 도

구들이 어떻게 통합이 되고 어떤 정보를 생성하는지 알아볼 예정이다.

원저 : Programming Research Ltd. / Jason Masters, R&D Director

번역 : 김관식 / MDS테크놀로지

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)–Vol. 2

그림 4. Jekins 대쉬보드 오른쪽은 모든 작업의 목록을 보여준다.

왼쪽 아래는 Slave Machine의 목록을 보여주며, 이는 빌드 상태이다.

www.embeddedworld.co.kr 67

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 2

66 Embedded World

UEST ARTICLEG

치 후 GUI에서 설정하고 사용자가 원하는 시점에

서 설치한 플러그인이 실행할 수 있게 API 정리

가 잘 되어 있다.

800개가 넘는 플러그인이 존재하며 버전관리시

스템, 코드 Build, 테스트, 리포트 그리고 관리를

할 수 있게 해준다. 관련 있는 플러그 인을 설치

함으로써 Jenkins는 프로젝트 Build와 테스트 요

구사항에 맞게 바뀔 수 있는 것이다.

대쉬보드

Jenkins는 모든 작업(job)의 경과를 보여주는 대

쉬보드가 있다. 각 작업(job)의 상태는 점 형태로

보여주며 점의 색깔이 마지막 실행의 상태를 나

타낸다. (기본설정은 빨간색은 실패, 노란색은 불

안정, 푸른색은 성공을 의미한다. Jenkins의 가장

큰 특징으로 이것 또한 변경 가능하다.)

깜박이는 점은 현재 작업(job)이 Build 되고 있는

것을 나타낸다. 태양이나 폭풍우를 나타내는 날

씨 심볼은 최근 Build 과정의 결과를 시각적으로

보여주는 것이다.

Dashboard는 Build를 기다리는 작업 목록의 대

기상태를 보여준다. 또한 어떤 작업이 대기상태

인지 어떤 작업을 실행중인지를 알 수 있는 Slave

의 상태도 보여준다. 그림 4는 Jenkins의대쉬보

드를 나타낸다.

작업(Jobs)

작업은 3개의 단계로 나눌 수 있다.

1. 선Build 단계 : 저장소에서 가장 최신의 코드를

Check-out하며, 보통 정해진 시간 또는 다른

일이 끝난 후 저장소에 Check-in된 코드가 있

는지 확인하는 것으로 시작한다.

2. Build 단계 :이 단계는 컴파일, 링크부터 테스트

실행까지 대부분의 작업이 실행되는 단계이다.

Jenkins는 디버깅을 쉽게 하기 위해 모든 콘솔

명령어를 출력하며 추적한다.

3. 후Build 단계 : 이 단계는 Build된 코드를 테스

트 하는 이후의 단계를 포함하고 있다. 결과를

수집하고대쉬보드에 출력하기 위해 분석하며

필요한 정보들은 Master로 보낸다.

Build와 후 Build 단계는 Build와 테스트의 요구사

항과 어떤 플러그인이 설치됐느냐에 따라 0개 또

는 그 보다 많은 실행과정을 가지고 있다.

간단한 작업은 아래와 같은 설정으로 구성될 수

있다.

1. 선 Build : 버전관리시스템 어플리케이션, 저장

소의 경로 그리고 모듈 이름

2. Build: make 명령어를 포함하여 실행명령어

순서

3. 후 Build: Build 단계에서 실행한 내용들을 수

집 및 분석

작업이 수행되면 Jenkins는 저장소에서 가장 최

신 코드를 Check-out해오며, make 명령 실행 후

실행 결과물을 master에 복사한다. 만약 실행과

정 중 실패하면 그 이후의 과정은 작동되지 않고

그 작업은 실패상태로 설정된다.

모든 과정이 error없이 완료되어야 성공상태로 설

정된다. 위에서 설명한 간단한 단계에서 Jenkins

의 실행은 밤(night)에 Build하게 설정하여 사용

할 수 있다.

시작하기

Jenkins를 시작하는 것은 매우 간단하다. 웹 어플

리케이션으로 바로 실행 가능한 압축파일을 설치

하면 된다. 압축파일은 간단하게 다운받고 실행

하면 된다. 설치과정이 끝나면 사용자권한을 얻

으며 서비스 / 데몬에 설정된다.

Part 2: PRQA Jenkins 플러그인을 이용한

정적 분석

PRQA는 정적 분석 도구인 제품인 QAC/QAC++

으로 코드를 분석할 수 있게 Jenkins 플러그인을

개발했다. 이 플러그인은 후 Build단계에서 자동

적으로 실행된다.

1. 프로젝트 분석

2. 코딩규칙 만족 결과 리포트 생성

3. 분석한 프로젝트의 코딩 규칙 위반사항 개수와

설정된 위반사항 개수를 비교하여 그 값이 설

정된 값보다 넘어서면 Build 상태를 불안정 상

태로 설정한다. 이것은 뒤따라 오는 과정들을

멈추는 데 사용할 수 있다.

4. 추가적으로 웹 기반 소프트웨어 품질 관리 시

스템인 QA•Verify에 분석 결과를 업로드 할

수 있다.

분석은 Dependency 모드로 실행할 수 있다. 이

는 지난 분석과 비교하여 변경된 코드에 대해서

만 분석하여 분석시간을 가능한 줄이는 방법이

다. 또한 Build 단계에서 분석이 가능하며 (예를

들어 Makefile Integration을 사용한다면) 플러그

인은 어떤 파일이 분석이 되었는지에 대한 정보

를 받는다. 웹 페이지에서의 플러그인 결과 정보

는 그림 5와 같다.

코딩 규칙 만족 그래프와 Build당 위반사항 그래

프를 그려준다. 이 그래프를 통해 코딩 규칙 위

반사항의 개수의 변화를 쉽게 확인할 수 있다.

Compliance Summary 테이블은 프로젝트와 파

그림 5.

www.embeddedworld.co.kr 69

코드 품질을 높이기 위한 정적 분석과 지속적인 통합(CI)- Vol. 2

68 Embedded World

UEST ARTICLEG

일 별 코딩 규칙 만족 정도와 전체 위반사항의

개수를 나타낸다. (코딩규칙을 지키지 않은 정도

와 다른 자세한 정보는 QAC / QAC++에서 제공

하는 리포트 프로그램으로부터 얻은 결과이다.)

두 번째 테이블은 코딩규칙 레벨 별 위반사항의

개수를 나타낸다. 플러그 인은 프로젝트의 코딩

규칙 만족 정도를 나타내는 모든 리포트들을 자

동으로 정리한다.

코딩 규칙 위반사항 개수의 경계 값은 절대값으

로 설정되어야 한다. 예로 0은 위반사항이 하나도

없어야 한다는 의미이다. 게다가 위반사항 레벨

별로 경계 값을 설정할 수 있어, 코딩규칙 위험정

도에 따라 설정될 수 있다는 의미이다. 유지보수

나 스타일 가이드와 같은 코딩 규칙에 대한 위반

사항은 통과지만, 버그와 같은 오류를 가지는 코

드는 실패 상태로 남길 수 있는 것이다.

강력한 기능 중 하나는 QAC 분석 결과를 QA·Verify

에 업로드 할 수 있다는 것이다. 개발자들이 위반사

항의 내용이 포함된 분석 결과를 면밀히 검토할 수

있으며, 정확하게 코딩 규칙 위반사항 위치를 확인

할 수 있다. 검출된 위반사항에 대해 제거(devia-

tion)할 수 있으며 MISRA C와 같은 코딩 규칙을

만족한 것을 증명할 리포트관리를 할 수 있다.

QA·Verify는 프로젝트의 품질을 관련자(관리자

또는 고객)들에게 정보를 제공할 수 있다.

개발자들은 보통 때처럼 코드를 Commit할 수 있

다. (단계 저장소에서 모든 테스트를 만족하여 실

제저장소로 옮기는 일련의 작업으로) 일이 QAC

/ QAC++이 코드를 분석할 수 있게 CI서버에 설

정이 되어 있어야 한다. CI서버에서 코드가 얼마

나 코딩 규칙을 만족했는지에 대한 정보를 확인

할 수 있으며, 또한 분석 결과에 대해 자동으로

QA·Verify에 업로드한다. 개발자는 코딩 규칙을

위반한 코드의 정확한 위치를 웹 브라우저에서

확인할 수 있으며, 다시 Commit 하기 전에 코드

를 수정할 수 있다.

다른 관련자들도 QA·Verify에서 위반사항 내용

이 추가된 코드를 확인할 수 있고 코드를 보는 낮

은 레벨이 아닌 그 보다 높은 레벨의 정보를 원

하는 매니저나 QA 팀에게는 추가적인 정보를 제

공한다.

관리자는 코드를 보고 싶어하지 않고 코드에 결

함이 얼마나 있는지 그리고 줄어들고 있는지 늘

어나고 있는지를 알고 싶어 한다. 프로젝트 단

위의 정보를 보여주는 것으로 프로젝트에 자원

에 대한 재할당과 같은 결정을 내릴 수 있게 도

와준다.

결론

정적 분석을 통해 코드에 베스트 프랙티스를 적

용하는 것은 CI를 이용하여 적은 양을 자주 실행

하는 것으로 쉽게 적용할 수 있다. CI를 개발단계

에서만 적용하는 것이 아니라 통합 테스트 단계

까지 적용하면 더 많은 이점이 있다. 심각한 문제

가 되기 전에 문제를 알려주며, 높은 품질의 코드

가 저장소에 Commit 될 수 있게 해준다.

PRQA 정적 분석 도구인 QAC와 QAC++는 플

러그인을 통해 Jenkins와 쉽게 적용할 수 있고,

이를 통해 코딩 규칙의 만족 정도에 대한 결과

를 바로 알려준다. 위반사항에 대한 면밀한 분석

과 코드가 어떻게 변화하고 있는지 추적을 확인

할 수 있게 플러그 인은 QA·Verify에 결과를 자

동으로 업로드 한다. CI와 PRQA 정적 분석 도구

의 궁합은 정해진 시간과 개발비용에서 개발할

수 있게 해주며 높은 품질을 가질 수 있게 해준

다. (단계 저장소에서 모든 테스트를 만족하여 실

제저장소로 옮기는 일련의 작업으로) 일이 QAC

/ QAC++이 코드를 분석할 수 있게 CI서버에 설

정이 되어 있어야 한다. CI서버에서 코드가 얼마

나 코딩 규지 추적을 확인할 수 있게 플러그 인은

QA·Verify에 결과를 자동으로 업로드 한다. CI와

PRQA 정적 분석 도구의 궁합은 정해진 시간과

개발비용에서 개발할 수 있게 해주며 높은 품질

을 가질 수 있게 해준다.

그림 6.