이 소스는 건들지마
2011/10/09 16:07 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.
위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.
기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다.
그것은 바로 "Baseline"과 "3-way merge"이다.
이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.
Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.
아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by jACK TWO
RSS Feed
소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.
- 이 소스코드는 건들지만 이번주 금요일에 릴리즈할 건데 지금 테스트 중이라서 건들면 헷갈리니까 잠시 건들지 말아줘
- 소스코드를 수정해서 등록하는데 Conflict가 났다. 원래 수정자를 찾아 같이 모여서 소스코드를 머지했다.
- 같은 소스코드를 서로 같이 동시에 수정하면 문제가 많으니 각 모듈마다 담당자를 따로 정해서 소스코드가 충돌하는 경우를 원천 봉쇄했다. 그래서 서로 다른 사람들의 소스코드를 잘 모른다.
- 하나의 소스코드를 가지고 오늘은 내가 내일은 다른 사람이 수정할 수 있도록 서로 일정을 조정했다.
- v1.0 출시 후 v1.0 유지보수와 v1.5로 업그레이드 하는 프로젝트가 동시에 진행하는데 서로 소스코드가 섞여서 소스코드 관리를 잘해야 한다.
- 위 경우 소스코드 충돌 때문에 소스코드 브랜치를 만들어서 따로 6개월간 개발을 했는데 나중에 v1.0의 수정본을 v1.5에 합치는데 워낙 많이 바뀌어서 거의 한달이나 걸렸다. 그 한달동안에 v1.0 소스코드는 또 많이 바뀌어서 Merge하고 테스트하는데 시간이 또 많이 걸렸다.
위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.
기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다.
그것은 바로 "Baseline"과 "3-way merge"이다.
이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.
- 언제 릴리즈하는지는 상관없이 언제든지 소스코드를 수정할 수 있다.
- 소스코드 Conflict가 일어나도 원래 수정자가 없이도 쉽게 Merge할 수 있다.
- 소스코드에서 여러 컴포넌트를 개발했던 원래 개발자는 있지만 서로 상대방의 컴포넌트를 수정할 수 있고 동시에 수정을 해서 충돌이 가끔 일어나지만 문제 없이 Merge가 된다.
- 소스코드를 누가 언제 수정하는지 전혀 신경 쓰지 않고 서로 동시에 수정을 할 수 있다.
- 유지보수 프로젝트와 업그레이드 프로젝트가 동시에 진행을 해도 Merge는 불과 몇시간이 걸리지 않고 대부분 자동으로 해결된다.
Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.
아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by jACK TWO
'기반시스템 > 소스코드관리' 카테고리의 다른 글
| SVN보다 Git가 더 좋을까? (21) | 2011/10/25 |
|---|---|
| 이 소스는 건들지마 (4) | 2011/10/09 |
| 소스코드 Conflict (5) | 2011/02/18 |
| 소스코드관리시스템 사용도 2차 조사 결과 (10) | 2010/12/03 |
| 2차 소스코드관리시스템 사용도 조사 Poll (12) | 2010/11/14 |
| 마이크로소프트, 구글의 소스코드 트리의 비밀? (9) | 2010/06/08 |
Trackback Address: http://allofsoftware.net/trackback/236
좋은 글 잘 읽었습니다. 버전 관리 시스템 기능을 최대한 활용해 문제를 해결할 수 있다는 것에 일정 부분 공감하지만 버전 관리 시스템 사용만으로는 한계가 있다고 생각합니다.
브랜치가 생성되는 순간 이를 테스트할 수 있는 개발 환경을 쉽게 구축할 수 있는 환경이 되어야 하고, 소스 코드 머지가 subverion은 다소 문제가 되는 부분이 있어 다른 형태의 버전 관리 시스템을 사용해 보는 것도 고려해볼 필요가 있다고 생각합니다.
그러나 다른 무엇보다 각 기능들을 어떻게 관리하느냐가 가장 중요하지 않나 생각합니다. 기능들을 잘게 나누어서 우선순위를 선정해 개발하는 방식이 갖추어져 있어야 이 모든 과정이 가능할 겁니다. 이 부분을 모두 갖춘 상태에서도 브랜치를 나누고 소스 코드를 잘 관리하는 방법은 상당히 어려운 작업이라고 생각합니다. 한, 두 달의 시간이 아닌 1,2년의 시간을 투자했을 때 진정 우리가 원하는 형태의 소스 코드 관리가 가능해지지 않을까 하는 생각이 드네요.
안녕하세요. 자비지기님
SVN은 Merge에 있어서 정말 강한 툴이지요. ^^
하지만 제대로 쓰려면 그 컨셉을 정말 잘 알아야 합니다.
형상관리도 중요하고 스펙의 범위 관리도 중요하지요. 뭐하나 소홀히 얘기하기는 어렵겠네요.
Git이 SVN보다는 몇가지 나은 점이 있고, 또한 3-way merge를 해서 아무런 문제 없이 머지가 되었다고 해도 그건 단지 텍스트상의 머지이기 때문에 실제로 '언제든지 소스코드를 수정할 수 있다' 가 만족되려면 상당한 수준의 테스트 케이스가 준비되어야 하고 또한 QA들의 도움이 필요한게 사실이지요.
또한 이미 릴리즈된 버전에 픽스된 라이브 버그 픽스들을 적절히 트렁크로 가져와서 머지하는 것도 중요합니다. 안 그러면 매 버전마다 개발자들이 regression bug때문에 생고생을 하는 경우도 종종 -_-;;
안녕하세요. 우울한딱따구리님
Git을 쓰려면 조금더 역량이 필요한 것은 사실이지요. ^^
언제한번 SVN과 Git를 비교해보도록 하겠습니다.