태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '빌드'

한방에 빌드

2009.08.06 20:37 by 전규현


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




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

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

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

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

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

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

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

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

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

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

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
(image by OCReactive)


저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/빌드/릴리즈 빌드, 자동화, 한방

  1. 한방에 빌드 만들기.. 완전 순수히 귀찮아서 만들기 시작했는데 한번 스크립트로 만들고 나니 이거 없었으면 어떻게 했냐 싶습니다. 명령 한방으로 빌드, 셋업, CVS 관리까지 한번에 끝나니..

    그래서 팀에 자주 하는 말이 있습니다. 프로그래머는 귀차니스트가 되어야한다. 반복적인 작업 귀찮아.. 자동으로 할 수 있는 방법없나?? 라고 말이지요.

    아직 daily 빌드는 하지 못했는데, 글을 읽다가 다시 생각이 나네요.. 이것도 시도해봐야겠네요.

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

베이스라인

2009.08.04 23:12 by 전규현


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




"Baseline"이라는 용어가 생소한 개발자들이 있을 수 있습니다.

우리말로 번역을 하면 "기준선"이라고도 하는데, 헷갈리므로 그냥 Baseline이라고 사용해도 무관할 것입니다.

소스코드는 살아 있습니다. 매 순간 변화하고 있다고 봐도 됩니다. 실제로 몇 천명의 개발자가 참여하는 프로젝트에서는 소스코드 관리시스템의 로그를 보면 거의 매 순간 소스코드가 바뀌는 것을 알 수 있습니다. 또 작은 프로젝트라고 하더라도 어느 순간에 소스코드가 바뀔지는 알 수 없습니다. 그래서 Baseline을 관리하지 않으면 소스코드의 어느 의미 있는 순간을 잡아내는 것이 쉽지 않습니다. 그래서 Baseline을 관리합니다.

Baseline을 설정하는 방법은 여러 가지가 있습니다. 소스코드를 통째로 특정 디렉터리에 복사를 해 놓는 것도 Baseline설정의 한 방법입니다. 그 순간의 소스코드를 언제든지 꺼내 올 수 있죠. 하지만, 더 편리하고 일반적인 방법은 소스코드관리시스템의 Baseline설정 기능을 이용하면 됩니다. Visual SouceSafe에서는 Label이라고 하며 CVS, SVN에서는 Tag라고 합니다. 이중에서 SVN이 Baseline을 설정하는데 탁월한 성능적인 우위를 가지고 있습니다.

Baseline 설정이 왜 필요할지 해보지 않고 선뜻 이해를 한다는 것은 불가능합니다. 여태 Baseline 설정 한번 하지 않고도 소프트웨어를 잘 개발해 왔으니까요. 그럼 Baseline을 설정하지 않으면 어떠한 부작용들이 있는지 알아보죠.

가장 먼저 버그가 발생했을 경우 정확하게 버그가 발생한 그 버전에 대한 소스코드를 찾기가 어려워서 정확한 버그 재현이 곤란해질 수 있습니다. 그리고 릴리즈가 통제가 되지 않을 수도 있습니다. 즉, 1.5버전을 빌드해서 만들어 놓고, 은근 슬쩍 소스코드 몇 개 바꾸고 그냥 1.5버전을 다시 빌드해서 그냥 내보내는 겁니다. 사소한 것으로 생각해서 이렇게 하는 경우도 있지만, Baseline이 관리되지 않은 조직에서는 흔히 볼 수 있는 일입니다. 

Baseline은 주민등록과 같이 개발팀에서 낳은 모든 아이(소프트웨어)의 기록입니다. 개발팀에서는 아무리 많이 소스코드를 바꾸어도 출생기록이 남는 것은 아닙니다. 하지만, 일단 소프트웨어가 빌드 되어서 개발팀 바깥으로 나가서 테스트팀으로 넘기던, 고객이 소프트웨어를 사용하던, Baseline라인이 관리되어야 합니다. 소스코드 한 줄을 바꿔서 다시 릴리즈를 했어도 Baseline은 바뀐 것이고, 다른 소프트웨어로 관리가 되어야 합니다. 그렇지 않으면 아이는 수십명 낳아놓고 각 아이들의 출생 기록도 없고, 이름도 없는 아이들이 많아지는 겁니다. 많은 아이 중에서 한 아이가 아픈데, 누가 아픈 것인지 정확하게 지칭도 못하는 일이 발생하기도 합니다.

소스코드관리시스템을 이용하면 아주 쉽게 Baseline을 설정할 수 있습니다. 기존에 Baseline을 설정하지 않고도 소프트웨어 개발에 문제가 없다고 하더라도, 기존의 방법에 익숙해진 것 뿐이지 문제가 없는 것도 아니고 효율적이지도 못합니다. 소프트웨어를 빌드하고 릴리즈하는 기준을 현재변화하고 있는 소스코드가 아닌 Baseline을 이용하는 방법으로 전환을 해야 합니다. 각론에 들어가면 회사마다 Baseline설정 규칙이 달라질 수는 있겠지만, 소프트웨어를 공식 빌드하고 릴리즈하기 위해서는 Baseline을 설정한다는 규칙은 바뀌지 않습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 Baseline, 릴리즈, 빌드, 소스코드관리, 형상관리

  1. 저희는 cvs에서 tag를 이용하고 있는데, 작은 규모 치고는 소장님께서 잘 운영을 하고 있었던 거군요 -ㅁ-!

  2. 구차니님 안녕하세요. 개발팀 규모가 아무리 작아도 Baseline은 설정해죠. ^^ CVS의 단점 중의 하나가 프로젝트의 규모가 커지면, Tag, Branch 생성에 시간도 오래 걸리고, 시스템 공간을 많이 차지하는 것입니다. 대규모프로젝트를 하다보면 CVS의 불편함을 종종느끼게 됩니다.

누가 소스코드를 몰래 바꿔놨다.

2009.07.13 19:57 by 전규현


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



누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회
사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 


저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 Peer Review, 빌드, 소스코드관리, 슈퍼맨3, 테스트

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

2008.11.12 17:09 by 전규현


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





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

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

원칙은 베이스라인을 설정한 후에 해당 베이스라인을 가지고 빌드를 하는 것입니다. 작은 소프트웨어는 사실 이러한 것이 거의 문제가 되지 않습니다. 하지만 대규모 프로젝트는 빌드에 24시간이 넘게 걸리는 것도 있습니다.
Windows NT 개발팀은 Daily Build가 48시간이 걸려서 몇대의 장비가 교대로 Daily Build를 수행했다고 할 정도 입니다.
이 경우 빌드가 끝나고 나서 베이스라인을 설정하려고 하면 이미 소스코드는 엄청나게 바뀌어 있게 됩니다.

베이스라인 설정, 태깅 한 후에 태그를 가져와서 빌드를 하도록 빌드 스크립트를 만들면 됩니다.
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/빌드/릴리즈 베이스라인, 빌드

  1. 안녕하세요? 올리신 글 잘 읽었습니다. 그런데 얼핏 읽어서는 "왜" 문제가 되는지 감이 잘 오지 않습니다. 좀 더 구체적인 사례를 들어주시면 도움이 많이 될 것 같은데요... 감사합니다.

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

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

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

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

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

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

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

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

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

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

  8. PinkPapa님 안녕하세요.

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

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

Broken tree

2008.11.12 14:06 by 전규현


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





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

 

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

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

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

 

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

 

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

 

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

 

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

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


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




저작자 표시 비영리 변경 금지
신고

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바