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

카테고리

분류 전체보기 (140)
테터 (1)
悲歌 (12)
Lost & Found (1)
IT (126)
Total
Today
Yesterday

형상관리 솔루션 실루엣을 개발하면서 브랜치와 병합에 대한 의견을 다양한 업종에 계신 개발자분들과 이야기 할 기회가 많이 있습니다.

버전관리에 있어서 브랜치기능은 필수라고 생각하시는 분도 계신 반면, 그런거 기능은 있지만 실제로 쓸일이 있나요? 라고 반문하시는 분까지 말입니다.

저의 경험을 대략적으로 정리 해 보면.

- 형상통제 환경(일반적으로 금융권 형상관리 통제상황)에 계시는 분들은 버전관리 프로세스 자체가 병렬개발을 허용하지 않는 경우가 많기 때문에 필요성에 대한 욕구가 작습니다.

- 소규모 사이트 유지보수 상황(조그마한 중소기업 전산실 환경)에 계시는 분들은 해당 업무를 자신 혼자서 담당하는 경우가 많아서 브랜치를 고려 하는 경우가 적습니다.

- Package를 개발해서 판매하는 상황(실루엣 같은 Package 솔루션을 만들어서 각 사이트 별로 커스터마이징 하는 경우)은 브랜치 및 병합에 대한 욕구가 매우 강합니다만, 일반적인 경우 파일 하나에 대한 브래치라기 보다 특정 모듈 전체에 대한 브랜치 적인 성격이 강합니다.

- 제법 규모가 있는 서비스 사이트(통신사 고객서비스 센터 같은)의 경우에는 사이트는 운영기간동안 국지성 SI사업이 빈번하기 때문에 (신규 서비스가 오픈된다든지 하는) 신규 모듈에 대한 병합과 신규 모듈에 의해서 변경되는 기존모듈의 병합에 대한 욕구가 강합니다.


실제 모듈병합에 대한 제반지식을 포함한 메뉴얼을 아래에 첨부합니다.



실루엣을 사용한 모듈병합기능을 설계하면서 좀더 한국에 있는 개발자들에게 현실적인 도움이 되는 기능이 무엇일까 항상고민합니다. :)

혹시 모듈(업무)에 대한 병합을 고민하고 계신 개발자라면 반드시 실루엣을 사용하지 않더라도, 아래에 정의된 병합의 상태에 대한 가이드가 많은 도움이 되실 것입니다.



병렬개발과 모듈 병합에 대한 프로세스 이해


병합 상태에 대한 이해. 자세한 설명은 위에 첨부된 실루엣 모듈병한 메뉴얼 참조.

Flag 3가지 유형의 값을 보여주는 것으로 0 = 없음, 1,2,3은 값이 동일 한지를 의미 합니다.

예를 들어서 1-1-2 Base Mainline이 동일하고 Branch만 다르다는 것을 의미합니다.

상태

Flag

해석

동일

1-1-1

파일이 전혀 변경되지 않은 경우이다.

완료

0-1-1

1-0-0

1-2-2-

완료는 Base에 비교해서 병합작업이 완료된 경우이다. 실제 파일이 수정된 경우이기도 하지만, 파일이 동일하게 삭제되거나 추가된 경우도 포함된다.

올림

0-0-1

1-1-2

올림은 Branch에서 변경 혹은 추가된 것으로 필요하다면 Mainline에 반영 해야 하는 대상이다

내림

0-1-0

1-2-1

내림은 Mainline에서 변경 혹은 추가된 것으로 필요하다면 Branch에 반영 해야 하는 대상이다

검토

검토는 상황에 따라서 사용자의 판단이 필요한 경우이다.

소스의 내용을 판단하고, 파일의 생성시간을 참조 해서 처리방법을 판단 해야 한다.

1-0-1

(일반적으로) Mainline에서 삭제된 파일이 Branch에 아직 남아 있는 경우일 가능성이 높다. Mainline의 삭제이력을 조사하자.

1-0-2

Mainline에서는 삭제되었는데, Branch에서는 변경된 경우이다. Branch에서 계속 사용되고 있거나 그냥 변경 되었을 수 있다. Branch의 체크인 이력을 조사해서 누가 변경 했는지 추적하자.

1-1-0

(일반적으로) Branch를 생성 할 때 제외한 파일일 가능성이 높다. 물론 Branch에서 필요에 의해서 삭제 했을 수도 있다. Branch 생성시점의 이력을 조사하자.

1-2-0

Branch에는 포함되어 있지 않은데, Mainline에서는 수정되고 있는 경우이다. Branch 생성시점의 이력을 조사하자

병합

1-2-3

양쪽 모두에서 변경된 경우이다. 3WayDiff를 사용해서 어떤 내용이 변경되었는지 조사하자

기타

?-?-?

위 경우에 해당하는 않는 Case이다. 실루엣 개발팀에게 알려주자.




모듈병합 과정 이미지
Posted by 머샤머샤
, |

캐즘을 넘는다는 것.

IT/ALM / 2010. 4. 22. 07:14

[캐즘을 뛰어 넘는다는 것은 제품중심의 가치에서 시장중심의 가치로 이행한다는 것을 뜻한다.]
- 캐즘마케팅, 193Page 경쟁포지셔닝 나침반, 세종서적 완전계정판 -

최근 2개월간 제1금융권 형상관리 솔루션 실루엣 구축에 대한 컨설팅을 진행하고, 그 산출물을 막 실루엣 R&D팀에 인계하였습니다. 이후는 R&D팀에서 커스터마이징 부분을 개발해서 고객에게 인도 할 것입니다.

형상관리 솔루션 실루엣이 이제까지 제2금융권이나 제조, 서비스, 해외 등 많은 사이트에서 구축되거나 설치사용을 해 왔습니다만, 국내 제1금융권이 형상관리를 바라보는 관점이 이제까지의 고객과는 조금 다른면이 있었습니다.

실루엣 R&D팀원들의 경우에는 (이전 직장에서) 국내 여러 제1금융권의 형상관리 구축경험을 가지고 있습니다. 하지만 저의 경우에는 처음으로 진행한 컨설팅이라 그런지 (팀원들이 느끼지 못했던, 아니면 나만 그렇게 생각하는?) 부분이 다른 면입니다.

  1. 어떤일을 결정 할 때, 절차중심 혹은 절차관리를 중심으로 생각하는 것이 몸에 배어있다.
  2. 형상 관리자의 Roll과 라이브러리언의 Roll이 완벽하게 구분되어 있다.
  3. 오랜기간 형상관리 솔루션 도입 및 활용의 노하우를 기반으로 솔루션, 그 다음의 Step을 생각하고 있다.

1,2번 항목은 제도적인 절차와 금융감독원의 감사 사항등이 오랜기간동안 적용된 결과인것으로 유추됩니다.

하지만 3번 항목은 조금 의외의 결과였는데, 예를 들면 "Lock중심의 체크인/아웃 보다 (솔루션에서 충분히 지원이 된다면) 개발자의 생산성 향상을 위해서 상태중심(Update중심)의 통제방안이 더 유용하다"라던지, "고정된 프로세스와 고정된 기능의 형상기능 보다는 SDK형태의 솔루션을 기술전수 받아, 자체구축하는 것이 더 유용하다." 등.

이제까지 컨설턴트인 제가 고객에게 설명하던 부분을 먼져 이야기 하는 모습에 조금 당황하기도 했습니다. :)
- 하지만, 실루엣 솔루션에서 이미 충분히 검증되거나, 준비된 기능이라 마음속으로 기쁘기도 했습니다.
- 실루엣은 체크인/아웃등 형상기능을 위한 고객이 사용가능한 SDK를 현재 Beta 테스트 중이며, 2011년 1/4분기에 정식 릴리즈 할 계획입니다. 물론 희망하는 고객에 한해서 사전제공됩니다. :)

어떤의미에서 국내시장에서 "초기 외산 솔루션 벤더들이 (그때 그 시절에는 최선이었겠지만, 세월이 지난 지금의 환경으로는) 바람직하지 않은 방향으로 구축한" 형상관리를 기반으로, 오랜 사용경험을 바탕으로 나름의 바람직한 방향으로 진화하고 있다고 생각됩니다.

그런데 오히려, 국내 형상관리 제 1세대의 구축환경을 기반으로 학습하고 있는 제 2세대, 제 3세대의 형상관리는 현재의 개발환경 변화의 패러다임을 보지 못하고, 구습을 반복하는 것 같아 오히려 가슴이 아픕니다.

제프리 무어의 "캐즘 마케팅"을 10년만에 다시 읽으면서, 첨단 기술시장에 대한 이해도 다시하고 있지만, 기술의 전이와 기업의 생존방향에 대해서도 다시한번 인지하게 됩니다.

그리고 이제 불혹의 나이에 서서, 세상에 올바른 대안을 제시하는 것이 인생의 바른 목표라는 생각도 하게 됩니다. 자라나는 아이를 보며 말입니다.

ps - 이 글은 아름프로님의 "개발팀 힘을 내주세요."를 일전에 보고 마음속에 담아둔 바가 있어서 작성하는 글이기도 합니다. :)



Posted by 머샤머샤
, |

동영상보기

형상관리 솔루션 실루엣은 당연한 이야기지만, 실루엣을 사용하여 형상관리를 하고 있습니다. :)
( 가끔씩 영화 메트릭스에서 기계가 사람을 키우기 위해서 쓸모가 없어진 사람을 단백질로 분해해서 다른 사람에게 주입했던 기억이... )

실루엣의 기능을 소개하는 홈페이지 형상관리도 당연하게 실루엣을 이용하여 형상관리하고 있습니다.

동영상에서 보여지는 작업흐름은

  1. 변경된 소스(Html, Image)를 실루엣 Repository에 CheckIn하고,
  2. 호스팅 받고 있는 홈페이지 서버에 반영(이행)하기 위해서 "반영작업"(여기서는 요청서)을 생성합니다.
  3. 실루엣 서버에 설치된 이행서버가 "반영작업"에 설정되어 있는 대상서버(여기서는 호스팅 서버)에 파일을 전송하고, 그 로그를 기록합니다.
  4. 작업 진행상태를 모니터링 한 다음, 결과 로그를 확인합니다.
  5. 마지막으로 홈페이지에서 변경된 사항을 확인합니다.

실루엣이 가지는 이상적인 목적은 안정성, 정확성, 통제성, 편리성 등 좋은말이 많겠지만, "사람을 위한 형상관리"가 되어야 하겠습니다. :)

호스팅 서버에 체크인된 소스(Html, Image)를 전송하기 위한 FTP Step.
Posted by 머샤머샤
, |

최근 고향인 대구에서 형상관리 컨설팅을 진행하게되었습니다. 
어릴적 뛰어놀던곳에서 이제 성인이되어 프로젝트를 진행한다고 생각하니 감회가 새롭습니다. :)


챔프정보, 대구은행 차세대 형상관리 솔루션 공급

형상관리 솔루션 전문업체인 챔프정보(대표이사 박옥구, www.champit.co.kr)는 대구은행(www.dgb.co.kr) 차세대 시스템 'NexPia Project'에 형상관리 솔루션 실루엣을 공급한다.

차세대 시스템 ‘NexPia(넥스피아)’는 삼성SDS사를 시스템 구축 주사업자로 선정하여 은행 전산의 핵심 프로그램인 계정계 시스템을 비롯한 전산인프라를 전면 개편하는 대규모 프로젝트이다.

형상관리 솔루션 실루엣은 NexPia의 주요 개발 Framework인 'SYSTEMiER'의 개발환경을 지원하고, 형상의 이행 및 통제를 위해서 대구은행 그룹웨어 iTMS와 연동하는것을 목표로 구축된다.

실루엣을 사용한 NexPia 형상통제는 2010년 하순을 적용목표로 하며, NexPia Project는 2011년 중순을 완료목표로 하고 있다.

주)이 자료는 (주)챔프정보 품질관리팀에서 작성한 것으로 언론매체가 보도를 목적으로 자유롭게 사용할 수 있습니다.

Posted by 머샤머샤
, |
늘 자료와 정보의 공개 및 공유를 외치는 머샤입니다. :)

이번에 컨설팅을 진행하고 있는 사이트에서 형상관리에서 도출 될 수 있는 Report Template에 대한 요청이 있어서, 아예 작업하는 김에 두고 두고 사용 할 수 있는 포맷으로 준비를 했습니다.

URL: http://www.snh.co.kr/brochure/sil_report_sample/sil_report_sample_201002.pdf

물론, 이것은 형상관리 솔루션 실루엣을 사용하여 프로세스 커스터마이징을 하는 경우에 도출 가능한 Report입니다.
 
평소 국내 형상관리 관련 자료가 너무나 부족함을 절절히 느끼고 있기에, 관심있으신 분들께 조금이나마 도움이 되고자 하니 참조하시기 바랍니다.

Report Sample에 포함된 이미지중 일부 입니다.



Posted by 머샤머샤
, |
10년만에 "캐즘 마케팅"을 다시 꺼내 읽고 있습니다.

적용사례를 참조하려는 성향이 강하고 높은 수준의 후속 지원에 중독되어 있는 전기다수 수용자의 주류시장에서 마케터들은 부족한 적용사례와 미흡한 지지기반으로 인해 길고 외로운 싸움을 할 수밖에 없는 난관에 봉착한다. 이것이 바로 캐즘이다.
- 캐즘 마케팅(완전개정판) 48P -
형상관리 솔루션 실루엣을 시작하는 시점에 주류시장이라고 할 수 있는 금융권 형상관리에 진입하기 위해서 부단히 노력했던, 특히 적용사례의 부족으로 난관에 봉착했던 일들이 떠올려 집니다.

팀원들이 부단히 노력한 결과이기도 하지만, 기술 트랜드의 변화, 마케팅 방향의 변화를 통해서 이제는 많은 참조모델을 가지고, 어느 정도 (물량이 밀리면서) 일할수 있는 상황은, 그간 많은 변화가 있었다는 것을 의미 할 것입니다.

이제 실루엣이 목표로 하는 SMB시장을 위해서는 어떤 효과적인 마케팅을 해야 할 것인지 고민하고 있습니다.

(가칭)실루엣 3.0은 엔터프라이즈 시장에 부족한 것은 아니지만, 솔루션 커스터마이징이라는 엔터프라이즈시장이 가지는 비용한계점을 극복하고자 하는 것이 주요한 목적이니, 좀더 다른 형태의 접근방향을 구상하고 있는 상황입니다.

실루엣이 진정한 캐즘을 넘어서 "보편재"로서 롱런 하기를 기원해 봅니다.
Posted by 머샤머샤
, |
Copyright (c) 2007 Laurent Gregoire

어제 대구에 출장갔다온 사이, 이전에 알고 지내던 WAS관련 개발을 하는 지인이 메신저로 근황을 남겨두었네요.

*** ( [흥](ㅡ,.ㅡ) ) 님의 말 :
클리어케이스쓰는데 이거 빡시네요
이분은 형상관리 제품인 실루엣을 1년정도 사용하신 분입니다.

어제 대구에서도 뼈저리게 느낀것입니다. 형상관리라는 영역이 아직은 기술수용주기에서 "전기다수수용자"의 초입이 아닐까 합니다.

물론 ClearCase와 같은 (10년전)얼리어뎁터를 위한 제품이 기업시장에서 아직은 강세를 보이고 있지만, VSTS2010, RTC 같은 제품들이 전기다수수용자를 포용하기 위한 준비가 된 상황이라는 판단입니다.

아주 고가의, 그리고 오래된 (얼리어뎁터)솔루션이 계속 살아남아서 전기다수수용자의 욕구를 충족 할 수 있을까요?

실루엣은 현재 실루엣 3.0의 런칭준비를 논의중입니다.
고객, 마케팅, 가격포지셔닝, 지원 및 운영준비....

빠른 시간내에 저렴한 가격으로 여러 고객들에게 다가 갈수 있으면 좋겠습니다. :)
Posted by 머샤머샤
, |

컨설팅을 진행하다 보면, 한국에 있는 품질관리 담당 혹은 관리자들은 빌드와 디플로이 관련 작업에 인력을 할당하는 것이 합당한지에 대해서, 회의적인 생각을 가지고 있는 같습니다.

반면에 서양쪽에서는 그와 관련된 직업군이 형상되어 있고, 매우 빈번하게 인력 채용공고가 나오는 편입니다.

이런 빌드관련 작업을 개발자가 해야 하는 작업일까요?

물론 팀의 상황에 따라 다르겠습니다만, Build와 Deploy를 매우 잘 관리하는 것이 품질관리 측면에서 많은 도움이 된다는 것을 인지하였으면 좋겠습니다.

형상관리 솔루션 실루엣 컨설팅을 수행하면서 고객에게 빌드형태에 대한 설문이나, 빌드스크립트 생성의 역활에 대해서 대화를 하다보면, 빌드관리자의 존재는 고사하고, 형상관리에 대한 책임까지도 누구에게 있는지 모호한 팀을 많이 만났습니다.

모든 팀에게 인력적인 여유가 있는것은 아니겠지만, Build와 Deploy 만큼은 담당자를 지정해 두고, 자동화와 스크립트 유지보수에 투여되는 시간에 대해서 보장되었으면 합니다.

빌드관련 채용공고 Sample보기
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=302&dockey=xml/f/b/fb10cab3c27a1a39a42dca395fab2bb7@endecaindex&source=18

Title: Build and Deploy Engineer(Clearcase,Clearquest and TFS)

Skills:Build and Deploy Engineer(Clearcase,Clearquest and TFS)

Date: 12-7-2009

Description:

(1) Creates projects and code stream in Clearcase and TFS.
(2) Builds and merges code for Clearcase.
(3) Builds and merges code in TFS.
(4) Creates build scripts that are produce deliverables/packages that the deployment engineers use to deploy code. (5) Provides support for CCIT resources using Clearcase and TFS. (6) Provides support for Clearquest to enable the automatic deployments of custom objects and standard reports to non-production environments.

Sam Ayyalil
Ajilon
RoseTree Corporate Center Suite 5025
Media, PA 19063
Phone: (800) -88-8-80

Posted by 머샤머샤
, |

2009년도 이제 정리해야 하는 시점입니다.

연말이 되면 항상 올 한해도 기술문서나 소개문서를 만들어서 많이 공개하지 못했구나... 어떤 남아있는 숙제같은 것을 느끼는데 말입니다.. :)

이번에 만든 문서중에서 기획하는 단계에서 사용 할 수 있는 설문조사서를 하나 공개 할까합니다.


주로 품질관리를 담당하는 업무팀에서 사용할 목적으로 만든것입니다만, 팀내에서 빌드 자동화나 이행(배포) 자동화를 생각하고 계신 분이라면 분명히 도움이 될 것입니다.

이제 조금 남은 연말에 좀더 많은 문서를 공유 할 수 있기를 희망합니다.

빌드관리시스템, 배포관리시스템, 이행관리시스템, 형상관리시스템, 버전관리시스템... 뭐 말은 많지만 결국 그 모든것들이 사용자를 억압하는 시스템이 되어서는 않된다는 것이 제 생각압니다.

개발과 운영환경이 매우 복잡하고 다양해진 현재의 IT환경은 점점 더 많은 개발 및 운영 리소스를 필요로 하고 있습니다. 효율적인 자동화는 개발팀과 운영팀의 로드를 덜어주고 본연의 업무인 개발과 운영 그리고 인간적인 삶에 집중 할 수 있도록 해 주는 분명 의미 있는 작업입니다.

부디 팀이 할애 할 수 있는 최대의 노력을 자동화에 투여 하여 좀더 낳은 환경에서 업무를 추진 할 수 있기를 희망합니다.

from 박부장.. :)


Posted by 머샤머샤
, |
관련 동영상 보기

형상관리 솔루션 실루엣을 개발하면서 다양한 환경의 사용자분들을 만나게됩니다.

버그트레킹 시스템의 진화에 관한 토론등에서도 느낄 수 있지만, 사용자(특히 개발자 혹은 관리자)들이 선호하는 UI는 시스템의 기능에 절대적인 도입 포인트가 되기도 하고, 때에 따라서는 해당 솔루션 개발팀의 의지를 반영하기 도합니다.

Base Camp. 팀이 말하는 Rich Client에 대한 굳은 의지신념에서 살짝 느껴지는 장인정신이랄까요?

일반적으로 기업에서 정해진 품질관리 프로세스 (변경요청 부터 시작되는 ....)는 개발도구와는 조금 별개로 취급되고는 합니다.

상용이거나, 공개되어 있는 IDE에 연동되는 프로세스제품(예를 들어서 Bugzilla)를 사용하지 않는 이상은, 개발자가 IDE상에서 직접 회사의 프로세스에 자신의 작업결과물을 반영하는 등의 작업은 할 수 없겠지요.

개발은 개발 따로 하고, 개발이 완료된 상태에서 테스트 할  테스터(그나마 테스터라도 제대로 있으면 다행)에게 테스트 해 보라고, 전화, 메신저로 테스트 환경을 알려주거나, 혹은 오프라인으로 어찌 어찌 연락을 해야 하는 상황이 우리 주변에서 흔히 볼 수 있는 상황입니다.

Eclipse IDE (혹은 Visual Studio라도)상에서 테스트 빌드를 하고, 그 결과물이 정상일 때 자동으로 테스터에게 테스트를 요청 할 수 있도록 한다면, 개발자들의 잡무를 줄이고 개발업무에만 집중 할 수 있을 것입니다. :)

개발자게 개발을... 형상관리는 개발자를 옭아매는 통제시스템이 아니라, 개발의 보조수단. 도움이 되는 유틸리티가 되어야 한다.

이것이 실루엣팀의 고집이자. 신념입니다. :)
Posted by 머샤머샤
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함