머샤의 인생과 웃기는 고양이

Maven을 사용하여 컴파일을 하고 테스트를 하면 당연히 프로젝트 내부에 있는 파일의 변화가 발생합니다.
(누가 이런거에 관심을 가지겠냐마는... :')

위 표는 Maven archetype 112번 sample로 테스트 한 것으로... (하여간)

위 에서 주시하는 내용은  
* compile 명령은 target의 class를 생성합니다.
* test 명령은 target의 class와 test-class를 모두 생성합니다. 그리고 Test Result를 .txt, ,xml File로 생성합니다.
* package 명령은 test까지 포함하는 작업을 수행하고 .jar와 .properties File을 생성합니다.
* clean 명령은 다시 깨끗하게 지워주는 군요 :')

생각해 보면 당연한 것이데... :') 

조사는 File 확장자 분석기 프로그램을 사용했습니다. :') http://halfenif.tistory.com/140 

도데체 HDD안에는 무슨 파일들이 얼마나 들어 있는 것일까요? 대부분 쓸모없는 동영상 파일들이겠지만 말입니다.

첨부한 실행파일은 특정 폴더에 포함된 파일을 분석해서 확장자별로 구별 해 주는 프로그램입니다.
(원래는 형상관리 실루엣 레파지토리 구성 할 때 관리 할 소스파일의 유형을 도출하기 위한 도구입니다만...)

 

첨부한 프로그램을 실행하시고 1,2,3 순서로 조작 하시면 폴더에 포함된 파일 확장자별 용량을 구하실수 있습니다.


아래 첨부파일은 확장자 분석기 실행파일입니다.

 

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

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

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

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

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

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

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


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



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

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

개발도구의 트랜드가 다시 변경되는 시점이라는 판단에 매뉴얼 갱신 및 살펴볼겸 Windows Phone 7의 개발환경을 설치해 보았습니다.

무려 One Click으로 어디 설치되는지 물어보지도 않고, 진짜 간편하게 모든 개발환경이 설치되고 말았습니다만..

Visual Studio Express Edition은 버전관리 옵션을 제공하지 않는군요. ㅠㅠ

아래 Visual Studio 2010에서 제공 하는 옵션에서 척봐도 많은 부분이 다른거 같습니다. :)

만약 아드로이드 앱 개발자분들이라면 실루엣 Eclipse Plug-in을 사용해서 Linux나 Mac에서 까지도 개발을 할실수 있습니다만, WinPhone 개발자 분들은 강력한 실루엣 Client인 Workspace를 사용하셔야 겠네요.. :)

IBM으로 부터 "소프트웨어 개발 라이프사이클에 맞춘 똑똑한 솔루션! 형상/변경/빌드/배포 관리의 통합" 이라는 거창한 제목의 설문조사가 왔길래... 당연히 Jazz일 꺼라고 생각 했습니다.

설문조사 보기 http://www-903.ibm.com/kr/surveys/survey.jsp?survey_id=Rational_edm

ClearCase, ClearQuest, BuildForge에 대한 설문조사입니다.

왜? 일까요? 현실적으로는 여러가지 사정이 있겠습니다만, 관심을 가지고 지켜보는 입장에서는 순간 당혹하지 않을 수 없었습니다. :)

얼마전에 있었던 "애자일 실천법 세미나 2010..."에 대한 후기가 올라왔군요.
박PD님 세미나 후기보기: http://parkpd.egloos.com/tb/3241701

관심을 가지고 있었습니다만, 지방출장관계로 참석을 못했는데 후기를 보는 것 만으로 많은 도움과 많은 생각을 하게 합니다.


드디어 실루엣 개발팀은 애자일관점에서 보면, 또하나의 사내 협업 도구인 CodeInside의 Eclipse RCP 버전을 릴리즈했습니다.
* 물론 저희팀만 사용하는 것입니다. Google에서 찾지마시기 바랍니다. :)

많은 분들이 좋은 회사에 다니시는 관계로 좋은 사내 Groupware나 (아니면)제로보드라도 설치해서 사내 협업을 하고 계십니다만, 실루엣팀은 거의 초창기부터 Delphi로 만들어진 인하우스도구를 사용하고 있습니다.

여러분은 협업도구를 왜? 사용하고 계십니까? 단순히 정보의 교환이나 보고의 목적으로 사용하시나요?

방금 얼마전에 있었던 "애자일 실천법 세미나 2010 후기..."를 보고 느낀 점입니다만, 개발팀이 하나의 목표를 성공하기 위해서 조직 및 의식을 만들어 가는 "팀빌딩"에는 상당한 시간과 많은 비용을 요구합니다. 그런데 그런 노력을 잘 몰라주시거나, 왜 필요한지 의심을 가지시는 고객이나 윗분이나 팀원이 있다면... 순간 순간 난감하지요.

실루엣 개발팀은 그 팀빌딩의 방법으로 하나의 협업도구("CodeInside")와 조직의분리("개발/PMO+QA")를 통한 버전관리+데일리빌드+워크아이템 관리환경을 거의 5년동안 실행하고 있는 셈입니다.

이 CodeInside Eclipse RCP 버전도, 얼마전에 백일된 딸아이들 둔, 이모과장님이 업무 외 시간을 짬짬이 투입해서 완성한 버전입니다. 이전에 동일한 서버를 사용하는 2개의 델파이 버전 Client와 Web 버전까지 있으니, Eclipse RCP 버전이 4번째 Client인 셈이군요.

팀원의 새로운 도전에 대해서 팀은 언제나 환영하고 격려하는 분위기를 조성하고, 자신감을 가지고 일 할 수 있도록 배려하는 것은 무엇보다. 우리가 "닭장의 미싱 시다처럼 부려지는 노동자"가 아니라 "창의적인 생각으로 제품을 만들고 있는 사람"이기 때문일 것입니다.

그런 관점에서, "애자일도 개발자를 사람답게 만드는 아름다운 작업"일 것입니다. 그런 생각을 기반으로 팀빌딩을 위한 노력을 기울이고 싶습니다. 계속해서 말입니다. :)

[캐즘을 뛰어 넘는다는 것은 제품중심의 가치에서 시장중심의 가치로 이행한다는 것을 뜻한다.]
- 캐즘마케팅, 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 - 이 글은 아름프로님의 "개발팀 힘을 내주세요."를 일전에 보고 마음속에 담아둔 바가 있어서 작성하는 글이기도 합니다. :)

이 글은 영회님의 "버전관리 툴에 대한 조사" 포스팅에 트랙백하기 위한 목적으로 작성합니다.

버전관리 제품에 대한 선호의 차이가 극명한 차이를 보이는 점에 대해서 머샤는 이러한 관점으로 생각합니다.

버전관리(ALM거의 대부분)는
- 개발환경과 밀접한 관계가 있다.
- 조직의 문화와 밀접한 관계가 있다.

* 어떤 버전관리(ALM모두)도 모든 조직의 문제를 히결 해 주지 못한다.
* 어떤 버전관리 제품이라고, 조직이 문제를 극복하고자 하는 의지만 있으면, (설사 그것이 맨손이라도) 해결 할 수 있다.

버전관리 뿐만아니라, ALM관련 제품은 조직의 문제를 알아서 해결하기 보다는, 조직의 문제 해결에 보완이 되는 부분이라고 생각합니다.

시스템에 맞추어 일을 하기 보다는, 조직이 합리적이고 생산적인 프로스로 가기위한 도구로서 검토되고 채택되어야 한다고 생각합니다.

- CVS는 Lock기능이 않되어서 사용(통제) 할 수 없어요.
- ClearCase는 너무 복잡하고, 고가인데다 사용하기 너무 힘들어요.
- SourceSafe는 Source가 가끔 깨져요. 신뢰 할 수 있어야 해요
- Harvest는 서버가 죽어요.

조직인 다른 솔루션을 도입해서 문제를 해결 할 수도 있겠지만, 현재 보유한 솔루션을 잘 활용 할 수 있도록 많은(진짜로 많은) 노력을 들여서 고민하고 또 고민하고, 조금씩 실천하면서 적용하는 것이라 생각됩니다.

물론 형상관리 솔루션 실루엣도 마찬가지이고, 제가 사이트에 컨설팅을 가서도 항상 드리는 말씀입니다.

형상관리 솔루션 실루엣은 3가지 기능으로 구성되어 있습니다.
- Worksapce: 버전관리
- Builder: 빌드/배포 관리
- Workflow: 변경 프로세스관리

Workflow Online Demo 사이트: http://gscm.snh.co.kr:7070

이제까지 Workspace와 Builder는 평가판을 공개하고 있었습니다만, Workflow는 그 특성상 공개하는 것이 쉽지는 않았습니다.

이번에 ExtJS 라이선스 구매를 계기로, "ExtJS개발자들에게 보탬이 되는 무언가를 하자!"라는 엉뚱한 발상으로 Workflow를 간략하게 만들어서 공개하게 되었습니다.

1) 이건 아무리 생각해도 발상이 이상한것 같습니다만, 2008년 실루엣 웹 프레임워크로 ExtJS를 선정 할 당시, 참조할 사이트가 아무것도 없어서 고민하고, 구글링을 통해서 중국쪽에서 만들어진 사이트 이미지만 가지고 판단했던 기억이 너무나 생생하기 때문입니다.

2) 온라인에서 동작하는 ExtJS 사이트, 그것도 기업용으로 만들어진 사이트를 접해 볼 수 있는 기회가 많지 않습니다. 그런 관점에서 ExtJS를 개발 프레임워크로 선정하려는 분들께 조금이나마 도움이되고자 하는 바램입니다.

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