Daily Build라는 개념을 처음 알게 된건, 아마도,
2007년 언젠가, "조엘 온 소프트웨어"라는 책을 읽으면서 였을 껍니다.
1년차 개발자로써, "조엘 테스트" 항목에 있으니까, 그저 좋은 건가 보다 하면서,
다니고 있던 회사에 도입을 극구 주장했었습니다.
지금 생각해 보면 참 우스은 일이죠. 뭐가 어떻게 좋은건지도 제대로 이해하지 못하면서,
좋은가 보다 하면서 도입하자고 했으니 말입니다.
최근에, 이 Daily Build 라는 녀석에 대해서 다시 한번 생각해봤습니다.
" 이거 정말 필요한거야 ? " 라는 생각말입니다.
결론부터 말씀드리면,
"평생 혼자서만 개발할꺼라면 필요 없다."
그러나, 그런일은 거의 없겠죠? ^^
"소프트웨어 개발" 에 "협업"이라는 키워드가 추가되면, "Daily Build"가 힘을 발휘합니다.
우리가 협업을 하고 있다고 가정해봅시다.
거기다가, 우리의 프로젝트는 "국제적인" 프로젝트라서,
내가 퇴근하고나서야, 일을 시작하는 나라에 사는 사람과 협업을 하고 있습니다.
나는 퇴근하기전에 작업물을 Commit하고 갔는데,
재수가 없게도, Build가 깨져버렸습니다. 물론 Daily Build를 하고 있지 않으니, 나는 알턱이 없죠.
저 멀리 아주 먼 나라에서 같이 일하는 개발자는 기쁜 마음으로 출근했지만,
이런 우라질, 소스 컴파일 이 안됩니다.ㅜㅜ
그 사람은 자기가 잘 알지도 못하는 코드를 분석해가며, (거기다가 욕을 해가면서 ... )
수정하고 나서야, 자기 일을 시작하게 됩니다.
다음 날 출근한 저는 내 코드를 잘 알지도 모하는 녀석이, 기괴한 방법으로 수정했음을 발견합니다.
아.. 나는 Refactoring을 해야 겠군요 ;ㅂ;
만약, 여기에 Daily Build를 하고 있었다면 어땠을까요?
나는 퇴근하기전 Daily Build가 깨진것을 확인하고,
수정을 해놓고 나서야 퇴근합니다.
그럼 외쿡인 개발자가, 잘 알지도 모르는 소스를 분석할일도, 수정할일도 없었을테고,
내 소스를 그 사람이 자기 멋대로 수정할 일도 없었겠죠.
바로 이것입니다.
Daily Build는 빌드가 깨지는 일을 방지합니다.
CI Server를 통해 자동화 된 테스트 까지 "정상적"으로 수행시키도록 프로젝트를 꾸려가면,
S/W 가 Compilable 한 상태 뿐 아니라, "Runnable"한 상태를 유지하도록 도와줍니다.
사실 Daily Build라는 말을 사용했지만,
Commit Build, Integration Build 등등 다른 말로 표현되고 있는 "Build 자동화"에 대한 이야기입니다.
약간의 극단적인 예를 들긴했지만, 같은 사무실에 동시간대에 일하는 사람들도,
이런 자동 빌드가 없는 경우 , 빈도는 조금 적을 수 있겠지만, 여전히 같은 문제가 발생합니다.
"나는 Build 자동화를 무조건 도입해야 한다 !" 라고 생각하지 않습니다.
모바일 앱 개발 같은 경우, 혼자서 작업하는 경우도 분명히 많습니다.
그런 경우 Build 자동화는 사실 큰 의미가 없습니다.
당신의 프로젝트가 혼자서 하는게 아니라면,
"나는 무조건 빌드자동화를 도입해야 한다" 고 생각합니다.
