CI 서버(Hudson)를 사용할 경우 SCM에 대한 Commit Comment의 의미

보통 개발자들에게 가급적이면 자주 커밋(commit 혹은 check-in)을 할 것을 권장한다. 적어도 메소드 하나 정도가 완료되면, 그리고 컴파일 에러가 발생하지 않으면 작업한 내용을 소스 저장소(Source Repository)로 보내야 한다.

흔히 보이는 잘못된 Commit 의 케이스를 뽑아보면 이렇다.

- Comment 없는 commit
  . 특히 CI 서버와 연동되어 있을 경우, 해당 빌드에 참가한 소스가 뭘 하는건지 쉽게 알수 없게 된다.
- 컴파일 에러가 있는 소스의 커밋
  . 빌드를 깨뜨리게 된다.
- 지나치게 짧은 간격의 commit
  . 빌드서버에 부하를 준다.
  . 변경 comment 를 달기 어렵게 된다.

해결책
- Comment 없는 commit
<- pre-commit 이나 post-commit 등의 Hook Script 를 사용한다.
  (subversion 같은 경우 hook 폴더내에 유닉스용 template 를 제공하는데, 이를 윈도우 버전환경에 맞게 수정한 다음 .bat 이나 .cmd 파일로 확장자를 변경하면 된다.)

- 컴파일 에러가 있는 소스의 커밋
<-- 컴파일 에러가 있는 소스를 커밋한 개발자에게 채찍
<-- Sandbox 개념을 이용해서 컴파일 오류가 없는 빌드만 Deploy 가 될 수 있도록 CI 서버의 JOB을 듀얼로 구성한다.

- 지나치게 짧은 간격의 commit
 . 아키텍트가 commit 간격을 정해준다.
 . commit comment 의 작성 난이도를 높인다.
 . 바로직전의 comment 와 동일한 코멘트로 commit 하는 것을 막는다. (정책적 혹은 기술적으로)