블로그 이미지
Welcom Back Tatter. 머샤머샤

카테고리

분류 전체보기 (140)
테터 (1)
悲歌 (12)
Lost & Found (1)
IT (126)
Total
Today
Yesterday
가끔 바라보는 블로그 유입경로에 CVS나 SVN의 Lock기능을 검색해서 오시는 구글러 분들이 계십니다.

거기다가, 컨설팅을 진행하는 사이트 혹은 문의하시는 고객분들 중에도 CVS는 Lock을 사용 할 수 없어 않되요..라고 말씀하시는 고객분들도 계시고요.

2007년 초 실루엣 2.0을 기획 할 당시에 구할 수 있는 대부분의 형상관리 제품을 벤치마크하면서, 그 이전까지 당영하게 생각하고 있었던 CheckOut Lock의 Concept을 변경하게 되었습니다.

현재 실루엣팀이 생각하는 Lock의 Concept은 
* 필요와 상황에 따라 개발자가 선택 할 수 있어야 한다. * 입니다.

반드시 품질을 책임지고 있는 파트에서 강요하는 형태가 아니라, 
* 개발자에게 도움이 되는 도구로서의 형상관리 도구 * 입니다.

물론 실루엣 2.0은 PVCS, SorceSafe와 같은 형태의 Lock중심의 무결성 보장방식과 CVS, SVN과 같은 상태중심의 무결성 보장방식을 모두 지원하고 있습니다.

다만, 어느 한쪽으로 강요하고 않고, 개발자가 자신의 개발환경 특성에 따라 선택 할 수 있도록 하는 것이... (최초)도입시점에 한쪽의 경험만 가지고 계신 담당자 분의 우려와 염려를 야기 하기도 합니다. :)

* 몇 담당자 분들은 어느 한쪽이던지 고정된 방식을 선호 하시더군요. 특히 Lock방식을 선호하시는 분들은 말입니다.

CVS, SVN을 사용하면서, Lock기능을 고려 하시는 분들 께서는 (부담없이)다음 사항을 한번 검토해 보시면 어떨까 합니다.

A. 개발도구가 CVS(SVN)만 지원하기 때문에 (주로 Eclipse) CVS를 쓰기는 써야 하겠는데, Source가 자꾸 엎어지거나 꼬이는 문제가 있다.
B. 개발환경이 Unix에서 공용ID 하나만 가지고 울트라에디터 FTP연결로 개발하는데, CVS Lock으로 버전관리를 해야 하겠다.

말하고자 하는 결론부터 이야기 하자면,
* CVS(SVN)는 개인 개발영역에 특화된 버전관리 도구입니다. *
* Lock 중심의 컨셉은 공용작업영역일 경우 그 사용 효과가, (사용하지 않을경우)의 불안정성(개발 및 반영의 불편함. 여러 문제들)을 극복 할 수 있습니다. *

Case B. 처럼 (우리나라에만 있는? :) 공용작업영역을 한꺼번에 사용하는 개발환경에서는 CVS처럼 상태정보를 사용하는 방식은 적용 하는 것이 바람직 하지 않습니다.
* CVS Lock기능을 사용해서 관리하는 것이 완전히 불가능 한것은 아닙니다만.... 사용주체를 개발자가 아닌, 관리자가 단독으로, 정기적으로 사용하는 것이 바람직 합니다.

Case A. 처럼 CVS를 사용하면 좋은 개발환경인데, (무언가, 하여간 자꾸만 문제가)생기는 상황이라면, 그것은 Lock을 기능을 사용해야 하는 것이 아니라, 개발자+담당자 모두 모여 신경쓰고, 교육을 통해서 팀의 Source관리 환경을 Upgrade시켜야 하는 것입니다.

그리고, 이 모든 사항이 절대적이라기 보다는, (일반적으로 그렇다는 것이고) 
* 개발도구+개발환경+빌드환경을 고려 하여 버전관리(형상관리)도구를 선택하시기 바랍니다.
* 어떤 도구도 모든 환경에 최선의 선택이 될 수 없습니다.
Posted by 머샤머샤
, |

이 글은 오리대마왕님께 트랙벡하기 위해서 씁니다.

먼저 우리개발팀은 SVN을 사용하지 않습니다. 버전관리는 실루엣을 사용하니 SVN에 특화된 이야기는 아니지만 개발자들의 Commit은 장려해야 하는 것이 아닐까해서 몇자 적어 봅니다.

이제까지 형상관리 혹은 버전관리 제품을 사이트나 프로젝트에 도입하면서 개발자들이 못쓰겠다고 버티는 것이 문제였지 너무 잦은 commit은 축복이 아닐까 합니다.

물론 오리대마왕님이 지적하신 것 처럼 프로젝트 리비전을 지원하는 SVN에서 파일 하나 단위로 commit하면 관리하는 입장에서 상태파악(Insight)하기는 좀 곤란하지요. :)

(Eclipse SVN)에 버그가 있어서 소스가 날라가는지는 모르겠지만, 버전관리 시스템은 개발자들이 아무리 험하게 다루더라도 그 변경내용을 고스란히 기록해 줄 것입니다. 그것이 그 프로젝트의 생명줄과 같을 테니 말입니다.

그것보다도 가끔씩 PM님들이 QA에게 물어보는 난감한 질문에 대처하는 방법이 가끔씩 필요하지 안을까 합니다.

"우리 개발자들이 하루에 프로그램을 몇본이나 짜?"
"신규로 체크인되는 소스 갯수 세어보면 알 수 있지?"

가끔씩 이런 코볼시대 상황을 이야기하시는 분은 상당히 곤란하기는 합니다만. 필요한 질문이기도 하지요.

개발자들이게 프로젝트가 어떻게 가시적으로 commit되고 있는지 현황을 보여준다면, 너무 잦은 commit은 자연스레 정리 될 지도 모르겠습니다.

실루엣에는 프로젝트 리비전조회라는 기능이 있어서 개발자들이 직접 변경된 내용을 볼수 있습니다만, SVN의 경우에는 FishEye와 같은 제품을 부가적으로 사용해서 프로젝트 진척상태를 함께 공유하는 것은 어떨런지요.

Line history 
물론 10User에 $1,200이나 하는 무시무시한 가격이지만, 아직까지 이것보다 좋은 도구는 찾아보지 못했습니다. :)

(정 않되면, Log를 파싱해서 Excel로 Chart를 그려내는 수고까지)한다면 일거리가 너무 많아지는 것일까요? 하지만 QA입장에서 개발자들이 직접 피부로 느낄수 있는 자료를 지속적으로 제공하는 것 만큼 좋은 협조는 없다고 생각합니다. 개인적인 생각일지 모르겠지만, 개발자들이 눈으로 추이를 볼 수 있다면 조금씩 조금씩 QA가 원하는 방향으로 흘러주기도 합니다.

교육도 교육이지만 공감이 중요하다는 생각. 물론 PM님에게 어필도 되구요. (이게 제일 중요한 것인가요? 흠.) 프로젝트 QA 힘내세요. 짝짝짝!

Posted by 머샤머샤
, |

 

사용자 삽입 이미지









Project Version Manager Demo




전통적인 버전관리툴들, 그것이 Lock 중심의 것들(PVCS, SourceSafe...)이던지, Update 중심의 것들(CVS...) 이던지 상관없이 파일 중심의 버전관리 도구들입니다.

즉, 하나의 파일에 대한 버전변경을 추적하는 기능을 가지고 있는 것이지요.

실제 개발팀에서는 파일 하나의 버전에 대한 추적도 중요하지만, 변경셋(Change Set)에 대한 이력을 추적하고 관리하는 것이 무엇보다도 중요합니다.

CVS를 대체하겠다고 만든 SVN은 그런 의미에서 뉴트랜드에 부합하는 버전관리도구라고 할 만합니다.

몇몇 외산 버전관리 도구들이 Snap Shot이름으로 그 변경내용을 저장하는 방법을 제공 하기는 합니다만, 자동으로 저장되는 것이 아니라 사용자가 필요시점에 Snap을 작성하는 것이라 불편한 점이 많았습니다.

사용자가 일일이 snap을 작성하는 부분은 일견 "레이블" 기능과도 닮아 있습니다만, 사용방법과 Scope가 다릅니다. (그 이야기는 나중에 기회가 있으면...)

상단에 링크된 실루엣 프로젝트 버전 관리를 유심히 살펴보면 각 변경내역을 기록하고 추적하는 다양한 기능이 구현된 것을 볼 수 있습니다.
중요 기능을 정리하면

  • Check In 시점에 자동으로 Project Revision 생성
  • Project간 Revision Compare (Branch된 다른 Project에 대해서 Compare)
  • 특정 Project 리비전에 Check In된 소스 조회 및 복원
  • 특정 Project 리비전 복원 (프로젝트 내용 전체를 복원하는 기능)

형상관리, 버전관리는 도구도 중요합니다만, 개발팀이 얼마나 의욕을 가지고 꾸준히 실천하느냐가 무엇보다 중요합니다.
그 실천의 과정에서 필요한 도구는 자연스럽게 방법이 찾아지고, 정착 될 것입니다.

Posted by 머샤머샤
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함