태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

소프트웨어 프로젝트에서 빌드를 어떻게 하시나요?

2008.11.10 15:27 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어를 개발하고 계신다면 빌드를 어떻게 하고 계시나요?

여기서 제가 말하고 있는 "빌드""공식빌드"입니다.
"공식빌드"란 소프트웨어를 개발하는 프로젝트나 절차에서 공식 Output을 만들어 내는 것입니다.

"공식빌드"가 아닌 것은 "엔지니어링 빌드"라고 합니다.
이는 개발자가 자신의 작성한 코드를 테스트하기 위해서 비공식적으로 하는 빌드입니다.

그럼 원래 질문으로 돌아가서 "공식빌드"를 어떻게 하고 계십니까?

혹시 IDE(통합개발환경)에서 빌드를 하고 계시나요?

Visual Studio나 Eclipse의 IDE를 이용해서 빌드한 결과물이 공식적으로 릴리즈가 되고 있습니까?

그러면 잘못되고 있는 겁니다.

"공식빌드"는 IDE에서 이루어지면 안됩니다. 
"공식빌드"는 빌드 전용 장비에서 커맨드라인 통해 한, 두개의 스크립트로 자동으로 전과정의 빌드가 이루어져야 합니다.

빌드작업은 대단히 전문적인 작업이라서 쉽게 생각할 것이 아닙니다.
전문화되고 자동화된 빌드는 소프트웨어 개발 생산성을 대단히 높여 줍니다.

실제로 자동화되지 않은 빌드로 인해서 많은 소프트웨어 프로젝트에서 쓸데 없는 비용을 낭비하고 있습니다.

자동화된 빌드를 통해서 할 수 있는 일은 대단히 많습니다.
자동화가 되어야 Daily Build가 가능하며, 빌드 후에 각 소프트웨어마다 이루어지는 수많은 부가 작업들이 자동으로 연결이 가능해 집니다.
어떤 제품은 Smoke Test를 붙이기도 하고, 
Packaging을 해서 CD에 굽기 전의 상태까지 준비가 되기도 하고, 
홈페이지에 업데이트 버전이 등록되기도하고,
버그관리시스템과 연동도 됩니다.
이러한 부가 작업은 소프트웨어나 회사마다 다릅니다.

전문 빌드담당자가 정해지면 이러한 일련의 작업에 대해서 책임감을 가지고 향상을 시키게 됩니다.
이러한 것들이 눈에 잘 보이지는 않지만, 소프트웨어 개발 역량 및 생산성 향상에 많은 영향을 미치게 됩니다.

"공식빌드"와 "엔지니어링빌드"에 대해서 구분없이 소프트웨어를 개발하고 계신다면 
일단 "빌드의 중요성"에 대해서 인지를 하셔야 합니다. 
막연히 빌드의 중요성은 알기 어렵죠. 앞으로 이에 대해서 계속 포스트를 하도록 하겠습니다.

빌드에 대한 의견 환영합니다.

전규현 기반시스템/빌드/릴리즈

  1. 지난 주말에 CruiseControl.NET을 이용하여 빌드환경을 구축했는데 오늘 이 포스트를 보니 딱 뭔가 박자가 맞는거 같은 느낌이...^^
    하지만, 뒤에 붙을 것들(자동화 테스트, 배포환경등)이 없는 상태에서는 좀 썰렁하네요.
    주변에 자랑했다가 "왜 이렇게 (쓸데없이) 빌드를 자주해요?" 뭐 이런 소리도 좀 듣구요 ^^;

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

  3. 좋은글 잘봤습니다.

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

  5. 헉.. 저희는 그냥 막 빌드를 해버렸는데.. -_-;;;
    이런식으로는 전혀 생각을 못해본것 같습니다.. ㅠㅠ

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

  7. Blog Icon
    생각나무

    안녕하세요.
    최근이 이런 멋진 블로그가 있는걸 찾아서 정독 중에 있습니다.

    최근 프로젝트 진행 중에 본문의 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...)을 아는데(모르는 사람도 많아졌...)
    테스터는 그걸 모르는 경우가 많은 것도 문제이군요....

  8. 안녕하세요. 생각나무님

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

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

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

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

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

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..