SVN Branch Tagging 전략

양완수

未讀,

2010年6月4日凌晨12:06:222010/6/4

收件者：Agile Beginners' Q&A

안녕하세요 양완수라고 합니다.

이곳에 적합한 글인지 모르겠습니다.

SVN 을 도입한지 오랜 시간이 지났지만 그다지 소스 관리에 대한 복잡성이 좋아지지 않았습니다.
그 이유가 나름 진단하기로 Branch 와 Tagging 전략에 부재 라 고 생각했습니다.
즉 trunk(사실 새로운 프로젝트가 생길 때마다 브랜치를 Header 를 통해 따고 있습니다. )에서 Error 수정,추가
개발 하다 보니 이전 zip 파일을 사용해 통째로 묶던 때와 시간이 가면 갈 수록 별반 다르지않네요...

적절한 시기에 Branch를 따고 trunk에 merge 하고 해야 한다는 것은 알겠습니다.

이런 적절한 사례나 가이드를 찾아 보았지만 그다지 속시원한 내용이 없네요..

각 회사마다 SVN 을 사용하는 적략이 있다고 생각이 듭니다.
좋은 가이드나 사례 (실패사례도 좋습니다.) 에 대한 가르침 부탁드립니다.

그리고 최종적으로 CI 를 위해서 SVN을 초기발판으로 이용하고 있는 회사로써
빌드서버 도입하신 도입스토리가 있다면 이또한 부탁드립니다.

여기까지 읽어 주셔서 감사합니다.

GyehongPark

未讀,

2010年6月4日晚上11:01:452010/6/4

收件者：Agile Beginners' Q&A

저 같은 경우는 branch를 사용해야 하는 경우에도 일부 코드를 주석으로 했다가, 풀었다가 하면서 하는 경우가 많았던듯 하네
요. 불편함에도 불구하고 그러는 이유는...... 생각해 보니 branch에 약간의 거부감이 있는듯 하네요. 그렇다고 merge
에 거부감이 있는 것은 아닙니다. merge와 그에 따른 충돌은 branch가 아니어도 많이 있으니까요. 저는 보통 commit
을 자주 하는 편입니다. 아마 여러개의 충돌에 대해서 조금 불편한 마음이 있는듯 하네요.

tagging은 제품 릴리즈 정도? svn에서는 tagging이 크게 의미가 있다고 보여지지는 않습니다. 주석을 잘 달면되
죠.

저도 branch나 tagging 을 잘 사용하시는 팀은 어떻게 사용하는지 궁금하네요.

그렇지만, 사용하지 않는다고 해서 왜 소스관리가 엉망이 되고 있다는 생각하셨는지는 궁금합니다. svn으로 작업을 할 때, 어떤
문제가 있었는지 같은 것들을 이야기해주시면 도움이 될듯 합니다.

저도 그렇지만, 많은 분들이 아주 기본적인 기능만 쓰기도 하니까요. 모두 좋은 주말되세요~ ^^*

wansu yang

未讀,

2010年6月5日晚上11:23:102010/6/5

收件者：ab...@googlegroups.com

저희 상황은 이렇습니다.

하나의 웹 프로젝트를 SVN 으로 버전관리를 시작한 후 프로젝트가 시작 할 때 기 많들어 져있던 프로젝트를 그래로 브랜치를 땁니다.

그 후 다른 프로젝트가 생기면 이전 생성된 브랜치에서 jsp,js,java 등등의 파일을 고치고 다시 브랜치를 땁니다.

이렇게 하다보니 하나의 브랜치가 여때 해왔던 프로젝트에 합집합에 되어서 새로들어오는 작업자들이 현 프로젝트에서 중요한것과 쓰이지않는 부분을 파악해야하는 불필요한 작업이 생겼습니다.

2010년 6월 5일 오후 12:01, GyehongPark <gyeho...@gmail.com>님의 말:

--
Google 그룹스 'Agile Beginners' Q&A' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ab...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 abqna+un...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.

--
===========================================================

안녕하세요! 양완수 입니다.
+HP : 010 2008 4167
+Email : ywsa...@gmail.com , yang...@daumsoft.com
+
===========================================================

GyehongPark

未讀,

2010年6月6日凌晨12:51:512010/6/6

收件者：Agile Beginners' Q&A

알려주신 상황으로 보면... 브랜치가 아니라 여러 개의 프로젝트를 하나의 svn에서 관리하는 것처럼 보이네요.
A, A', A'' 이런 별도의 프로젝트가 공통 부분이 있다보니 하나의 svn으로.....

그냥 별도의 프로젝트로 분리하는 것이 좋다고 생각합니다.

그러면서 코드 리뷰와 리팩토리을 통해서 불필요한 소스를 삭제 해야할듯. 그리고 이것은 결국 틈틈히 해야할듯. 시간을 별도의 시간
을 얻기는 힘드니. 특히 프로젝트마다 사람이 달라지는 경우 불필요한 소스의 유무를 알기 어렵습니다. 한참 시간이 흘러야죠. 비슷
한 코드도 여기 저기 생기게 되고.....

정말 공통 부분이 있다면 별도의 프로젝트로 빼 낼 수도 있을듯. 라이브러리화?. (하나의 프로젝트가 2개 이상의 svn 저장소
를 사용) 빌드등에 불편할 수 있으니가 이 부분은 빌드 서버 등으로 처리하는 것도 좋겠습니다.

정리.
새로운 프로젝트는 새로운 저장소로 관리한다.
꾸준히 코드 리뷰와 리팩토링을 통해서 불필요한 코드를 정리한다.
공통 부분은 별도의 프로젝트로 빼내는 것도 고려한다.(라이브러리화)

On 6월6일, 오후12시23분, wansu yang <ywsaa...@gmail.com> wrote:
> 저희 상황은 이렇습니다.
>
> 하나의 웹 프로젝트를 SVN 으로 버전관리를 시작한 후 프로젝트가 시작 할 때 기 많들어 져있던 프로젝트를 그래로 브랜치를 땁니다.
> 그 후 다른 프로젝트가 생기면 이전 생성된 브랜치에서 jsp,js,java 등등의 파일을 고치고 다시 브랜치를 땁니다.
> 이렇게 하다보니 하나의 브랜치가 여때 해왔던 프로젝트에 합집합에 되어서 새로들어오는 작업자들이 현 프로젝트에서 중요한것과 쓰이지않는
> 부분을 파악해야하는 불필요한 작업이 생겼습니다.
>

> 2010년 6월 5일 오후 12:01, GyehongPark <gyehongp...@gmail.com>님의 말:

> > 그룹에서 탈퇴하려면 abqna+un...@googlegroups.com<abqna%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.

>
> --
> ===========================================================
>
> 안녕하세요! 양완수 입니다.
> +HP : 010 2008 4167

> +Email : ywsaa...@gmail.com , yangwa...@daumsoft.com
> +
> ===========================================================

Joonhwan Lee

未讀,

2010年6月7日晚上8:08:512010/6/7

收件者：ab...@googlegroups.com

제가 있는 회사에서는

- 몇번에 나누어서 commit해야 하는 큰 규모의 변경사항인 경우
- 제품을 릴리즈할 때

만 branch를 만듭니다. branch는 거의 trunk에서 나가구요, 특별한 경우, branch에서 또 다른 branch로 가는 경우가 있습니다.(branch에 또 다른 branch를 시험적으로 합치는 경우)

tag의 경우 거의 쓰지 않습니다.

잘 사용하고 있는지는 모르겠지만, 그럭저럭 운용되고 있는 듯 합니다...

2010/6/6 GyehongPark <gyeho...@gmail.com>

그룹에서 탈퇴하려면 abqna+un...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.

--

Joon

wansu yang

未讀,

2010年6月9日凌晨1:37:142010/6/9

收件者：ab...@googlegroups.com

//주환님

"몇번에 나누어서 commit해야 하는 큰 규모의 변경사항인 경우 " 에 양적 기준은 어느정도인가요??
저에 경우에는 TAG 에 경우 readonly 권한을 주어 관리하려고 합니다.

//계홍님

말씀하신 부분이 각각에 repository 로 관리 할 경우 중복 되어 발생되어지는 코드는 별도에 repository를 생성해서 thirdparty 형식으로 가져다 쓰게 하는것이 맞는건가요?

이럴 경우 이미 진행된 부분이 많기 때문에 자주 코드 리뷰가 이루어져야 겠군요

2010년 6월 8일 오전 9:08, Joonhwan Lee <joonhw...@gmail.com>님의 말:

Joonhwan

未讀,

2010年6月10日凌晨1:20:162010/6/10

收件者：ab...@googlegroups.com

�� ̶�°� "��"�� 纸�ٴ� "��ڵ忡 �� Ʈ"�� ؼ��Ǿ�� ϴ�.
��, �� ƹ�� , �� ߰��Ǵ� ��̰ų�, ��ڵ�� �� ,
2ȸ �̻� Ŀ�� ʿ��ϴٰ� �ǴܵǸ�, �� 귣Ī �մϴ�.

��, �� ó�� "�귣ġ�ƿ��"�� Դ� �� ٴ�,
��ϴ� �� Ŀ��(��踦 �� ʰ� �ڵ�� ϴ� ��Դϴ�. ;( ),
, ��, "��.... �̰� �ѹ�� Ŀ��δ� �ȵǰڴµ�..." �� ǴܵǸ�, �귣ġ�ƿ��ϴ� ��찡 �� ֽ��ϴ�. ��ǰ�쿡��

TAG�� , readonly�� ϴ°�� ̶�� ϴ�. ��... �� ִ� �� ׳�
revision number�� tagó�� ϴ�. (��Ǵ� ��̳ʸ�� revision number�� ǥ�õǹǷ�...Ȯ�� ϴ�).

-�̻�-

2010-06-09 �� 2:37, wansu yang �� :

// ��ȯ��
" ��  commit�ؾ� �ϴ� ū �Ը�� " �� ΰ��??
�� 쿡�� TAG �� readonly �� ־� ��Ϸ�� մϴ�.

//��ȫ��

��Ͻ� �κ�� repository �� ߺ� �Ǿ� �߻�Ǿ�� ڵ�� repository�� ؼ� thirdparty �� ϴ°�� ´°ǰ��?

�̷� �� ̹� �� κ�� ڵ� ��䰡 �̷�� ڱ��

2010�� 6�� 8�� 9:08, Joonhwan Lee <joonhw...@gmail.com>�� :

�� ִ� ȸ�翡��

- ��  commit�ؾ� �ϴ� ū �Ը��
- ��ǰ��

�� branch�� ϴ�. branch�� trunk�� , Ư�� , branch�� ٸ� branch�� 찡 �ֽ��ϴ�.(branch�� ٸ� branch�� ġ�� )

tag�� ʽ��ϴ�.

�� ϰ� �ִ�� 𸣰��, �׷�� ǰ� �ִ� �� մϴ�...

2010/6/6 GyehongPark <gyeho...@gmail.com>

�� ֽ� ��Ȳ�� ... �귣ġ�� ƴ϶� �� Ʈ�� ϳ�� svn�� ϴ� ��ó�� ̳׿�.
A, A', A'' �̷� �� Ʈ�� κ�� ִٺ�� ϳ�� svn��.....

�׳� �� Ʈ�� и��ϴ� �� ٰ� ��մϴ�.

�׷��鼭 �ڵ� �� 丮�� ؼ� ��ʿ�� ҽ�� ؾ��ҵ�. �׸�� ̰�� ᱹ ƴƴ�� ؾ��ҵ�. �ð�� ð�
�� . Ư�� Ʈ�� ޶�� ʿ�� ҽ�� ˱� ��ƽ��ϴ�. �� ð�� 귯��. ��
�� ڵ嵵 �� ǰ�.....

�� κ�� ִٸ� �� Ʈ�� . ��̺귯��ȭ?. (�ϳ�� Ʈ�� 2�� ̻�� svn ��
�� ) �� �� ϰ� �� κ�� ó��ϴ� �͵� ��ڽ��ϴ�.

��.
��ο� ��Ʈ�� ο� ��ҷ� ��Ѵ�.
�� ڵ� �� 丵�� ؼ� ��ʿ�� ڵ带 ��Ѵ�.
�� κ�� Ʈ�� ͵� ��Ѵ�.(��̺귯��ȭ)

On 6��6��, ��12��23��, wansu yang <ywsaa...@gmail.com> wrote:
> �� Ȳ�� ̷��ϴ�.
>
> �ϳ�� Ʈ�� SVN �� Ʈ�� ִ� ��Ʈ�� ׷�� 귣ġ�� ϴ�.
> �� ٸ� ��Ʈ�� 귣ġ�� jsp,js,java �� ġ�� ٽ� �귣ġ�� ϴ�.
> �̷�� ϴٺ�� ϳ�� 귣ġ�� ؿԴ� ��Ʈ�� տ� �Ǿ ��ε�� ۾��ڵ�� Ʈ�� ߿��ѰͰ� ��ʴ�
> �κ�� ľ��ؾ��ϴ� ��ʿ�� ۾�� ϴ�.
>

> 2010�� 6�� 5�� 12:01, GyehongPark <gyehongp...@gmail.com> �� :

>
>
>
>
>
> > �� branch�� ؾ� �ϴ� ��쿡�� Ϻ� �ڵ带 �ּ�� ߴٰ�, Ǯ��ٰ� �ϸ鼭 �ϴ� ��찡 ��Ҵ�� ϳ�
> > ��. ��Կ�� ұ��ϰ� �׷�� ...... �� branch�� ణ�� źΰ�� ִµ� �ϳ׿�. �׷��ٰ� merge
> > �� źΰ�� ִ� �� ƴմϴ�. merge�� ׿� �� 浹�� branch�� ƴϾ �� ϱ��. �� commit
> > �� ϴ� ��Դϴ�. �Ƹ� �� 浹�� ؼ� �� ִµ� �ϳ׿�.
>
> > tagging�� ǰ �� ? svn�� tagging�� ũ�� ǹ̰� �ִٰ� �� ʽ��ϴ�. �ּ�� ޸��
> > ��.
>
> > �� branch�� tagging �� Ͻô� �� �� ϴ�� ñ��ϳ׿�.
>
> > �׷��, �� ʴ´ٰ� �ؼ� �� ҽ�� ǰ� �ִٴ� ��ϼ̴�� ñ��մϴ�. svn�� ۾�� , �
> > �� ־�� ͵�� ̾߱��ֽø� �� ɵ� �մϴ�.
>
> > �� ׷��, �� е�� ⺻�� ɸ� ��⵵ �ϴϱ��. �� ָ��Ǽ��~ ^^*
>
> > On 6��4��, ��1��06��, ��ϼ� <ywsaa...@gmail.com> wrote:
> > > �ȳ��ϼ�� ϼ�� մϴ�.
>
> > > �̰�� 𸣰ڽ��ϴ�.
>
> > > SVN �� ð�� ״�� ҽ� �� ⼺�� ʾҽ��ϴ�.
> > > �� ϱ�� Branch �� Tagging �� ߽��ϴ�.
> > > �� trunk(�� ο� ��Ʈ�� 귣ġ�� Header �� ֽ��ϴ�. )�� Error ��,�߰�
> > > �� ϴ� �� zip �� °�� ð�� ٸ��ʳ׿�...
>
> > > �� ñ⿡ Branch�� trunk�� merge �ϰ� �ؾ� �Ѵٴ� �� ˰ڽ��ϴ�.
>
> > > �̷� �� ʳ� ��̵带 ã�� ״�� ӽÿ�� ׿�..
>
> > > �� ȸ�縶�� SVN �� ϴ� �� ִٰ� �� ϴ�.
> > > �� ̵峪 �� (��л�ʵ� ��ϴ�.) �� ħ ��Ź�帳�ϴ�.
>
> > > �׸�� CI �� ؼ� SVN�� ʱ�� ̿��ϰ� �ִ� ȸ��ν�
> > > ��弭�� Ͻ� ��Խ��丮�� ִٸ� �̶�� Ź�帳�ϴ�.
>
> > > �� о� �ּż� ��մϴ�.
>
> > --
> > Google �׷콺 'Agile Beginners' Q&A' �׷쿡 ��Ƿ� �� ۵Ǿ��ϴ�.
> > �� ׷쿡 �Խ��Ϸ�� ab...@googlegroups.com(��) �� ̸�� .

> > �׷쿡�� Ż��Ϸ�� abqna+un...@googlegroups.com<abqna%2Bunsu...@googlegroups.com> ��
> > �̸�� ּ��.
> > �� ɼ�� http://groups.google.com/group/abqna?hl=ko�� ׷�� 湮�ϼ��.

>
> --
> ===========================================================
>
> �ȳ��ϼ��! ��ϼ� �Դϴ�.
> +HP : 010 2008 4167

> +Email : ywsaa...@gmail.com , yangwa...@daumsoft.com

> +
> ===========================================================

--
Google �׷콺 'Agile Beginners' Q&A' �׷쿡 ��Ƿ� �� ۵Ǿ��ϴ�.
�� ׷쿡 �Խ��Ϸ�� ab...@googlegroups.com(��) �� ̸�� .
�׷쿡�� Ż��Ϸ�� abqna+un...@googlegroups.com�� ̸�� ּ��.
�� ɼ�� http://groups.google.com/group/abqna?hl=ko�� ׷�� 湮�ϼ��.

--

Joon

--
Google �׷콺 'Agile Beginners' Q&A' �׷쿡 ��Ƿ� �� ۵Ǿ��ϴ�.
�� ׷쿡 �Խ��Ϸ�� ab...@googlegroups.com(��) �� ̸�� .
�׷쿡�� Ż��Ϸ�� abqna+un...@googlegroups.com�� ̸�� ּ��.
�� ɼ�� http://groups.google.com/group/abqna?hl=ko�� ׷�� 湮�ϼ��.

--
===========================================================

�ȳ��ϼ��! ��ϼ� �Դϴ�.

+HP : 010 2008 4167
+Email : ywsa...@gmail.com , yang...@daumsoft.com
+
===========================================================

--
Google �׷콺 'Agile Beginners' Q&A' �׷쿡 ��Ƿ� �� ۵Ǿ��ϴ�.
�� ׷쿡 �Խ��Ϸ�� ab...@googlegroups.com(��)�� ̸�� .
�׷쿡�� Ż��Ϸ�� abqna+un...@googlegroups.com�� ̸�� ּ��.
�� ɼ�� http://groups.google.com/group/abqna?hl=ko�� ׷�� 湮�ϼ��.

-- 
Joonhwan Lee
www.joonhwan.org

gyehong park

未讀,

2010年6月10日凌晨4:30:382010/6/10

收件者：ab...@googlegroups.com

맞다기 보다, 중복을 제거하다가 보면 자연스럽게 그렇게 되지 않을까요?

그리고 "저장소를 별도로 관리해야 하는가?"보다는 리팩토링을 하는 것이 중요해 보입니다.

A프로젝트 코드를 브랜치(복사)해서 B프로젝트에 사용하고, B프로젝트 코드를 브랜치(복사)해서 C프로젝트에 사용하고... 이런 형태의 코드는 비슷한 기능이 중복되는 경우가 많고, 사용하지 않지만 제거하지 않은 코드도 많습니다. 저도 이런 프로젝트를 경험해봤기 잘 압니다.

이런 소스코드는 저장소를 아무리 관리를 잘 한다고 해도 문제가 많이 있을 것입니다. 결국 리팩토링을 꾸준히 해 주는 것이 첫번째 단계라고 보여집니다. 그렇게 하다가 보면 저장소를 어떻게 관리해야 할지도 나오지 않을까요?

2010/6/9 wansu yang <ywsa...@gmail.com>

석한울

未讀,

2010年6月11日晚上8:53:372010/6/11

收件者：ab...@googlegroups.com

초보자라서 용기내어 답글을 달아 봅니다.

SVN Branch Tagging 은 무엇인가요??

음.. 글을 좀 읽어보니까 프로젝트를 진행하다가 여러가지 한군데서 사용하던 기능들을..

복사해다가 다른 프로젝트에서도 사용하고 그러다보면 같은 모듈이 여러가지 생기는 중복이 발생하는

경우를 말하시는것 같은데 맞나요??

음.. 저혼자 같은경우도 이것저것 만들다 보면 전혀 다른 프로젝트에서 사용하던 기능들이 필요해 지게되고

단순히 그걸 복사해서 기능을 조금 바꾸어서 사용하게 되는 경우가 많은데..

요즘에는 그런상황이 생기면 좀 돌아가더라도.. 둘다 리팩토링을 해 봅니다.

예가 적당한지는 모르겠지만.

Cars 프로젝트에 GasolinEngine 클래스가 쓰이고 있는데

Truck 프로젝트에서 저 가솔린 엔진을 조금 변경해서 재사용을 해야하는 상황 과 비슷하다고 이해하면 될까요?

그러면 따로 VhicleParts 라는 라이브러리를 만들어서 저 엔진부분을 때어내고.

Cars프로젝트를 라이브러리를 사용하는 방향으로 우선 리팩토링을 합니다.

그리고 추가로 필요한 요구사항을 VhicleParts라는 라이브러리 프로젝트에 기능을 더 추가합니다.

그리고 Truck 프로젝트에서 VhicleParts라이브 러리를 가져다 쓰게 도는데

여기서 단순히 인터페이스 부분이 안맞는 경우는 Truck프로젝트 안에서만

어텝터 패턴을 사용하여서 한번 래핑해서 사용하고 그럽니다.

나중에 어텝터로 래핑한게 다른데서도 필요하면 저 레퍼를 비클 라이브러리 프로젝트로 따로 때서 옴기거나 하겠죠.

초보자 쓰래드이길래. 딴소리 할 수도 있다는 가능성이 너무 많지만

글을 남겨봅니다.

제가 전혀 엉뚱한 소리를 했다면 ㅠㅠ 그런이야기가 아니구요~ 하면서 좀더 자세히 설명해 주세요..

감사합니다.

Steve Yoon

未讀,

2010年6月11日晚上9:45:582010/6/11

收件者：ab...@googlegroups.com

안녕하세요? 윤경록입니다.

제가 경험한 전략을 공유드립니다.

저는 벤처기업에서만 일을 했었기 때문에 대부분 '을'의 입장에서 일을 하게 됩니다. '을'의 입장에서 일을 하게 되니 '갑' 지향 프로젝트를 하게 되고, 개발 비용을 줄이기 위해 하나의 프로젝트에서 여러 '갑'들을 위한 프로젝트로 제품이 발전해 나가게 됩니다.

아래는 실제 있었던 일이지만, 제 마음대로 각색하여 예로 듭니다.

1.TRUNK version 발생

2005년 6월 모일, 회사의 CTO께서 세계 최초 ABC 프로젝트에 대해 전 직원에게 중요도에 대해 설파하고 당시 신입사원이던 저를 포함한 TFT(Task Force Team)을 구성하여 사내 자체 프로젝트를 진행 ==> 소스 코드를 SVN TRUNK에 추가하여 관리

2005년 8월 모일, 석달 정도 진행된 TFT의 밤샘으로 만들어진 데모 버전 제품을 삼성에 프로모션 할 것이라는 소식을 들음 ==> TRUNK에 있는 코드는 '삼성 향' 제품이 됨.

2005년 9월 모일, ABC 프로젝트 제품은 삼성 데모 보드(제품이 동작하게 될 타겟 하드웨어)의 종속성에 따른 요구사항을 만족시키며 삼성에 프로모션 되었으나 호응이 없었음.

2005년 10월 모일, ABC 프로젝트 제품이 엘지에 프로모션하여 선정됨 ==> TRUNK에 있는 코드는 '엘지 향' 제품으로 급 변경되기 시작

2005년 11월 모일, 엘지의 ABC 프로젝트 제품이 이탈리아의 알파(익명) 회사라는 대기업에 납품되기로 결정 ==> TRUNK에 있는 코드가 '엘지 향'이면서 '알파 향'이 되도록 변경되기 시작

2006년 4월 모일, ABC 프로젝트 성공. TFT는 상금과 트로피를 받고 그날 저는 술이 덜 깬 채로 이상한 집에서 일어남.

2. BRANCH version 발생

2006년 5월 모일, ABC 프로젝트의 삼성향이 진행되고 있음을 알아챔 ==> TRUNK에 있는 코드에서 외부 종속성이 있는 부분에 대해 추려내고 삼성향 BRANCH와 엘지향 BRANCH로 BRANCH를 냄. 더이상 TFT만으로 관리가 되지 않아서 2개의 팀에서 진행하기로 함. 한개의 팀은 대략 팀장 제외 4명 정도. 미리 BRANCH로 내어놓지 않고 작업해서 개고생 하고 있다는 생각을 하게 됨. 종속적인 부분을 떼어내기 위해 약 2주간 밤샘(프로젝트 진행 중 퇴사한 직원, 제품의 시나리오를 정확히 알지 못하고 땜빵한 코드들에 의한 레거시가 아주 큼)

3. TAG version 발생

2006년 12월 모일, 삼성향 ABC 프로젝트 무사 성공. ==> 해당 코드를 /tags/2006_12_rev20120_samsung.zip으로 tagging

4. Merging

2007년 모월 모일, 공통 모듈 중 삼성 향을 진행하면서 버그 수정된 부분에 대해서 TRUNK에 머징. 종속적인 부분은 #ifdef feature를 통해 묶음. #ifdef feature를 외부 파일로 빼고 makefile을 구성하자는 의견이 나오기 시작.

위에서 예로 든 것을 정리해보겠습니다.

맨 처음 프로젝트가 발생하면 TRUNK 버전으로 진행을 하게 됩니다. 이 TRUNK 버전이 외부 요구사항 변경에 따라 BRANCH로 갈라져 나오게 되는데, 이 시점에 대해서는 해당 산업에 대해서 경험이 있는 사람이 결정하는게 옳다고 봅니다. 너무 늦으면 추후 여러 BRANCH로 갈라질 때 굉장한 비용을 소모하게 되고 너무 이르면 왜 BRANCH로 갈라지게 해야할지 팀원의 합의를 얻어내기 힘들 수도 있다고 여겨집니다. TAG는 프로젝트 하나가 끝나거나 릴리즈가 되면 압축 파일 형태로 남겼는데, 압축을 하고 안하고의 차이를 못느꼈기 때문입니다. 나중에는 TAG를 아예 쓰지 않고 FTP에 올리는 방식을 쓰기도 했습니다.

제가 경험한 전략이 효율적인지는 저도 잘모르겠습니다. 그렇지만 팀원들과 큰 문제없이 수행하고 효과를 톡톡히 본 전략이기는 합니다. 효과는 1년도 넘게 지난 릴리즈 제품에서 문제가 발생할 때 확실히 나타났구요. ^^;

각색을 정말 아름답게 했습니다. 실제는 더럽고 힘들고 위험하였던 순간이 너무나 많았습니다. 이 자리를 빌어 당시에 저로 인해 상처받은 모든 분들께 사죄드립니다.

그럼 이만 줄이겠습니다.

윤경록 드림

回覆所有人

回覆作者

轉寄