Whitekid님 안녕하세요.
귀찮아서 자동화하지 않는 개발자도 많습니다. ^^

Eminency님 안녕하세요.
make도 제대로 사용하려면 공부를 많이 해야하죠. 대부분들 선배들이 만들어 놓은 makefile 그냥 조금씩 수정해서 사용을 하고 전체 의미는 잘 모르고 쓰는 경우들이 많더군요. 또 Windows플랫폼에서 개발하는 개발자는 그냥 IDE에서 만들어주는 대로 그냥 빌드를 하기 때문에 make의 과정이나 옵션등을 속속들이 모르고 그냥 쓰고 있는 경우가 많습니다. 빌드 자동화를 위해서는 make나 nmake에 대해서 잘알아야죠.

kenu님 반갑습니다.
그렇게 말씀하시면 쑥스럽고요 앞으로 좋은 의견 많이 나눠요. 감사합니다.

서영아빠님 안녕하세요.
빌드에 대해서 관심이 많으신가보네요.
앞으로도 좋은 정보 많이 교환해요.
감사합니다.

식빵님 안녕하세요.
블로그 대표 이미지 바뀌었습니다. 눈썰미 있으시네요.
주말 잘보내세요. ^^

이병준님 안녕하세요.
왜 문제가 되는지는 본문에 있습니다만...

작은 프로젝트에서는 거의 문제가 되지 않기 때문에 문제를 겪어본 경험이 없거나 감이 안올 수도 있습니다.
원칙은 태깅(베이스라인)을 한것과 빌드하여 릴리즈한 것은 완전히 동일해야 합니다. 그것이 Configuration Identification의 기본 원칙입니다. 왜그런지는 감이 안오면 실제로 대규모 프로젝트를 해보던지 소프트웨어 개발 프로세스의 전과정을 모두 겪어보면 됩니다.

그렇지 않다면 당장 지금 문제를 겪을 일을 없을 겁니다.
이 글을 올린 이유도 이것이 이슈가 된다는 한 글을 보고 트랙백으로 올린 겁니다. ^^

네 본문에 무슨 말씀하신지는 알겠습니다만... 성공적으로 마쳐진 빌드에 태그를 설정하게 되면 태그 설정 시점에 소스 코드가 엄청나게 바뀌어 있게 된다고 하셨는데요. 이런 상황에서 문제가 될 만한 것을 생각해 본다면, 태그에 설정된 날짜가 실제 빌드를 시작한 날짜와 일치하지 않는다는 것 정도가 될 것 같은데, 그것이 문제가 된다는 말씀이신지요?

태그(베이스라인)은 기준선입니다. 그런데 빌드를 하고 태깅을 하면 그 기준선이 방금 빌드를 한 것과 다른 것이 될 수 있다는 뜻입니다. 태그(베이스라인)은 빌드와 완전히 일치를 해야 한다는 말입니다. 날짜가 같아야 한다는 것을 넘어서 Configuration Identification이 보장이 되어야 한다는 뜻입니다. ^^

친절한 답변 감사드립니다. 그런데 계속 궁금증이 생기네요. ^^; 트랙백 거셨다는 원글을 좀 알려주시면 이해하는데 도움이 될 것 같습니다. 미리 감사드립니다~

이병준님 트랙백 주소는 http://blog.naver.com/tb/sonjae76/10033773331 인데, 해당 포스트는 찾기가 어렵네요. - -;

참고로 SVN에서는 사후 태깅도 지원합니다.

SVN이 사후 태깅이 가능한 이유는 CVS 처럼 파일 단위의 버전 관리가 아닌 저장소 중심의 리비전을 관리하는 관계로 빌드 당시의 소스 리비전만 알고 계시면 언제든지 사후 태깅도 가능합니다.

그러나, 프로젝트의 중요성이 크다면 사전 태깅을 하거나 빌드 자동화 스크립트를 이용하여 자동 태깅이 되도록 하는 것이 좋습니다.

PinkPapa님 안녕하세요.

PinkPapa님은 이 팀블로그의 블로거 중 한분이시고 제가 알고 있는 최고의 빌드/릴리즈/SCM(Software Configuration Management)에 대한 전문가이십니다. 물론 최고의 개발자이면서요. ^^

좋은 지적이시네요. SVN은 Revision 번호만 알면 언제든지 태깅을 할 수 있죠.
제가 컨설팅을 할 때는 항상 원칙을 강조해서 설명을 합니다. 그래야 각인이 되더군요.
그렇게 해도 항상 예상치 못한 오류나 실수가 자주 생기더군요.

헝그리맨님 반갑습니다.
다른 사람들도 헝그리맨님같이 좋은 툴이나 프로세스를 도입해도 이해를 잘 못하는 사람들의 반대에 많이 부딪히곤 합니다. 따라서 남을 설득할 수 있는 지식도 있어야 지요. 그렇다고 남과 부딪히지는 마세요.
CruiseControl은 CI솔루션 중의 하나죠. 소프트웨어는 구현 초기부터 지속적인 빌드가 되어야 하고 자동화 되어야 하는 것을 많은 사람들이 모르죠.
힘네시고요. 앞으로도 할게 많습니다. ^^
궁금하신 것이 있으면 언제든지 찾아오세요.

yagur님 반갑습니다.
종종 뵈요.

빌드의 중요성을 먼저 아는게 중요한 것 같습니다.
그리고 자동화된 빌드는 생산성을 대단히 높여줍니다. 하나하나 시도해보세요.
감사합니다.

안녕하세요. 생각나무님

요즘 Daily Build에 대해서 오해를 하고 있는 사람들을 매우 자주 만납니다.

Daily Build의 원래 목적은 Broken Tree를 방지하는 겁니다. 즉, 프로젝트가 매일 빌드 가능한 상태를 유지하기 위한 겁니다. 여기에 추가로 Smoke Test, 정적테스트를 하는 경우도 있기는 하지만 이는 모두 자동화 된 것이고 인력을 투입해서 테스트를 하지는 않습니다.

테스트는 별도의 스케쥴을 정해서 진행합니다. 추가로 말씀을 드리면 Daily Build는 설계가 끝나고 구현이 시작되는 첫째날부터 가능해야 합니다. 이게 안되면 설계가 안된 겁니다.

테스터가 스펙을 모르는 것은 스펙을 적지 않았거나 부실하게 적었기 때문입니다. 그리고 테스터와 리뷰도 안된 겁니다.

스펙을 제대로 적지 않는 것이 프로젝트가 엉망으로 되는 가장 큰 이유입니다.