한방에 빌드

Visual Studio나 Eclipse를 실행해야만 빌드를 할 수 있습니까?

"Yes"라고 대답하는 개발자들은 대부분은 이것이 무슨 문제인지 모르고 있는 상황입니다. 

Joel Test 12개 항목 중 하나를 차지할 정도 한방에 빌드를 만들어 내는 것은 중요합니다. Visual Studio나 Eclipse에서 버튼 하나만 누르면 빌드가 된다고 이것을 한방에 빌드를 만들어 내는 것이라고 착각하면 곤란합니다. 일단 Command line이 아니고 빌드를 위해서 사람의 손을 통해서 무슨 프로그램을 실행해야 한다면 한방의 빌드와는 거리가 먼 겁니다.

그럼 왜 한방에 빌드를 만들어 낼 수 있을까요? 

빌드는 반복적인 작업이며 대단히 귀찮은 작업이면서 전문적인 작업이기도 하고 실수하기 쉽기도 하며 개발에서 많은 시간을 소모하는 작업입니다. 한번의 빌드는 큰 시간 소모가 아니라고 생각할지 몰라도 개발 프로젝트 전체를 놓고 보면 아주 큰 시간과 비용입니다.

그래서 빌드는 자동화되어야 하고, 전문화 되어야 하고, 통제가 되어야 하며, 별도의 담당자가 할당되게 됩니다. 빌드의 효율성을 높이기 위해서 전과정을 자동화 하기 위해서는 Build Technology에 대한 연구가 이루어져야 합니다. 빌드는 일반 개발자가 개발도 하면서 매우 잘 해내기 힘든 전문 분야입니다. 

한방에 빌드란 개발자들이 해당 빌드에 추가될 모든 기능을 구현해서 소스코드 관리시스템에 등록을 한 상태에서 단 한번의 명령어 실행으로 빌드 전과정을 자동으로 실행해서 최종 마스터가 마스터 보관소에 저장이 되는 것을 말합니다. 이 빌드 전과정은 회사마다 제품마다 상당히 다르며 어떤 제품은 5분이면 끝나고 어떤 제품은 24시간이 넘게 걸리는 것도 있습니다. 또 어떤 제품은 수십개가 넘는 OS에서 빌드를 해야 하고, 어떤 제품은 빌드를 위해서 수십개의 빌드시스템을 동시에 실행하기도 합니다. 

5분짜리 빌드만 해본 개발자들이라면 한방에 빌드와 IDE를 통한 수동 빌드가 별로 차이가 없어 보이지만, 규모가 커지고 빌드가 복잡해지기 시작하면 그 차이는 확연히 드러납니다. 사실 5분짜리 빌드도 자동화의 잇점이 상당으로 작기는 하지만 자동화를 하는 것이 더 유리하죠. 그래야 자동화의 필요성도 깨닫게 되구요.

개발자가 분석, 설계, 구현하는 작업 외에 다른 작업에 많은 시간을 소모하고 있다면 그런 작업은 최대한 자동화하고 개발자들은 개발에 집중할 수 있도록 해야 합니다. 한번의 자동화가 귀찮다고 조금씩 갉아 먹는 시간은 대단히 큰 비용입니다.

아직 빌드 자동화에 대한 경험이 부족하다면 막상 시작하려면 막막한 경우들이 있습니다. 궁금하신 내용들이 있아면 제게 메일을 보내주세요. 제가 아는 한 최대한 성심껏 답변드리겠습니다.

Build Script를 C언어로 작성하기

Build Script를 Script언어가 아닌 C언어로 작성하시거나 그런 경험이 있으십니까?

저는 Build Script를 C언어로 작성하는 것을 본 적이 있습니다. 이 경우에 Build Script라고 하기에 좀 그렇군요. Build Program이라고 해야 할까요? 

누구나가 Build Script라고 부르는 이유는 Script언어로 작성하기 때문이기도 합니다.

물론 IDE에서 공식 빌드를 하는 것이 아니고 Build Script를 작성한 것은 긍정적으로 볼 수 있지만 Build Script를 사용하기 위해서 다시 Build를 해야 한다면 우습네요.

Build Script를 C언어와 같이 Build가 필요한 언어로 작성하는 경우는 이러한 경우가 있을 수 있습니다.

• C언어는 기가 막히게 잘 아는 Script언어는 잘 모른다.
• Build Logic이 복잡하여 Script언어로는 작성하기 어려울 것 같다.
• Build 과정에서 다른 시스템과 연동하는 등 인터페이스가 많다.

Script언어를 하나도 모른다면 어쩔 수 없겠지만, Script언어로도 빌드에 필요한 정도의 모든 기능은 쉽게 구현할 수 있습니다. 오히려 Build를 위해서 만들어진 Ant같은 경우는 더 효율적입니다. Script언어에 아직 익숙하지 않다면 간단하게 Batch 파일로 작성할 수도 있습니다. 그리고 C언어와 유사한 Python을 이용하면 Python을 아주 잘하지 않더라도 간단한 Build Script 정도는 만들어 낼 수 있습니다.

Build Script는 처음부터 모든 원하는 기능을 다 자동화 할 필요는 없습니다. 우선 기본적인 빌드 기능부터 구현을 한 다음에 사용을 해보면서 자동화가 필요한 부분을 차례차례 추가해 넣으면 무난히 효율적인 Build Script를 만들 수 있습니다.

빌드와 컴파일의 차이

kenu님의 블로그에 빌드와 컴파일에 대한 차이를 묻는 글이 올라와서 간단히 설명해보려고 합니다.

http://okjsp.tistory.com/1165643615

컴파일 : 소스코드 파일 등의 원시파일을 실행파일, 라이브러리 등의 Object 파일로 바꾸는 작업

빌드 : 소스코드 파일들을 컴퓨터에서 실행할 수 있는 소프트웨어로 변환하는 일련의 과정

컴파일은 빌드의 부분 집합입니다.

빌드 과정은 제품마다 서로 다르지만 간단한 예를 하나 들어보면 다음과 같습니다.

보통 아래 과정은 Build Script에 의해서 한번에 자동으로 실행됩니다.

실제 예는 아래 나열한 것보다 수십배는 더 복잡합니다. ^^

1. 소스코드관리시스템에 태그(베이스라인) 작성
2. 작성된 태그(베이스라인) 체크아웃을 통해 빌드 전용시스템으로 소소코드 가져오기
3. 새로운 빌드번호 획득 및 반영
4. 컴파일(빌드) 시작
5. 컴파일(빌드)시 발생한 에러 처리
6. Doxygen 또는 JavaDoc 생성
7. 팩키징 절차를 통해서 마스터 파일 생성
8. 스모크 테스트 등 자동화 테스트 실시
9. 테스트 결과 처리
10. 빌드 결과를 관련자에 이메일로 전송
11. 마스터 서버로 마스터 파일 복사
12. 릴리즈 결과 전사 공지

또 빌드와 릴리즈는 항상 짝을 이뤄 따라 다니며, 수많은 B/R(Build/Release) 엔지니어들이 이에 대한 자동화와 효율성/생산성 증대를 위해서 연구를 하고 있지요. 

소프트웨어 프로젝트에서 빌드의 중요성에 대해서는 제가 이미 포스팅을 한 글이 있으니 참고하세요.

빌드가 먼저일까? 베이스라인 설정이 먼저일까?

빌드와 베이스라인 순서에 대해서 이슈가 있다는 글을 보고 아래 글을 작성합니다.

몇몇 빌드관련 솔루션들이 빌드를 해서 성공을 하면 베이스라인(Tag, Label)을 설정하는 것이 있더군요.

이는 원칙에 어긋나는 겁니다.

원칙은 베이스라인을 설정한 후에 해당 베이스라인을 가지고 빌드를 하는 것입니다. 작은 소프트웨어는 사실 이러한 것이 거의 문제가 되지 않습니다. 하지만 대규모 프로젝트는 빌드에 24시간이 넘게 걸리는 것도 있습니다.

Windows NT 개발팀은 Daily Build가 48시간이 걸려서 몇대의 장비가 교대로 Daily Build를 수행했다고 할 정도 입니다.

이 경우 빌드가 끝나고 나서 베이스라인을 설정하려고 하면 이미 소스코드는 엄청나게 바뀌어 있게 됩니다.

베이스라인 설정, 태깅 한 후에 태그를 가져와서 빌드를 하도록 빌드 스크립트를 만들면 됩니다.

Broken tree

소프트웨어의 빌드가 안 되는 상황을 Broken Tree라고 합니다.

소프트웨어를 개발하는 회사라면 Broken Tree의 발생을 엄격하게 규제해야 합니다.

소스코드관리시스템 안의 소스코드는 항상 빌드가 가능한 상태로 존재해야 합니다.

그리고 언제든지 꺼내서 빌드를 하면 빌드가 되어야 합니다.

개발자들은 버그를 고치거나 새로운 기능을 추가할 때 소스코드관리시스템에서 최신 소스코드를 가져와서 소스코드를 고치고 개발자 테스트를 마친 후 소스코드를 체크인 하는 것만으로 임무가 끝나지 않습니다.  내가 소스코드를 수정하는 사이에 누군가가 다른 소스코드를 수정했을 수도 있으니 꼭 다시한번 최신 소스코드가 빌드가 되는지 확인을 해야 합니다.

믈론 한두명이 개발한다면 이런 일은 거의 없겠지만, 꽤 큰 규모의 회사나 프로젝트에서는 종종 발생하는 문제 입니다.

항상 빌드가 가능한 소스코드를 유지하기 위해서 CI (Continuous Integration)솔루션을 사용하기도 합니다.

빌드가 안 되는 코드를 체크인한 개발자는 모든 업무를 제쳐놓고 빌드가 가능하도록 만들어야 합니다. 

Broken Tree를 만드는 것은 개발자가 저지르는 가장 심각한 잘못 중의 하나입니다.

글이 좀 무거운데, 호랭이 블로그에서 재미 있는 카툰을 발견했네요. 재있게들 보세요.

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

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

여기서 제가 말하고 있는 "빌드"는 "공식빌드"입니다.

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

"공식빌드"가 아닌 것은 "엔지니어링 빌드"라고 합니다.

이는 개발자가 자신의 작성한 코드를 테스트하기 위해서 비공식적으로 하는 빌드입니다.

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

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

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

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

"공식빌드"는 IDE에서 이루어지면 안됩니다. 

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

빌드작업은 대단히 전문적인 작업이라서 쉽게 생각할 것이 아닙니다.

전문화되고 자동화된 빌드는 소프트웨어 개발 생산성을 대단히 높여 줍니다.

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

자동화된 빌드를 통해서 할 수 있는 일은 대단히 많습니다.

자동화가 되어야 Daily Build가 가능하며, 빌드 후에 각 소프트웨어마다 이루어지는 수많은 부가 작업들이 자동으로 연결이 가능해 집니다.

어떤 제품은 Smoke Test를 붙이기도 하고, 

Packaging을 해서 CD에 굽기 전의 상태까지 준비가 되기도 하고, 

홈페이지에 업데이트 버전이 등록되기도하고,

버그관리시스템과 연동도 됩니다.

이러한 부가 작업은 소프트웨어나 회사마다 다릅니다.

전문 빌드담당자가 정해지면 이러한 일련의 작업에 대해서 책임감을 가지고 향상을 시키게 됩니다.

이러한 것들이 눈에 잘 보이지는 않지만, 소프트웨어 개발 역량 및 생산성 향상에 많은 영향을 미치게 됩니다.

"공식빌드"와 "엔지니어링빌드"에 대해서 구분없이 소프트웨어를 개발하고 계신다면 

일단 "빌드의 중요성"에 대해서 인지를 하셔야 합니다. 

막연히 빌드의 중요성은 알기 어렵죠. 앞으로 이에 대해서 계속 포스트를 하도록 하겠습니다.

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