태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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님 안녕하세요.
    귀찮아서 자동화하지 않는 개발자도 많습니다. ^^

Build Script를 C언어로 작성하기

2009.02.24 00:13 by 전규현


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




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를 만들 수 있습니다.


이미지출처 : Microsoft Office Online

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

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

  1. make를 빼고는 얘기가 안되죠 :)
    C만 쓸 줄 알다가 처음 make를 혼자 익혀보고는 감탄했던 때가 생각나는군요. 사람은 배워야죠...ㅡㅡ;

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

Daily Build를 하십니까?

2009.02.04 02:13 by 전규현


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



Daily Build는 많은 혜택을 줍니다.

소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며

모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다.

 

요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다.

여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다.

하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요.

저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Build를 할 수 있어야 한다고 생각합니다.

기본적인 개발 Stage를 사용하던, Iteration을 쓰던 간에 설계의 결과물은 빌드가 되어야 한다는 것입니다. TDD를 사용할 경우 Test 코드를 먼저 작성을 하기 때문에 빌드가 가능합니다. 테스트는 통과를 하지 못하더라도 말입니다. 즉 껍데기, Class, Public function의 Prototype을 정해 놓고 빌드가 가능한 상태로 만들어 놓고 구현을 시작합니다.

 

이때 SCM에 Baseline을 한번 설정을 하고 소스코드의 내용을 채워 나가기 시작합니다. Daily Build의 혜택을 누리기 위해서는 소스코드를 빌드 가능한 상태로 만들어 놓고 시작을 해야 합니다.


이미지출처 : Microsoft Office Online

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

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

빌드와 컴파일의 차이

2008.11.14 15:17 by 전규현


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




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

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

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

컴파일은 빌드의 부분 집합입니다.
빌드 과정은 제품마다 서로 다르지만 간단한 예를 하나 들어보면 다음과 같습니다.
보통 아래 과정은 Build Script에 의해서 한번에 자동으로 실행됩니다.
실제 예는 아래 나열한 것보다 수십배는 더 복잡합니다. ^^
  1. 소스코드관리시스템에 태그(베이스라인) 작성
  2. 작성된 태그(베이스라인) 체크아웃을 통해 빌드 전용시스템으로 소소코드 가져오기
  3. 새로운 빌드번호 획득 및 반영
  4. 컴파일(빌드) 시작
  5. 컴파일(빌드)시 발생한 에러 처리
  6. Doxygen 또는 JavaDoc 생성
  7. 팩키징 절차를 통해서 마스터 파일 생성
  8. 스모크 테스트 등 자동화 테스트 실시
  9. 테스트 결과 처리
  10. 빌드 결과를 관련자에 이메일로 전송
  11. 마스터 서버로 마스터 파일 복사
  12. 릴리즈 결과 전사 공지
빌드릴리즈는 항상 짝을 이뤄 따라 다니며, 수많은 B/R(Build/Release) 엔지니어들이 이에 대한 자동화와 효율성/생산성 증대를 위해서 연구를 하고 있지요. 
소프트웨어 프로젝트에서 빌드의 중요성에 대해서는 제가 이미 포스팅을 한 글이 있으니 참고하세요.
저작자 표시 비영리 변경 금지
신고

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

  1. 감사합니다. 잘 배웠습니다. ^^

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

  3. 좋은 글 감사합니다.
    컴파일,빌드 정의가 깔끔하네요.

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

  5. 블로그 이미지가 약간 바뀐 느낌인데...저만 그렇게 느끼는건가요? 하하.

    주말 재미있게 보내세요~

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

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

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 만드는 것은 개발자가 저지르는 가장 심각한 잘못 중의 하나입니다.


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




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

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

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

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)

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

티스토리 툴바