일일 빌드가 제공하는 장점#
- 버그를 수정하고 나면, 테스터는 새 버전을 빠르게 얻어서 정말 해당 버그를 수정했는지 살펴보기 위해 다시 테스트 작업을 수행할 수 있다.
- 개발자는 테스트용 장비를 별도로 두지 않고서도 시스템의 버전 중 어느 버전도 망가뜨리지 않았다고 좀더 확신할 수 있다.
- 정기적인 일일 빌드 바로 직전에 변경을 체크인한 개발자는 어느 누구도 컴파일이 불가능한 상황을 만들어 버리지 않으리라는 사실을 안다. ‘빌드를 꺠버리는’ 어떤 파일을 체크인해 다른 사람을 방해하지 못한다.
- 미완성된 제품을 사용해야 하는 마케팅, 베타고객사이트와 같은 외부 그룹은 상당히 안정적으로 알려진 빌드를 구해서 잠시 동안 이를 사용해볼 수 있다.
- 모든 일일 빌드 모음을 유지해두면, 정말 이상하고 새로운 버그가 출현했는데 이유를 밝히기 어려울 때, 이진 탐색 기법을 동원해 과거 이력을 뒤져서 버그가 코드에 처음 출현한 시점을 알아낼 수 있다.
- 프로그래머가 수정했다고 생각하는 문제점을 테스터가 보고할 때, 테스터는 문제를 확인한 빌드 번호를 말해줄 수 있다.
일일 빌드를 위한 몇가지 팁#
- 일일 빌드 스크립트로 전체 최종 빌드를 수행할 수 있게 만들어라. 한사람의 머리에만 있는 ‘문서화된’ 빌드 프로세스를 없앨 수 있다.
- 파일은 모두 다시 체크아웃한 다음에 완벽하고 깨끗한 일일 빌드로 만들어낸 코드만 외부로 선적해야 한다.
- 컴파일러 경고 옵션을 최대로 켜고 아주 사소한 경고가 발생할 때도 일일 빌드를 멈추게 만들어라.
- 일일 빌드가 깨졌다면, 팀 전체 작업을 중단해라.
- 일일 빌드 스크립트는 전체 개발 팀에게 이메일로 실패를 통보해야만 한다.
- 빌드를 꺠버린 사람은 다음에 다른 사람이 빌드를 깰 때까지 일일 빌드를 책임지고 수행한다.
- 팀이 모두 같은 시간대에 일한다면, 점심 시간에 빌드를 하는 게 좋다.
- 팀이 상이한 시간대에 작업을 진행한다면, 일일 빌드 일정을 조정해서, 특정 시간대에 있는 사람이 다른 시간대에 있는 사람을 방해하지 않게 한다.