여기서 제가 말하고 있는 "빌드"는 "공식빌드"입니다.
"공식빌드"란 소프트웨어를 개발하는 프로젝트나 절차에서 공식 Output을 만들어 내는 것입니다.
"공식빌드"가 아닌 것은 "엔지니어링 빌드"라고 합니다.
이는 개발자가 자신의 작성한 코드를 테스트하기 위해서 비공식적으로 하는 빌드입니다.
그럼 원래 질문으로 돌아가서 "공식빌드"를 어떻게 하고 계십니까?
혹시 IDE(통합개발환경)에서 빌드를 하고 계시나요?
Visual Studio나 Eclipse의 IDE를 이용해서 빌드한 결과물이 공식적으로 릴리즈가 되고 있습니까?
그러면 잘못되고 있는 겁니다.
"공식빌드"는 IDE에서 이루어지면 안됩니다.
"공식빌드"는 빌드 전용 장비에서 커맨드라인 통해 한, 두개의 스크립트로 자동으로 전과정의 빌드가 이루어져야 합니다.
빌드작업은 대단히 전문적인 작업이라서 쉽게 생각할 것이 아닙니다.
전문화되고 자동화된 빌드는 소프트웨어 개발 생산성을 대단히 높여 줍니다.
실제로 자동화되지 않은 빌드로 인해서 많은 소프트웨어 프로젝트에서 쓸데 없는 비용을 낭비하고 있습니다.
자동화된 빌드를 통해서 할 수 있는 일은 대단히 많습니다.
자동화가 되어야 Daily Build가 가능하며, 빌드 후에 각 소프트웨어마다 이루어지는 수많은 부가 작업들이 자동으로 연결이 가능해 집니다.
어떤 제품은 Smoke Test를 붙이기도 하고,
Packaging을 해서 CD에 굽기 전의 상태까지 준비가 되기도 하고,
홈페이지에 업데이트 버전이 등록되기도하고,
버그관리시스템과 연동도 됩니다.
이러한 부가 작업은 소프트웨어나 회사마다 다릅니다.
전문 빌드담당자가 정해지면 이러한 일련의 작업에 대해서 책임감을 가지고 향상을 시키게 됩니다.
이러한 것들이 눈에 잘 보이지는 않지만, 소프트웨어 개발 역량 및 생산성 향상에 많은 영향을 미치게 됩니다.
"공식빌드"와 "엔지니어링빌드"에 대해서 구분없이 소프트웨어를 개발하고 계신다면
일단 "빌드의 중요성"에 대해서 인지를 하셔야 합니다.
막연히 빌드의 중요성은 알기 어렵죠. 앞으로 이에 대해서 계속 포스트를 하도록 하겠습니다.
빌드에 대한 의견 환영합니다.
지난 주말에 CruiseControl.NET을 이용하여 빌드환경을 구축했는데 오늘 이 포스트를 보니 딱 뭔가 박자가 맞는거 같은 느낌이...^^
답글삭제하지만, 뒤에 붙을 것들(자동화 테스트, 배포환경등)이 없는 상태에서는 좀 썰렁하네요.
주변에 자랑했다가 "왜 이렇게 (쓸데없이) 빌드를 자주해요?" 뭐 이런 소리도 좀 듣구요 ^^;
헝그리맨님 반갑습니다.
답글삭제다른 사람들도 헝그리맨님같이 좋은 툴이나 프로세스를 도입해도 이해를 잘 못하는 사람들의 반대에 많이 부딪히곤 합니다. 따라서 남을 설득할 수 있는 지식도 있어야 지요. 그렇다고 남과 부딪히지는 마세요.
CruiseControl은 CI솔루션 중의 하나죠. 소프트웨어는 구현 초기부터 지속적인 빌드가 되어야 하고 자동화 되어야 하는 것을 많은 사람들이 모르죠.
힘네시고요. 앞으로도 할게 많습니다. ^^
궁금하신 것이 있으면 언제든지 찾아오세요.
현재 진행중인 프로젝트가 수동빌드를 하고 있는데, 정말 고민이 많은 부분이다. 소스 및 버전관리를 SVN를 통해 진행중인데, Repository에 업데이트된 소스를 자동빌드후 서비스 디렉토리로 이동하는 부분에 대해선 아직 답을 찾지 못하고 있다. 레이의 소프트웨어 개발 토론 팀블로그에서 언급한대로 커멘드창에서 특정 명령어의 타이핑만으로 현재 버전이 자동으로 적용되어야 한다는 점엔 동의한다. 문제는 어떻게 그 부분을 구현하느냐다. 단순한 버그 수정 및..
답글삭제좋은글 잘봤습니다.
답글삭제헉.. 저희는 그냥 막 빌드를 해버렸는데.. -_-;;;
답글삭제이런식으로는 전혀 생각을 못해본것 같습니다.. ㅠㅠ
yagur님 반갑습니다.
답글삭제종종 뵈요.
빌드의 중요성을 먼저 아는게 중요한 것 같습니다.
답글삭제그리고 자동화된 빌드는 생산성을 대단히 높여줍니다. 하나하나 시도해보세요.
감사합니다.
안녕하세요.
답글삭제최근이 이런 멋진 블로그가 있는걸 찾아서 정독 중에 있습니다.
최근 프로젝트 진행 중에 본문의 Daily Build라는 것 때문에 엄청 고생한 적이 있어 질문을 드립니다.
질문1. Daily Build라는 것을 통해 검증하는 범위가 어디까지인지 궁급합니다.
저는 핸드폰 제작 회사의 SW 부분에서 일을 하고 있는데요,
해당 SW는 핸드폰이라는 HW에 인스톨되어 동작시키기 전까진 정상동작 여부를 판단하기가 어렵습니다.
지난번 프로젝트부터 Daily Build라는 이름 하에 매일 Build를 하고 Bug를 찾아내는데요.
일단 문제로 대두된 것이
1. 개발 진행 중이라 완성이 안된 Function에 대한 테스트를 진행해서 Bug 아닌 Bug를 찾아서
담당자에게 메일 리포팅함으로써 이유없는 업무 로딩 생성
2. 이건 저희 회사의 문제일 수 있는데... 경험 없는 개발자들이 프로젝트에 대거 투입되면서
build error 대량 발생으로 수많은 재 build 상황 발생 -> 타 개발자도 모두 대기
이전의 Event Base로 Build를 하는 식으로 진행을 했을 때는
경험이 부족한 개발자가 프로젝트에 참여를 해도 상대적으로
그 사람으로 인해 발생하는 오버헤드가 크지 않았습니다.
암튼 개인적으로 build와 bug test는 분리되어야 한다고 생각합니다만,
한편 생각하면 build 해서 error 안나는 수준까지만 검증할꺼면,
왜 daily build를 한까 하는 의문도 들고
(build Error를 지속적으로 만드는 개발자와 같이 일하는 것도 고역이긴 합니다만)
그렇다고 bug 테스트를 병행하면 시간이 너무 많이 들고...
흠.. 개발자는 그나마 스펙(표준규격, 사업자 요구사항, etc...)을 아는데(모르는 사람도 많아졌...)
테스터는 그걸 모르는 경우가 많은 것도 문제이군요....
안녕하세요. 생각나무님
답글삭제요즘 Daily Build에 대해서 오해를 하고 있는 사람들을 매우 자주 만납니다.
Daily Build의 원래 목적은 Broken Tree를 방지하는 겁니다. 즉, 프로젝트가 매일 빌드 가능한 상태를 유지하기 위한 겁니다. 여기에 추가로 Smoke Test, 정적테스트를 하는 경우도 있기는 하지만 이는 모두 자동화 된 것이고 인력을 투입해서 테스트를 하지는 않습니다.
테스트는 별도의 스케쥴을 정해서 진행합니다. 추가로 말씀을 드리면 Daily Build는 설계가 끝나고 구현이 시작되는 첫째날부터 가능해야 합니다. 이게 안되면 설계가 안된 겁니다.
테스터가 스펙을 모르는 것은 스펙을 적지 않았거나 부실하게 적었기 때문입니다. 그리고 테스터와 리뷰도 안된 겁니다.
스펙을 제대로 적지 않는 것이 프로젝트가 엉망으로 되는 가장 큰 이유입니다.
빌드에 대해 중요성을 알게되었네요.감사합니다.
답글삭제