-All of Software-

Search results for '기반시스템'

2009/08/06 -- 한방에 빌드 (2)
2009/08/04 -- 베이스라인 (2)
2009/07/19 -- 이 소스코드는 나 밖에 못 건드려! (10)
2009/07/13 -- 누가 소스코드를 몰래 바꿔놨다.
2009/04/12 -- 버그관리시스템 사용 현황 조사 결과 (2)
2009/03/08 -- 소스코드관리 상세 조사 결과 리포트 (6)
2009/03/05 -- 몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다.
2009/02/28 -- 사라진 소스코드 (4)
2009/02/25 -- Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)
2009/02/24 -- Build Script를 C언어로 작성하기 (2)

한방에 빌드

2009/08/06 20:37

2 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

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

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

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

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

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

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

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

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

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

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

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

(image by OCReactive)

'기반시스템 > 빌드/릴리즈' 카테고리의 다른 글

한방에 빌드 (2)	2009/08/06
Build Script를 C언어로 작성하기 (2)	2009/02/24
Daily Build를 하십니까? (0)	2009/02/04
빌드와 컴파일의 차이 (6)	2008/11/14
빌드가 먼저일까? 베이스라인 설정이 먼저일까? (8)	2008/11/12
Broken tree (0)	2008/11/12

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

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/138

whitekid

2009/08/07 10:17

Reply | Edit

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

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

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

2009/08/07 12:13

Reply | Edit

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

베이스라인

2009/08/04 23:12

2 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

"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 [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

'기반시스템 > 소스코드관리' 카테고리의 다른 글

베이스라인 (2)	2009/08/04
이 소스코드는 나 밖에 못 건드려! (10)	2009/07/19
누가 소스코드를 몰래 바꿔놨다. (0)	2009/07/13
소스코드관리 상세 조사 결과 리포트 (6)	2009/03/08
사라진 소스코드 (4)	2009/02/28
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)	2009/02/25

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

Leave a Commnet 1 Trackback

Trackback Address: http://allofsoftware.net/trackback/137

2009/11/24 18:46

Delete

여러분의 소스코드는 안녕하십니까? Tracked from 청하는 애자일 개발자

구차니

2009/08/05 01:04

Reply | Edit

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

2009/08/05 10:46

Reply | Edit

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

이 소스코드는 나 밖에 못 건드려!

2009/07/19 11:01

10 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

"우리 팀은 각자 맡고 있는 소스코드가 다 달라서 서로 충돌 날 일이 전혀 없어요"

"이 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게"

"내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려"

"지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 수 없어요. 이거 다 끝날 때까지 기다려주세요."

이와 같은 현상이 친숙하나요? 그럼 Parallel Development(병행개발)와는 거리가 멉니다.

개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 때 항상 Lock을 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다.

아키텍처적인 이슈를 제외하고는 개발자들은 서로 같은 소스코드를 얼마든지 동시에 수정할 수 있고, 소스코드가 충돌이 일어나더라도 얼마든지 쉽게 해결할 수 있어야 합니다. 또한 동일한 소스코드를 기반으로 길고 짧은 프로젝트를 동시에 진행하면서 나중에서 손쉽게 Merge를 할 수 있어야 합니다. 이런 식으로 개발을 하지 않으면 대형 프로젝트는 너무 오래 걸릴 수 밖에 없습니다.

또한 이 때문에 각 개발자들이 Component Owner식으로 자신만 소스코드를 다룰 수 있다면 개발자들간에 소스코드 공유가 취약해지며 서로 단절된 개발을 하기 십상이 됩니다.

하지만 이런 Component Owner방식에 익숙한 환경에서는 이것이 너무 당연하게 생각이 되므로 이것을 바꾸려는 생각을 하기란 쉽지가 않습니다. 지금이 방식이 익숙하고 별 문제가 없어 보이고 또 이런 환경에서 발생한 문제들을 온갖 편법으로 피해 왔기 때문에 바꾸기가 쉽지 않습니다. 하지만 이로 인해 발생하는 문제들은 무시할 수 없습니다.

Parallel Development를 제대로 수행하려면 소스코드관리시스템을 단순히 소스코드 저장소 용도로 사용해서는 부족합니다. 소스코드관리시스템을 제대로 사용하기 위한 프로세스와 규칙이 필요하며 Branch와 Tag, Merge를 용도에 맞게 능숙하게 사용할 수 있어야 합니다.

이미지출처 : Microsoft Office Online

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

'기반시스템 > 소스코드관리' 카테고리의 다른 글

베이스라인 (2)	2009/08/04
이 소스코드는 나 밖에 못 건드려! (10)	2009/07/19
누가 소스코드를 몰래 바꿔놨다. (0)	2009/07/13
소스코드관리 상세 조사 결과 리포트 (6)	2009/03/08
사라진 소스코드 (4)	2009/02/28
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)	2009/02/25

Ray.전규현 기반시스템/소스코드관리 소스코드관리

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/131

mv

2009/07/19 11:49

Reply | Edit

지금 회사에서 svn을 쓰고 있습니다. 그냥 깔아서 쓰고 있죠. 문서공유와 프로젝트 소스코드를 관리하기 위함입니다.하지만 svn담당자는 branch가 뭔지,tag가 뭔지, merge기능이 뭔지 모르더군요. 그냥 계정주고 인스톨만 하면 끝인줄 압니다. 안타깝죠~.그렇게 깔아놓고 후배들에게 무언가를 가르칩니다. 안타깝죠.~
Ray.전규현

2009/07/19 16:34

Reply | Edit

안녕하세요. SVN을 그렇게 사용한다면 SVN이 주는 혜택의 5%정도밖에 못보는 거죠. "소스코드관리시스템을 사용하고 있습니까?"라는 질문에 "Yes"라고 답하기 곤란한 경우죠.
2009/07/20 08:21

Reply | Edit

비밀댓글 입니다
구차니

2009/07/20 09:36

Reply | Edit

결론은 버전 컨트롤 인가요 ㅋ
아직 태그만 사용해봤지 브랜치는 사용해 보질 않아서 ㅠ.ㅠ 한 10% 기능밖에 못쓰는거 같아요
Ray.전규현

2009/07/20 10:17

Reply | Edit

안녕하세요. 구차니님
결론이 버전컨트롤이라기보다는 이것은 소프트웨어를 개발하는데 있어서 아주 기초가 되는 사항이기 때문에 결론보다는 시작이라고 해야 적당한 것 같습니다. 단순히 소스코드를 공유하고 백업 받는 기능을 익히는데는 5분이면 족하지만, 그 외에 중급/고급 기능은 제대로 익히는데 몇년이 걸리기도 합니다.
whitekid

2009/07/20 14:37

Reply | Edit

그래서 우리 팀엔 규칙이 있죠.. 먼저 커밋한 사람이 이기는거다.. ^^;
Ray.전규현

2009/07/20 18:28

Reply | Edit

안녕하세요. whitekid님
불변의법칙이죠. 먼저 커밋하는 사람이 장땡이죠. ^^
거대한 프로젝트에서는 나중에 커밋하는 사람이 Merge하는데 며칠이 걸리기도 합니다. 아무리 툴의 지원을 받아도 그런 경우도 있죠.
ASH84

2009/11/10 12:24

Reply | Edit

ㅋㅋ 가장 먼저 커밋 하는 사람이 장떙? ㅋㅋ
Ray.전규현

2009/11/10 16:22

Reply | Edit

ASH84님 안녕하세요.
왠만한 규모의 프로젝트에서는 Merge를 잘 이용하며 손쉽게 공동작업이 짧은 시간에 이루어집니다.
sozu

2009/11/24 18:42

Reply | Edit

저희는 ClearCase를 쓰고 있는데...
"소스코드관리시스템을 이용하고 계십니까?" 라는 질문에 "No"라고 해야 할듯 싶네요..에공~

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

2009/07/13 19:57

'기반시스템 > 소스코드관리' 카테고리의 다른 글

베이스라인 (2)	2009/08/04
이 소스코드는 나 밖에 못 건드려! (10)	2009/07/19
누가 소스코드를 몰래 바꿔놨다. (0)	2009/07/13
소스코드관리 상세 조사 결과 리포트 (6)	2009/03/08
사라진 소스코드 (4)	2009/02/28
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)	2009/02/25

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

Leave a Commnet 1 Trackback

Trackback Address: http://allofsoftware.net/trackback/128

2009/07/14 09:07

Delete

권혜진의 생각 Tracked from fat's me2DAY

버그관리시스템 사용 현황 조사 결과

2009/04/12 20:23

2 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

그동안 제 블로그에서 50일동안 버그관리시스템 사용 현황을 조사하였습니다.

소프트웨어를 개발하는데 필수적인 요소 중의 하나인 버그관리를 어떻게 하고 있는지 조사하기 위함이었습니다.

물론 여기서 말하는 광의의 버그를 말하며, 이슈관리시스템, 이슈추적시스템이라고도 불리며 모두 같은 시스템이라고 생각하시면 됩니다.

질문은 다음과 같습니다.

버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요.

복수 응답을 허용하면서 투표한 결과 총 73표가 모였습니다.

그럼 그 투표결과를 분석해보도록 하겠습니다.

버그관리시스템 사용 vs. 미사용 비율

보시다시피 버그관리시스템은 68%만이 사용하고 있었고 32%의 사용자는 버그관리시스템을 사용하고 있지 않습니다. 버그관리시스템을 사용하지 않은 그룹은 버그관리를 하지 않거나, 엑셀파일 또는 워드파일로 관리를 하거나 전문 버그관리시스템이 아닌 게시판 등을 사용하고 있었습니다.

소스코드관리시스템 미사용율은 25%였는데, 이보다 더 높은 수치를 기록하고 있습니다.

버그관리시스템을 사용하는 것만으로도 소프트웨어 개발 생산성 및 효율성은 상당히 향상됩니다. 그리고 소프트웨어의 규모나 복잡성이 증가할 수록 시스템 없이 파일 등으로 관리하는 것은 점점 불가능해집니다. 물론 소프트웨어가 아무리 작아도 엑셀파일로 관리하는 것보다는 버그관리시스템이 훨씬 낫죠.

버그관리시스템도 소스코드관리시스템과 마찬가지로 단순히 설치해서 사용하기만 하는 것은 아주 기초적인 혜택만 누리는 것입니다. 버그관리시스템의 혜택을 제대로 누리기 위해서는 개발 프로세스도 필요하며 오랜 훈련과 경험이 필요합니다.

전체 투표 결과

전체 투표결과는 위와 같습니다. 엑셀로 버그관리를 하는 비율(18%)와 자체 제작한 버그관리시스템 사용 비율이 매우 높다는 것에 놀리자 않을 수 없었습니다. 특히 자체 제작한 버그관리시스템은 실패하는 것이 일반적입니다. 버그관리를 간단하고 쉽게 생각하고 자신의 회사에 딱 맞는 버그관리시스템을 만들 수 있다고 착각하지만, 실제 만들어서 사용하다보면 문제점이 많습니다.

우선 자신의 회사에 딱 맞는 시스템이라는 것이 기존의 회사에서 개발하는 방식에 문제가 있는 경우가 대부분이기 때문에 이에 딱 맞추면 회사의 개발 프로세스는 나아지는 것이 없습니다. 오히려 제대로 된 툴에 회사의 프로세스를 변화시켜서 맞춰나가는 것이 성공할 가능성이 더 높습니다. 또 버그관리시스템에 대한 전문적인 지식 없이 표면적인 기능만 구현을 하게 되면 계속되는 기능 추가 및 유지보수 이슈로 본업인 제품개발에 지장을 초래할 수도 있습니다. 이러다가 결국 포기하고 제대로된 툴을 사용하다보면 그동안 나쁜 버릇들이 몸에 베어서 정상적인 경우면 1,2개월이면 적응할 것을 적응 기간이 몇배 더 들고 또 실패할 수도 있습니다. 운동도 처음에 나쁜 자세가 몸에 익어버리면 제대로 배우는데 처음부터 배우는 것보다 몇배 더 오래 걸리는 것과 같은 원리입니다.

따라서 버그관리시스템은 처음부터 기존에 나와았는 상용이나 무료 툴들을 사용하는 것이 올바른 방법입니다. 서투른 다른 시도는 안하니만 훨씬 못합니다.

버그를 관리하지 않는 비율이 7%나 되는데, 음.. 버그가 하나도 없다는 얘기일까요? 신기하군요. 회사가 작다면 작은 PC에다가 Matis등의 무료 버그관리시스템을 설치해서 써보는 것도 좋은 방법입니다. 제대로 쓰기만 하면 개발 패러다임이 바뀔 것 입니니다.

버그관리시스템의 사용 비율

버그관리시스템을 사용하고 있는 집단에서의 시스템 사용비율을 따로 뽑아봤습니다.

그 결과 Mantis가 32%를 기록했습니다. 즉 버그관리시스템을 사용하고 있다면 3명중 1명은 Matis를 사용하고 있다는 것입니다.

그리고 Trac, JIRA, Bugzilla등의 순서인데, IBM CQ나 Teamwork를 쓰고 있는 회사도 소수 있었습니다.

Matis는 설치가 쉽고 사용이 쉽고 직관적이라서 많은 개발자들이 선호하는 것으로 보입니다. 또 무료라는 것도 무시할 수 없는 매력이겠지요.

결론

버그관리시스템의 사용비율은 예상외로 낮았습니다. - 68%

또, 자체적으로 만들어서 사용한다는 비율도 꽤 높았습니다. - 10%

이를 미루어 볼 때 버그관리에 대한 의식이 매우 낮고, 버그관리를 만만하게 보는 경향을 엿볼 수 있었습니다.

소스코드관리시스템을 만들어서 사용한다는 개발자들은 별로 보기가 힘듭니다. 일단 어려워보이거든요.

하지만 버그관리시스템을 팔기위해서가 아니고 자신들이 사용하기 위해서 만든다고 하는 개발자들을 쉽게 볼 수 있는 이유는 버그관리시스템이 만들기 쉽다고 생각하는 것 같습니다.

DB 좀 핸들링 할 줄 알고 Web 프로그래밍을 할 수 있으면 버그관리시스템을 만들 수 있다고 생각합니다. 버그관리시스템은 그렇게 간단한 것이 아닙니다. 크고 작은 소프트웨어 회사의 전체 개발프로세스를 완전히 이해하지 않으면 이를 개발할 수는 없습니다. 현재 유명한 Mantis 등의 버그관리시스템들도 모두 수십년에 걸쳐서 축적된 버그관리 철학이 녹아 있는 것입니다.

따라서, 이러한 버그관리시스템에 잘 적응해여 사용하는 것만으로도 수십년간 축적된 개발 프로세스와 문화를 흡수할 수 있는 좋은 기회입니다.

버그관리가 별거 아니라고 생각하는 서투른 착각으로 이런 좋은 기회를 차버리는 과오를 범하면 안되겠습니다.

버그관리시스템을 도입하거나 사용하시면서 의논할 사항이 있으면 언제든지 연락을 주세요. 도움을 드리도록 하겠습니다. 감사합니다.

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

image by coolbugstuff.com

'기반시스템 > 버그관리' 카테고리의 다른 글

버그관리시스템 사용 현황 조사 결과 (2)	2009/04/12
효과적인 버그 처리 방법 (6)	2008/12/09

Ray.전규현 기반시스템/버그관리 Bugzilla, ClearQuest, Jira, Mantis, Teamwork, trac, 버그관리, 소프트웨어, 엑셀, 이슈관리, 이슈처적, 투표

Leave a Commnet 2 Trackbacks

Trackback Address: http://allofsoftware.net/trackback/111

2009/04/14 08:27

Delete

자체 제작한 버그관리 시스템도 훌륭합니다. Tracked from 머샤의 인생과 웃기는 고양이
2009/04/15 11:54

Delete

Trac 관련 글 모음입니다. Tracked from TOW (TracOnWindows)

잘난맛에사는

2009/04/13 09:29

Reply | Edit

맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
저희회사도 이제막 도입을 검토중이거든요..
프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^
Ray.전규현

2009/04/13 12:47

Reply | Edit

어떤 시스템을 도입하려하시나요? Mantis? JIRA? 도입과정에서 어려움이 있거나 사용상의 이슈등 궁금하신 것이 있으면 언제든지 문의하세요. 감사합니다.

소스코드관리 상세 조사 결과 리포트

2009/03/08 16:18

6 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 2주에 걸쳐서 2차 조시를 실시했습니다.

질문항목이 26개나 되는 상당히 긴 투표였지만, 많은 분들이 응해주셔서 나름대로 의미있는 수치를 얻을 수 있었습니다. 투표에 참여해주신 모든 분께 감사드립니다.

투표위젯에 참 참여자 수를 보는 방법이 없어서 가장 많은 득표를 한 항목으로 미루어 짐작해서 35명이 투표에 참여한 것으로 생각하고 있습니다.

질문은 다음과 같았습니다.

각 항목별로 총 득표수는 다음과 같습니다. 아래 조사는 소스코드관리시스템을 사용하는 회사를 기준으로 계산을 할 것이므로 1번 항목은 100%입니다.

그럼 각 항목 별로 분석을 해보도록 하겠습니다.

1) 관리방법

2번 항목은 모든 개발자가 얼마나 소스코드관리시스템을 철저히 사용하는지에 대한 조사입니다. 소스코드의 Working copy가 개발자 PC나 개발서버에 임시로 있을 수는 있어도, 보관의 목적으로 다른 곳에 보관을 하면 안됩니다.

3번 항목은 소스코드와 문서를 같이 보관하고 있는가에 대한 조사입니다. 즉, 소스코드 뿐만 아니라 Baseline에 포함이 되어야할 모든 문서도 같이 보관을 해야 합니다. 조사결과 문서를 같이 보관한다는 응답이 40%에 불과하는데, 실제로 Baseline에 포함될 모든 문서와 자료를 다 보관하는 경우는 40%보다 더 적을 것으로 생각이 되는 군요. Baseline을 설정할 때 항상 문서와 소스코드는 같은 버전으로 짝을 이루어야 합니다. 대부분의 소프트웨어 개발 회사가 문서 작성에 소흘하기 때문에 이 항목은 아예 신경을 안쓰는 경우가 많습니다.

2) Baseline

이 항목들은 Baseline을 얼마나 제대로 설정하고 있는가에 대한 조사입니다.

Baseline을 설정한다는 응답도 54%로 낮은 편이나 제때 빠짐없이 Baseline을 항상 설정한다는 응답은 26%에 불과하다는 것을 알 수 있습니다. 특히 프로젝트 종료후 한번만 Baseline을 설정하는 경우도 있었습니다.

똑, 특이할만 한 점은 앞의 조사에서 문서도 같이 저장하는 경우는 40%이나 문서도 같이 Baseline을 설정하는 경우는 17%에 불과합니다. 즉, Tag나 Label을 만들 때 문서는 제외하고 소스코드만을 포함하는 경우입니다.

3) Rule

8번 항목을 보면 대부분의 회사가 메시지 작성 규칙이 없음을 알 수 있습니다.즉, 개발자들이 알아서 메시지를 남기거나 안남기기도 한다는 것이죠. 실제로 많은 회사들의 경우를 보면 소스코드관리시스템의 History가 거의 쓸모 없는 경우가 대부분입니다. 단순히 소스코드 저장소 역할만 하는 것이죠.

9번은 버그관리시스템과 연동이 되는지 보는 것인데, 8번과 같은 비율이 나온 것은 좀 이상하네요. 8번은 그야말로 기본적인 항목이고, 9번은 좀더 성숙도가 높은 항목인데요. 어쨋든, 소스코드관리시스템과 버그관리시스템은 서로 연동을 하면 개발 생산성을 높일 수 있습니다. 그리고, 버그ID가 없이 소스코드를 임의로 수정하는 일을 막을 수 있습니다. 시스템에서 버그 ID가 없으면 소스코드를 수정할 수 없도록 막을 수도 있습니다.

10번 항목은 소스코드가 항상 빌드가 가능한 상태를 유지하는지에 대한 질문입니다. 나름대로 회사들이 Broken tree를 방지하기 위해서 노력하고 있네요.

4) Review

이번 리뷰에 대한 조사 결과는 기대보다 대단히 낮은 것을 볼 수 있습니다. 일단 리뷰를 거의 안하고, 소스코드를 등록할 때도 리뷰자를 남기는 경우가 별로 없네요. 즉, 리뷰의 대한 저변은 매우 낮은 것을 알 수 있습니다.

특이한 것은 Pair programming을 하는 회사가 11%나 되네요.

5) Build

자동으로 Daily Build를 하고 있는 회사는 29%에 불과했습니다.

개발자 중에는 매일 빌드를 한다고해서 Daily Build를 하는 것으로 착각하는 경우가 있는데, Daily Build는 자동화 되어서 매일 지정된 시간에 자동으로 빌드를 하는 것을 말합니다.

6) 응용

이 항목은 개발자들의 공동작업을 얼마나 효율적으로 소스코드관리시스템을 이용해서 유연하게 처리하고 있는지 조사한 것입니다.

일단 Branch를 사용하고 있는 회사는 꽤 많습니다.(40%) 이에 비해서 Branch를 승인받아야 한는 경우는 17%에 불과합니다. 개발자들이 Branch를 아무 때나 만들 수 있다면 자칫 Branch가 관리가 안될 수도 있습니다.

소스코드를 Merge하는 회사는 60%정도이고 이중에서 아직도 상당히 많은 회사가 2-way merge나 눈을 이용해서 수동으로 Merge를 하고 있는 것으로 알 수 있습니다.

3-way merge툴을 아는 개발자가 40%나 되지만 그 활용도는 대단히 떨어집니다.(23%)

즉, 안다고 제대로 활용할 수 있는 것은 아니네요.

7) 백업

소스코드관리시스템은 꼭 백업을 받아야 합니다. 그런데, 약 60%만이 백업을 받고 있고 그중에서 안전한 장소에 백업을 보관하고 있는 회사는 훨씬 더 적습니다. (26%)

총평)

소스코드관리시스템 사용에 대한 성숙도를 따져보면 평균적으로 초,중급 정도의 사용도를 보이고 있습니다. 하지만, 이는 제가 실제로 접하는 여러 회사들이 평균보다도 높은 수치입니다. 그 원인이 블로그의 방문자들의 수준이 더 높던가, 얼굴을 보지 않고 이루어지는 투표라서 더 관대하게 투표를 했다고 생각합니다. 그렇다고 하더라도 아직 소스코드관리시스템의 활용도는 대단히 낮은 상태라고 볼 수 있습니다. 물론 소스코드관리시스템을 쓰지조차 않는 조직과 비교하면 상대적으로 낫겠지만, 개선할 점이 많습니다. Allofsoftware 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.

다시한번 설문에 응해주신 모든 분께 감사드립니다.

'기반시스템 > 소스코드관리' 카테고리의 다른 글

이 소스코드는 나 밖에 못 건드려! (10)	2009/07/19
누가 소스코드를 몰래 바꿔놨다. (0)	2009/07/13
소스코드관리 상세 조사 결과 리포트 (6)	2009/03/08
사라진 소스코드 (4)	2009/02/28
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)	2009/02/25
소스코드 관리 방법 조사 결과 (8)	2009/02/22

Ray.전규현 기반시스템/소스코드관리 Configuration, 소스코드관리

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/95

헝그리맨

2009/03/09 08:15

Reply | Edit

예상대로 코드리뷰에 대한 결과는 저조하군요. 흠...
Ray.전규현

2009/03/09 10:31

Reply | Edit

헝그리맨님 안녕하세요.
코드리뷰는 가장 정착시키기 어려운 개발문화 중의 하나입니다. 실리콘밸리에서도 귀찮기는 마찬가지이지만, 규칙으로 정해 놓고 누구나 따릅니다.
[1002]

2009/03/09 09:44

Reply | Edit

3번 Rule 에서 8,9번 항목의 경우 처음 질문 때 의도가 명확치 않으면 구분해서 쓰지 않고 중복 체크를 할 것 같습니다만.
그리고 버그트래커-버전관리툴 이 연동된 시스템을 쓰는 개발자 입장에선 버그 번호를 쓰는게 더 쉽습니다. 아무 설명도 안쓰고 버그 번호만 쓰면 되거든요. (상세 내용은 어차피 버그트래커에서 계속 덧글로 달리므로. 그리고 버그 트래커와 버그 번호 연동되는 시스템인 경우 버그 번호만 룰에 맞춰 남기는게 훨씬 보기에도 좋고 추적성 면에서도 좋습니다. 그리고 SVN Log 로 쓸 수 있는 텍스트 양은 한계가 있습니다. 차라리 별도 문서를 남기죠)
3 way merge 의 경우.. 툴 자체가 편하긴 하나, 자동 테스트가 구축되고 커밋 빈도가 높은 곳의 경우 그냥 눈으로 비교하는 것으로도 충분합니다. (한 changeset 당 코드 변화량이 적은 경우) changeset 당 코드 변화량과 conflict 단위가 큰 경우 툴의 편의성 문제로 보기보다는 그렇게 conflict 단위가 크게 가는 상황 자체가 문제일지도 모르죠.
그리고 질문이 있다면.. '팀/프로젝트 규모 대비 필요한 만큼의 성숙도' 의 기준이 정해진 것이 있는지 궁금합니다.
Ray.전규현

2009/03/09 10:40

Reply | Edit

좋은 의견 감사합니다.
8,9번 항목의 경우 실제로 그렇게 하고 있는 개발자라면 다 이해를 할 것입니다. 제대로 하고 있는 곳이라면 8,9번을 다 체크하겠지요.
머지는 팀이 커질수록 머지에 많은 노력이 들어가는데, 눈으로 비교해서 머지하는 것은 시간도 많이 걸리고 실수의 가능성도 크다고 생가가합니다. 팀이 커지고 동시에 많은 사람들이 소스코드를 중복해서 수정하더라도 Conflict가 가능하면 적게 생기도록 하는 것이 좋습니다. 이런 경험이 쌓이면 자연스럽게 어떻게 해야 Conflict가 적게 생기는지 요령이 생깁니다.
3,4명의 개발자들이 동시에 개발하는 팀에서는 어떻게 해도 큰 문제가 되지는 않습니다. 개발팀이 커질 수록 신경을 써야겠지요.
제가 소프트웨어공학 컨설팅을 하기 때문에 '팀/프로젝트 규모 대비 필요함 만큼의 성숙도'에 대한 기준은 가지고 있습니다. 하지만 많은 회사들이 그 기준에 미치지 못하고, 발생하는 수많은 문제를 피해 다님으로서 스스로의 생산성과 역량을 떨어뜨리는 결과를 가져오고 있습니다. 팀의 규모와 역량에 알맞은 규칙과 툴을 적절하게 이용하면 훨씬 더 생산성을 높일 수 있는데, 심지어는 자신만의 세계에 갇혀서 이러한 변화를 거부하는 개발자도 많답니다.
한인철

2009/03/11 11:52

Reply | Edit

안녕하셔요?
이제는 개발자에서는 조금 멀어진 애 늙은이 입니다.^^
제가 종사하는 분야에서는 아직도 주먹구구식으로 개발이 이루어지고 있습니다.
후배들에게는 체계가 갖추어진 환경을 물려주기 위해 공부 중입니다.

그런데, 코드리뷰는 어떻게 해야 하나요?
막연한 질문이지만, 간단히 설명 부탁드립니다.
혹시, 좋은 무료도구가 있을까요?
집필하신 책을 주문했는데, 그 안에 답이 있을까요?

그리고, 버그추적시스템을 소개와 비교 부탁드립니다.

감사합니다.
Ray.전규현

2009/03/11 13:40

Reply | Edit

한인철님 안녕하세요.
코드리뷰는 가장 필요하면서도 매우 정착시키기 어려운 개발문화입니다. 코드리뷰는 종류가 여러가지고 있고, 개발 조직에 따라서 알맞은 방법을 써야 하며 제도적으로, 시스템적으로 뒷받침이 필요합니다. 여러 도구가 있기는 하지만 당장 도구가 없어서 코드리뷰를 못하는 것은 아닙니다. 일단 시작하는 것이 중요하고 시작하기 위한 기본적인 지식은 갖춰야죠. 좀더 구체적인 것이 필요하면 연락주세요.

그리고 버그추적시스템은 제 책에도 소개가 되어 있고, 현재 투표가 진행중인데, 투표가 끝나면 글을 올릴 예정입니다.

감사합니다.

몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다.

2009/03/05 21:57

'기반시스템' 카테고리의 다른 글

몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다. (0)	2009/03/05
깨끗한 개발 환경, 빌드 환경, 테스트 환경 (6)	2009/02/05
서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System) (11)	2009/02/03
이클립스 프로젝트 필수 유틸리티 개정판 : Subversion, Ant, JUnit, Trac (2)	2009/01/28
우리 개발자는 뭐든 뚝딱 잘 만들어요. (0)	2008/12/08
기반시스템(Infrastructure System)을 사용하고 계신가요? (4)	2008/11/05

Ray.전규현 기반시스템 opensource

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/94

사라진 소스코드

2009/02/28 10:59

4 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

바이너리는 있는데 소스코드는 없어서 낭패를 보신 적은 없으신가요?

소스코드 백업은 흔히 소홀히 하기 쉽습니다.

사고가 발생한 후에야 문제가 되고, 사고가 그렇게 자주 발생하는 것은 아니죠.

자주 발생하지는 않지만, 일단 발생하는 타격이 아주 큽니다.

일상 생활에서는 보험을 들지만, 소프트웨어를 개발하는 현장에서는 보험을 드는 격인 백업을 제대로 하는 경우는 흔히 보기 어렵습니다.

소스코드는 이러한 경우에 흔히 사라지거나 깨지게 됩니다.

이 때 백업이 없으면 낭패가 됩니다.

HDD는 그리 드물지 않게 깨집니다. 그냥 운영 중에 HDD가 깨져버리는 경험은 많이들 있을 겁니다.
장비를 사무실 내에서 옮기거나, 회사가 이사를 갈 때는 HDD가 깨지는 경우가 더 흔합니다.
컴퓨터바이러스 등의 악성 코드에 의해서 데이터가 파손되거나 시스템이 망가질 수 있습니다.
번개나 전기 공사중의 시스템에 과도한 전류 등의 문제로 시스템이 망가지는 경우
화재, 지진, 홍수 등의 재난으로 시스템이 완전히 망가질 수 있습니다.
시스템이나 HDD를 도난 당할 수 있습니다.
개발자가 개발을 하다가 실수로 소스코드 전체 혹은 일부 파일을 삭제할 수 있습니다.
여러 개발자가 파일서버에서 동시에 개발을 하다가 실수로 다른 개발자가 개발해 놓은 내용을 무시하고 싹 Overwrite를 해버릴 수 있습니다.

그래서 소스코드를 백업을 받아야 하는데, 아래와 같이 불완전하게 백업을 받으면 완벽한 보험장치가 될 수 없습니다.

소스코드를 보관하고 있는 시스템을 RAID로만 구성하고 별도로 백업 받지 않음
소스코드가 보관되어 있는 시스템의 다른 디렉터리에 파일을 복사해서 백업
사내의 다른 시스템에 미러링 또는 정기적으로 복사
소스코드는 소스코드관리시스템에 있지만, 또한 각 개발자들의 PC에도 일부 또는 전체가 있어서 소스코드관리시스템이 망가져도 어딘가에는 소스코드가 있다.
주기적으로 DVD로 백업을 받아서 사내에 보관
사내에 소스코드는 팀 별로 여러 시스템에 보관이 되어 있는데, 팀 별로 알아서 스스로 백업을 받는다.

위의 경우 대부분의 사고에도 소스코드를 복구할 수 있겠지만, 화재가 발생 한다면 백업 받아 놓은 DVD도 같이 싹 타버릴 것입니다. 실제로 911테러나 고베 대지진 때 수많은 회사들이 백업 데이터가 없어서 문을 닫은 경험들이 있습니다. 이런 큰 사건이 아니라고 하더라도 화재 등의 사건은 발생할 수 있고, 회사는 화재에 대한 보험을 거의 다들 들고 있습니다. 하지만, 그런 화재보험이 소스코드를 복구 시켜 주지는 않습니다. 대부분의 회사가 화재를 경험하는 일은 평생 없겠지만, 누군가는 겪게 되고, 화재 뿐만 아니라도, 서두에서 언급했던, 백업이 필요한 수많은 경험들은 한번씩은 해봤을 겁니다.

그래서 백업은 아래와 같이 3단계로 이루어져야 합니다.

기본적으로 소스코드관리시스템을 사용한다는 전제하에 설명을 하겠습니다. 그래야, 최종 소스뿐만 아니라 소스코드 History도 모두 보관을 할 수 있습니다. 아래 활동은 개발팀마다 각각 수행하면 안되고, 회사가 아무리 커도 전체소스코드를 한군데서 관리를 하며 백업도 한번에 받아야 합니다.

소스코드관리시스템은 RAID를 구성하거나 실시간 미러링 시스템을 만들어서 시스템 장애 시 항상 복구가 가능해야 합니다. 이는 시스템이 항상 작동하도록 해줍니다.
소스코드관리시스템은 하루에 한번 DVD등의 미디어에 Incremental 백업을 받아야 합니다. 그리고 백업 받은 DVD는 사내에 보관합니다. Incremental 백업은 크기가 크지 않으므로 그리 오래 걸래지 않습니다. 이는 시스템이 망가져도 적어도 24시간 이전의 소스코드로 돌아갈 수 있도록 해줍니다.
소스코드관리시스템은 일주일에 한번 DVD로 Full 백업을 받아서 회사 외부의 안전 장소에 보관을 해야 합니다. 안전한 장소는 은행의 안전금고 등이 될 수 있습니다. 이는 회사가 완전히 불타서 없어져도, 적어도 일주일 전의 소스코드로 완전히 복구를 해줍니다.

소스코드를 안전하게 백업을 받았다가 불의의 사고 시 복구를 한다고 해도, 소스코드를 가지고 제품을 만들어 내는데 일주일 또는 수주가 걸린다고 하면 안됩니다. 백업의 목표는 소스코드 복구 후 24시간 안에 원래 제품을 그대로 만들어 낼 수 있어야 합니다. 그러기 위해서는 정확한 개발환경, 빌드환경, 테스트환경 정보가 문서에 기록이 되어서 소스코드관리시스템에 같이 보관이 되어 있어야 하고, 빌드는 완전히 자동화 되어서 빌드환경 구성 후 빌드 스크립트만 실행하면 제품이 만들어지도록 준비가 되어야 합니다.

이 정도가 되어야 제대로 된 백업을 받고 있다고 할 수 있습니다.

뭐, 백업을 이정도까지 완벽하게 받는냐?라고 반문하시는 분이 계실지 모릅니다.

그런 분이 질병 보험을 들면서, 한달에 보험료를 3만원만 내면, 감기, 골절 등 대부분의 질병은 다 보장이 되는데, 암 등의 죽을 수 있는 병은 보장이 안된다고 하면 어떻게 생각하시겠습니까?

또, 죽을 병이 보장이 되려면 보험료를 4만원을 내야 한다고 하면 어떻게 하시겠습니까? 나는 절대 암에 걸리지 않을 거야 하고 3만원만 내시겠습니까? 아니면 암에 꼭 걸릴 것을 예상하고 4만원을 내십니까?

대부분은 암에 절대로 걸리지 않을 것이라고 생각하면서도 일단 암에 걸리면 타격이 크니, 4만원을 보험료로 내는 선택을 할 겁니다.

백업도 마찬가지입니다. 절대로 화재나 지진등의 사고는 발생하지 않을 것이지만, 대비를하는 것입니다. 그 대비 비용이 사고 발생 후의 피해 보다는 훨씬 작기 때문입니다.

보험료를 지불한 만큼 보장을 받는 것입니다.

'기반시스템 > 소스코드관리' 카테고리의 다른 글

누가 소스코드를 몰래 바꿔놨다. (0)	2009/07/13
소스코드관리 상세 조사 결과 리포트 (6)	2009/03/08
사라진 소스코드 (4)	2009/02/28
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)	2009/02/25
소스코드 관리 방법 조사 결과 (8)	2009/02/22
VSS, CVS, SVN 비교 (12)	2009/01/08

Ray.전규현 기반시스템/소스코드관리 백업, 빌드자동화, 소스코드관리

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/91

아리새의펜촉

2009/03/01 01:30

Reply | Edit

예전에 만든 프로그램에서 버그가 발견되었지만, 소스파일을 날려버려서 새로 만든 적이 있습니다. 그 이후로 항상 웹과 USB, HDD에 삼중보관을 하고 있죠. 그런데 솔직히 위의 방법은 지나친 감이 있네요. 회사 차원에서 별도의 백업팀이 있으면 할만할지 모르겠지만 개인에게는 어려울 것 같습니다.
Ray.전규현

2009/03/01 11:00

Reply | Edit

아리새의 펜촉님 안녕하세요.
누구나 자신에게는 큰 사고가 일어난다고 생각하지 않습니다. 경험하신 일은 소스코드를 날려버리신 일인데, 보통 자신이 경험한 일 정도만 대응을 합니다.
위와같이 3단계로 백업을 하려면 백업팀은 아니고 백업담당자는 필요합니다. 대부분의 백업은 자동화를 하고, 주간백업정도는 수동으로 해야할 일이 있습니다. 백업담당자는 자신의 일중에서 10~20%정도는 백업을 해야합니다.
위와 같이 3중보관을 하고 계신다면 99.9%의 사고에는 완전할 수 있습니다. 0.1%의 사고까지 방지를 할지는 비용대비 효과를 생각해서 스스로 판단해야 할 일입니다. 작은회사들이 그렇게 투자하는 일은 흔하지 않습니다.
하지만 회사의 규모가 커질수록 큰 사고에 대해서 생각하지 않을 수 없습니다.
하루

2009/03/03 13:36

Reply | Edit

svn과 같은 형상관리를 적용해 보시는 것은 어떨까요?
Ray.전규현

2009/03/03 22:03

Reply | Edit

하루님 안녕하세요.
형상관리를 적용하는 것은 기본이죠. 위의 모든 얘기도 형상관리를 적용한 다음의 얘기입니다. 단, 저는 형상관리라는 말은 잘 사용안합니다. 가능하면 소스코드관리라고 얘기합니다. SVN을 백업받는 얘기라고 생각하시면 됩니다. ^^

Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

2009/02/25 00:19

18 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

소프트웨어를 개발하다 보면 소스코드의 브랜치가 일어나고 이를 Merge(머지)하는 일은 피하기가 어렵습니다.

이 Merge(머지)과정을 자동화 툴을 이용하면 상당히 많은 시간을 절약할 수 있습니다.

특히 Merge의 자동화를 위해서는 3way-Merge가 필수적인데, 시중에서 3way머지가 지원된다고 하는 툴 4가지와 SVN에서 지원하는 Unified diff, 이렇게 총 5가지를 비교해봤습니다.

그 결과는 아래와 같이 평가를 하였습니다. KDiff3, P4Merge와 Araxis Merge가 우수하게 나왔습니다.

총점

비교 데이터

비교 방법은 일부러 Conflict가 일어나는 상황을 만들어서 각 Merge툴이 얼마나 손쉽게 Conflict를 해결하는지 비교하였습니다.

제가 분석을 위해서 사용한 파일은 다음과 같습니다.

위에서 자동으로 Merge가 가능한 부분은 노란색으로 칠했고, Conflict가 나는 부분은 보라색으로 칠했습니다.

이렇게 Conflict를 일으켜서 SVN에서 자동 Merge를 실패하게 한 후에 각각의 Merge툴로 비교를 해 봤습니다.

실행

KDiff3와 Araxis Merge는 Conflict가 났을 때 SVN에 떨궈주는 파일 3개를 선택해서 쉽게 해당 툴을 실행할 수 있습니다. 그래서 Merge하는 시간을 절약할 수 있습니다.

KDiff3

Araxis Merge

비교 화면

비교는 Orginal File(Base)과 Trunk File(Working)과 Branch File 3개를 비교했습니다.

그 화면은 다음과 같습니다. 이미지를 클릭하면 큰 이미지를 볼 수 있습니다.

언뜻 보기에는 각각의 화면이 크게 차이가 나지 않는 것처럼 보입니다. 각 툴마다 다른 부분, Conflict가 나는 부분을 다른 방법으로 표시를 하고 있습니다. KDiff3는 한글이 깔끔하게 나오는 것이 눈에 좀 거슬리지만, 기능에는 문제가 없습니다.

비교 화면에서는 Araxis Merge가 가장 직관적이고 깔끔한 화면을 보여줍니다.

KDiff3

P4Merge

Araxis Merge

Beyond Compare

Ultra Compare

Merge시 Conflict를 알려주는 다이얼로그

KDiff3와 Araxis Merge는 의미있는 Conflict 정보를 Merge시 알려줍니다. 둘다 자동 Merge를 하면서 Conflict가 난 2건을 표시해 줍니다.

P4Merge는 가장 직관적인 화면을 보여주며 마찬가지로 Conflict 2건을 표시합니다.

KDiff3

P4Merge

Araxis Merge

Merge 화면

Merge를 실행하게 되면 KDiff3, P4Merge와 Beyond Compare는 원래 파일 3개는 그대로 두고 새로운 Merge파일 창이 새로 생깁니다. 하지만, Araxis Merge와 Ultra Compare는 기존의 파일을 수정하도록 되어 있네요.

P4Merge가 가장 직관적입니다.

KDiff3

P4Merge

Araxis Merge

Beyond Compare

Ultra Compare

Conflict 해결

Conflict는 각각 어떻게 해결을 할 수 이나 비교를 해 봤습니다.

KDiff3 - Merge화면에서 Conflict가 난 줄은 <Merge Conflict>라고 표시가 됩니다. 원래 비교 대상인 3개의 파일 중에서 하나를 마우스나 키보드를 이용해서 선택할 수 있습니다.

P4Merge - Merge창에서 Conflict가 난 부분은 붉은 표시가 되어 있습니다. 오른쪽에 있는 버튼을 클릭해서 원하는 부분은 클릭하면 쉽게 Conflict가 해결됩니다.

Araxis Merge - Conflict가 난 줄들은 줄 앞에 빨간 동그라미가 나옵니다. 해당 줄에서 >>, << 버튼을 이용해서 선택을 하면 됩니다.

Beyond Compare - Conflict가 일어난 줄은 붉은 바탕으로 표시가 됩니다. 이 줄에서 마우스 버튼을 이용해서 원하는 파일을 선택하면 적용이 됩니다. 테스트 시 라인 단위로 정교하게 선택이 안되고 뭉쳐서 선택이 되는 바람에 원하는대로 Merge를 하는데 시간이 좀 걸렸습니다.

Ultra Compare - Conflict는 표시가 안됩니다. 그냥 서로 다른 줄을 찾아서 ->, <-버튼을 이용해서 선택하면 됩니다. 자동 Merge가 안되서 수동으로 일일이 선택을 해줘야 합니다.

Unicode 지원

KDiff3 - Unicode를 지원하나 Auto detact가 잘 안되네요.

P4Merge - Unicode를 완벽하게 지원합니다.

Araxis Merge - 지원한다고 하는데, View에서 깨져 보임, Merge는 됨

Beyond Compare - View, Merge 모두 지원

Ultra Compare - View, Merge 모두 지원

총평

기능면에서는 약간 부족함은 있으나, 기본적인 Merge기능에 충실하고 가격이 무료인 KDiff3와 모든 기능이 우수하지만 가격이 좀 부담스러운 Araxis Merge에 높은 점수를 주었습니다.

그리고 P4Merge는 Merge 기능이 가장 직관적인고 편리합니다.

실제로 Merge결과 원하는 결과대로 바로 Merge가 되면서 Conflict를 몇 초만에 해결할 수 있었던 것은 KDiff3, P4Merge와 Araxis Merge밖에 없었습니다.

Branch와 Merge가 빈번하고 회사에 경제적인 여유가 된다면 Araxis Merge가 적당할 것 같고, 그렇지 않은 경우라면 다른 유료 툴보다도 KDiff3와 P4Merge가 좋을 것으로 생각합니다.

'기반시스템 > 소스코드관리' 카테고리의 다른 글

소스코드관리 상세 조사 결과 리포트 (6)	2009/03/08
사라진 소스코드 (4)	2009/02/28
Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18)	2009/02/25
소스코드 관리 방법 조사 결과 (8)	2009/02/22
VSS, CVS, SVN 비교 (12)	2009/01/08
하루에 몇 번 커밋하세요? (22)	2009/01/07

Ray.전규현 기반시스템/소스코드관리

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/90

영회

2009/02/25 01:04

Reply | Edit

KDiff3는 무료인데 최고점이군요.
Ray.전규현

2009/02/25 07:38

Reply | Edit

안녕하세요. 영회님
3way-merge 기능을 위주로 비교했기 때문입니다. 그리고 Araxis Merge가 기능이 더 좋기는 하지만, 가격 점수 때문에 그렇게 평가를 했습니다.
헝그리맨

2009/02/25 08:11

Reply | Edit

유용한 글 고맙습니다.
SVN의 Unified Diff 는 TortoiseDiff 와 같은 것인지요?
Ray.전규현

2009/02/25 09:53

Reply | Edit

헝그리맨님 안녕하세요.
Unified Diff는 Text포맷으로 Merge를 할 수 있는 하나의 Format입니다. SVN과 TortoiseSVN에서 기본적으로 제공합니다. GUI가 불편하므로 GUI가 편리한 다른 툴들을 사용하는 것이고요.
창천

2009/02/25 09:06

Reply | Edit

저는 보통 단순히 2개의 파일비교를 위해 winmerge를 사용하는데
3-way merge 라는 것과 새로운 툴들 정보 잘 봤습니다.^^
Ray.전규현

2009/02/25 09:54

Reply | Edit

창천님 안녕하세요.
Winmerge같은 2way merge의 한계는 모든 것이 수동이라는 것이지요.
뽕삼이

2009/02/25 09:44

Reply | Edit

언제나 유익한글 감사드립니다. 최근에 가장 자주오게되는 블로그네요.^^ 저도 현재 급한 프로젝트때문에 ClearCase를 사용하는 회사임에도 너무나 자주바뀌는 코드로인해 WinMerge를 통하여 급 머지를 하고있습니다.-_- 머지에 대해서 좀 자세하게 알고싶은데요.. 왜 3 way merge가 필수인가요? 아직 3 way merge에 대한 개념이 잘없네요. Tunk,와 Branch의 개념도 알고싶습니다. 감사합니다
Ray.전규현

2009/02/25 10:24

Reply | Edit

뽕삼님 안녕하세요.
http://allofsoftware.net/entry/Release-Branch-Function-Branch-and-Customer-Branch 과 http://allofsoftware.net/entry/diffandmerge 를 읽어보세요. 더 궁금한 것이 있으면, Email을 보내주세요.
popopome

2009/02/25 10:04

Reply | Edit

Perforce의 P4Merge도 무로이면서 좋은 3-way merge tool중에 하나라고 생각됩니다.
http://www.perforce.com/perforce/products/merge.html
Ray.전규현

2009/02/25 10:26

Reply | Edit

popopome님 안녕하세요.
P4Merge가 빠졌군요. 이것도 Evaluation에 추가를 할까 합니다. 감사합니다.
정의의소

2009/02/25 12:08

Reply | Edit

좋은 내용 감사합니다. 최근 반년간 거의 excel로만 작업을 했더니 코딩이 가물 가물 거리는 군요... ^^:
Ray.전규현

2009/02/25 14:33

Reply | Edit

정의의소님 안녕하세요.
경력이 쌓일 수록 코딩일은 점점 줄어들더군요. 그래도 코딩은 언제나 재미있죠. ^^
kkurrung

2009/03/18 08:30

Reply | Edit

p4 merge툴 자체는 무료라고 하는데.. 가격이 ㄷㄷㄷ..
http://perforce.com/perforce/products/merge.html
Ray.전규현

2009/03/18 15:47

Reply | Edit

안녕하세요. kkurrung님 블로그에 오류가 있네요. 지금 다시 확인해보니, Perfoce Merge는 무료네요. 제가 적어 놓은 것은 서버의 가격이네요. 수정하도록 하겠습니다. 지적해주셔서 감사합니다.
머샤머샤

2009/03/27 01:52

Reply | Edit

국산 3 Way Merge 도구도 있습니다. (물론 우리팀이 만들고 있고, 상용입니다.
http://www.snh.co.kr/?s=product&m=shape4 여기에서 평가판을 받으실수 있습니다.

물론, 우리팀은 Merge Tool만을 전문적으로 만들지 않고, 형상관리에 관련된 전반적인것을 함께 개발하고 있기때문에, 총력을 다하고 있지만 못합니다만. 국산제품도 있다는 점을 알려드리고 싶어요...
Ray.전규현

2009/03/27 21:51

Reply | Edit

머샤머샤님 안녕하세요.
개발을 하시면서 소스코드관리시스템은 물론 실루엣을 쓰시겠죠? ^^ 이런류의 질문들이 항상 궁금했습니다. ㅎㅎ 나중에 기회가 되면 같이 검토를 해봐야겠네요.
구차니

2009/04/28 13:30

Reply | Edit

araxis가 좋긴한데.. syntax highlight가 안되서 간간히 winmerge를 사용하고 있습니다만
디렉토리 비교 측면에서는 araxis가 좋더군요. 3way까지 잘 쓰질 않아서 유용한지는 잘 모르겠습니다 ^^;
Ray.전규현

2009/04/28 16:28

Reply | Edit

구차니님 안녕하세요.
3-way merge를 사용하지 않을 거면 winmerge로 충분하죠. 소프트웨어를 개발하다보면, 브랜치, 머지, 롤백 등 수많은 상황에서 3-way merge는 이런 활동을 몇배 편하게 해줍니다. 3-way merge도 익숙해질 필요가 있습니다.

Build Script를 C언어로 작성하기

2009/02/24 00:13

2 Comments

All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.

RSS Feed

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

'기반시스템 > 빌드/릴리즈' 카테고리의 다른 글

한방에 빌드 (2)	2009/08/06
Build Script를 C언어로 작성하기 (2)	2009/02/24
Daily Build를 하십니까? (0)	2009/02/04
빌드와 컴파일의 차이 (6)	2008/11/14
빌드가 먼저일까? 베이스라인 설정이 먼저일까? (8)	2008/11/12
Broken tree (0)	2008/11/12

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

Leave a Commnet Leave a Trackback

Trackback Address: http://allofsoftware.net/trackback/89

Eminency

2009/02/24 02:25

Reply | Edit

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

2009/02/24 09:30

Reply | Edit

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