프로젝트의 지속적인 통합서버, 허드슨 (CI Server Hudson) #2

현재 프로젝트내에서 사용하고 있는 통합 서버에 대한 두 번째 이야기 입니다.

이번엔 현재 유지하고 있는 JOB 과 CI Game, 그리고 StatSvn Report 에 대해 이야기 해볼까 합니다.

JOB을 세 개로 나누어서 운영중입니다. 첫 번째는 Instant Build, 두 번째는 데일리 레포트용, 세 번째는 통합 테스트가 진행되는 서버로의 Deploy용 입니다. 최근에는 개발과 테스트가 거의 동시에 실시간으로 이루어지게 된 관계로, JOB의 수행 순서를 변경하였습니다.

 

기존

레포트 빌드 및 JUnit Test 수행 => 서버로 배포

 

현재

통합테스트 서버로 배포 (1분마다 Poll)

Instant Report Build 및 JUnit Test 수행 (20분 마다 poll)

Daily Report Build (새벽에 수행)

 

 

[그림은 20분 마다 Polling 하는 화면]

 

 

28일이 지나거나 500개 이상의 Build 는 지우는 걸로 설정해 놓았습니다만, 사실 Subversion 이 소스를 관리해 주고 있기 때문에, 특별히 보관해야 할 Artifact 가 없으면, 굳이 이렇게 잡을 필요가 없습니다.

 

 

 

JUnit Report 취합항목입니다. 치환식( *.xml )로 할 수 도 있는데, Full Name으로 잡았습니다.

 

 

테스트 커버리지 목표입니다.

 

여담입니다만, 어제 오후 4시에서 6시 사이에는 Test Hour 로 잡고, 실패하는 테스트와 모자란 테스트 항목을 작성하는 작업을 하였습니다. 오늘, 내일도 마찬가지로 수행해서 목표치를 달성해야 겠습니다.

(개발자에게 살짝 압박을 주었는데, 영 미안하더라구요)

 

 

 

개발자들의 흥미를 돋구기 위해서 CI 게임을 운영중에 있습니다... (만, 그렇게 많이 흥미로 불타오르진 않더군요. 그래도 마음 한켠에선 점수가 신경을 건드리는 것 같긴 합니다)

 

 

이번주 CI 게임 스코어 입니다. 만일 특정 개발자가 스코어 게임에 참여되어 있지 않으면, 허드슨 개발자 메뉴에서 개발자를 선택한 다음 configure 항목에서 결정해 줍니다.

 

 

강제로 점수를 리셋시키거나 게임에 참여여부를 결정할 때 사용합니다.

 

 

 

데일리 보고서에서는 StatSVN 보고서를 따로 만듭니다.

 

 

 

프로젝트의 LoC (Line of Code) 입니다. 예전에는 크게 의미를 두던 시절도 있었으나, 요즘에는 LoC의 의미가 크진 않습니다.

 

 

 

개발자들의 LoC Portion 과 Tag Cloud 입니다.

 

 

commit 할때마다 평균적으로 변경되는 라인수가 많으면 문제 발생시 특정 시점 전/후로 변경이 쉽지 않아집니다.

 

 

초반에 소스를 죽~ 받아다가 필요없는 파일들을 지우는 작업을 했더니, 라인이 쭉! 줄은 시점이 있습니다.

 

 

파일의 라인수를 체크하는 부분입니다.

 

781 라인이 넘는 코드가 있는 클래스는 리팩터링 대상이 되는 클래스 입니다. 리스크가 커지기 전에 아키텍트가 미리미리 점검해 주어야 하지 않을까 생각됩니다.

아! 이러고 있을 때가 아니네요. 옆에서 눈치를 줍니다. -_-;;; Go back to work... 해야 겠습니다.