팀 협업의 중요성은 말하고 말 것도 없다. 그러나, 조금 다른 시각으로 다시 한 번 실감했다. 약 한달 전인 4월 7일 올렸던 포스트에 첨부했던 그림이다.


SCM 이력이다. 주석(Comment)에는 여러 가지 내용을 넣을 수 있다. 위에 보이는 것처럼 아무것도 넣지 않을 수도 있다. 그러나, 최소한 무엇을 변경했는지 알려줘야 내 동료가 자칫 허비할 수 있는 노력을 줄일 수 있다.

최근 3일 정도 SCM 개정 이력이다. 무슨 작업을 하고 올린 것인지 상당히 명확하게 바뀌었다. 얼마전 박재성씨가 했던 세미나에서 다룬 주제가 이른바 CI(Continuous Integration) 환경이다. 박재성씨는 아마도 Andrew Hunt와 David Thomas가 만든 조류를 칭하여 실용주의개발환경이라고 이름 지은 듯 하다.

뭐라 칭하든 팀 개발 속도(Velocity)를 높이고, 불필요한 버려지는 시간을 줄이려는 목적을 갖고 있다. 불필요한 버려지는 시간은 상당 부분은 개별 개발자들이 팀의 지향점과 동떨어져서 혼자 개발한 부분을 모아서 하나로 통합하려고 할 때 실감할 수 있다. 간혹 스스로도 Jira와 Clover 같은 도구에 집착하긴 하지만, 정작 중요한 것은 협업하는 주체 즉 팀원이다. 그들이 단결(Integration)해서 협업(Collaboration)하지 못한다면, CI 도구^[각주:1]는 한낱 것치레에 불과하다. 그러나, CMMI 인증을 얻는 과정에서 개발팀의 성숙도가 높아지는 혹은 높아지기도 하는 것을 보면, CI 도구 역시 개발팀의 협업 성숙도^[각주:2]를 높이는 촉매제 역할은 할 수 있을지도 모른다.

오픈소스 Continuous integration 툴인 헛슨(Hudson)을 이용하면 변경 내용에 대한 요약 정보를 보다 쉽게 알 수 있다. 그리고, PMD 플러그인을 추가하면 일반적인 규칙이나 팀 표준을 위반한 사항을 쉽게 확인할 수 있다. 또한 ANT Target 설정을 해두면 테스트 결과 추이를 도표로 확인할 수 있다.




테스트 커버리지를 위한 플러그인(Cobertura)을 추가하면 코드 커버리지도 확인이 가능하다. 조금만 노력하면 무료인 오픈소스 솔루션 만으로도 프로젝트 진척 상황을 보기 위한 상쾌한 환경을 구성할 수 있다. (커버리지가 0%인 좋지 못한 예제 화면이지만... ^^)

하지만, 프로젝트에 조금의 여력이 있다면 아틀라시안 툴 사용을 권장하고 싶다. (나도 아틀라시안 툴 쓰고 싶다. ㅡㅡ;)

흥미로운 뉴스는 자바지기 박재성님께서 관련 노하우를 공유하고 싶어해서, KSUG와 공동으로 세미나를 열기로 했다. 자세한 사항은 아직 일정과 장소가 미정인지라 추후 공지할 예정이다. 대략의 내용은 자바지기님 블로그에서 확인할 수 있다.


* 허드슨 관련 글:
- Hudson을 이용한 빌드 배포 테스트 자동화 (4/22 추가)
- Hudson과 CruseControl 비교(5/22 추가)

사람을 위한 자동화: 자동화를 통한 신속한 전개 (한글)

사람을 위한 자동화 시리즈 연재물을 번역한 글이다. 헛... 굉장히 좋아하는 시리즈인데, '무통(painless) 전개'라는 표현이 바로 눈에 띈다. 전개는 deployment를 번역한 것 같은데, 국내에서는 보통 배포나 배치로 쓰지 않나? painless의 경우도 '수월한' 정도로 완곡하게 표현하면 어땠을까 싶다.

이번 호 내용을 보니 옆 자리에서 프로젝트에서 코드 릴리즈 주기와 코드 관리 정책을 고민하고 있는 동료에게 오늘 바로 필요한 내용이었다. 퇴근하기 전에 출력해서 그 친구 책상에 올려둬야겠다.

개발환경을 책임지는 이 친구는 지속적 통합으로 조기에 결함 발견하기을 보고 Hudson을 후보 CI 서버로 올려놓고 시운용 중이다. 설치가 아주 간편하고, UI가 친근해서 좋다. 그런데, 반갑게도 프로젝트 고객사에서 Atlassian의 CI 제품인 bamboo를 구매를 해주려고 한다. 일민 형이 OSAF 개발을 위해 bamboo 설치했다고 자랑한 그 날, 고객사 담당자의 구매 의사를 들었다.

일민형과 채팅 중에 CI만 깔면 뭐하냐고 한다. automated test가 없으면 사실 CI 효용성이 바닥으로 떨어진다. 프레임워크 개발 때야 테스트도 꼼꼼히 하고, automated test를 하겠지만... 나중에 자동화된 테스트에 익숙하지 않은(왜 해야 하는지 납득하기도 힘든) 개발자들이 테스트 할 수 있게 가이드라도 잘 쓰라고 하면서.. 집에 가는 Toby형은 18일 후면 서울이 아니라 호주에 있는 집에 간다.

지속적 통합으로 조기에 결함 발견하기

워낙에 흥미로운 주제를 다루고 있다. 많은 개발자들에게 아직은 생소할 Continuous Integration을 다룬 글이다. 이전에 번역을 기다리는 리뷰를 쓴 일이 있는데, 약 두달만에 한글 문서가 올라왔다. 2쪽에서 '넛셸에서의 CI'라는 생소한 표현이 나오는 부분은 조금 아쉽다. 구글에서 "in a nutshell 이란"으로 검색해보면, 첫번째 결과만으로도 좋은 지침을 주었을 텐데... 하지만, 본문을 이해하는데 무리를 주는 표현은 아니다.



호감형(?) UI와 함께 Hudson은 CI툴 치고는 높은 편의성을 표방하는 것으로 보여진다.(실제 시도해보지 않아서 자신없는 어투가...ㅡㅡ;) 그러나, 매력적인 사용성을 내세우는 툴들도 토닥거려보면 삽질은 필수다. 여기 증언(?)도 있다.

p.s. 타국에서 돌아와서 올만에 올린 포스트가 영양가가 좀 떨어진다. 신나게 놀았더니 예열이 필요한 것 같다.

IBM DW Korea Java 관문 페이지에 'Continuous Integration으로 결점을 조기에 발견하기'가 올라와서 기대했는데 아쉽게 아직 번역이 안되었다. 첫 기사로 올린 것을 보니 곧 번역하지 않을까 싶다.

PDF로 받아본 원문에 대해 애기해보겠다. (DW Korea에 올라올 글에 대한 예고편 정도가 될 듯 하다.)

이 글에서 처음으로 Hudson에 대해 들었다. CI를 위한 도구에 대한 설명이 쭉 이어진다. Ant와 함께 JUnit, PMD, FindBugs. 그리고 CI와 SCM(CVS, SVN 등의 도구)의 관계를 설명한다. 뒤이어 대부분의 내용은 Hudson 설정과 활용에 대한 내용이다. 직관적인 UI가 끌렸다. CruiseControl에 비해 훨씬 호감(?)이 가고 직관적으로 보인다.



CI가 생소한 분은 Continuous Integration을 읽어보세요.

Continuous Integration