레이블이 기반시스템/소스코드관리인 게시물을 표시합니다. 모든 게시물 표시
레이블이 기반시스템/소스코드관리인 게시물을 표시합니다. 모든 게시물 표시

2010년 11월 14일 일요일

2차 소스코드관리시스템 사용도 조사 Poll

약 2년전쯤 제 블로그에서 어떤 소스코드관리시스템을 사용하고 있는지 조사를 한 적이 있습니다. 

시간도 꽤 흘러서 그동안 어떤한 변화가 있었는지 알고 싶어집니다. 특히 그동안 소스코드관리시스템을 사용하는 비율이 어느정도 높아졌는지가 가장 궁금하더군요. 또한 최근에 분산소스코드관리시스템에 대한 관심의 증가가 실제로 사용도에 영향을 주는지도 궁금합니다.

설문은 간단하게 사용하시는 소스코드관리시스템을 체크하면 됩니다. 만약에 보기에 없다면 Other 항목에 직접 적어 넣으시면 됩니다.

많은 참여 부탁합니다.

소스코드는 어디에 보관하세요? (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능)
 

2010년 6월 8일 화요일

마이크로소프트, 구글의 소스코드 트리의 비밀?

오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요.

책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다.

질문은 다음과 같습니다.
나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다. 그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다.

사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이해하고 경험이 있다면 질문에 해당하는 내용이 책에 포함 되어 있다는 것을 알 수 있을 겁니다. 

결론부터 먼저 말씀드리자면 최종 결과물인 "소스코드 트리"만 보면 배우기 어렵다는 겁니다. 잘 작성된 SRS를 몇개 보고 SRS를 제대로 작성하는 법을 배우기 어려운 것과 비슷합니다. 따라서 소스코드 트리를 보는 것이 큰 도움이 안된다는 것을 말씀드립니다. 하나의 사례를 보는 것에 족할 겁니다. 자칫 그 방법이 가장 좋은 방법인 줄로 착각을 하게 되면 시각이 굳어져서 손해를 볼 수도 있습니다.

좀더 쉽게 설명하면 타이거우즈(요즘 조금 부진하지만)가 골프치는 모습을 보고 골프를 배우기는 어렵고, 김연아가 스케이트 타는 것을 보고 따라하기 어렵다는 겁니다. 어떻게 해서 이러한 결과물이 나오는지 그 과정과 훈련 방법을 알아야 하겠지요. 

그런 과정에 관련된 내용이 책에서 상당히 많이 언급하려고 노력했습니다.

그 과정이라는 것도 각자의 수준에 따라서 보이는 것이 다릅니다. 수준을 1~10정도로 정의할 때 수준이 '1'인 사람은 아무리 설명해도 '2'나 '3'의 내용만 이해가 가능합니다. 수준이 '5'인 사람은 '6'이나 '7'정도가 이해할 수 있습니다. 그래서 올바른 방법으로 꾸준히 차근차근 훈련(경험)을 해 나가야 성장합니다. 

그외의 끝내주는 방법은 없습니다.

위 질문의 요지를 보면 다음과 같습니다.
  1. 모듈을 어떤식으로 분리하는지?
  2. 소스트리를 어떻게 구성하는지?
  3. 중복되는 소스코드를 어떻게 제거하는지?
  4. 공통모듈은 어떻게 공유하는지?
  5. 코멘트는 어떤 규칙으로 작성하는지?
결론부터 말씀드리면 다음과 같습니다.

 구체적인 방법은 회사마다 다르지만 원리는 똑같다.

이것을 모두 이해하려면 1~10 정도의 수준에서 '7'~'8' 이상은 되어서 합니다. 그렇지 않고 아직 소스코드관리시스템의 일부기능만 간신히 쓰고 있고 SRS도 아직 제대로 작성하지 않고 있고 리뷰도 하지 않고 있다면 수천명의 개발자들이 어떻게 뒤죽박죽 되지 않고 소프트웨어를 개발할 수 있는지 이해가 가지 않을 겁니다.

그게 소프트웨어 공학입니다. 어떠한 상황에서도 가장 짧은 시간에 적은 비용으로 소프트웨어를 개발하기 위한 실전적인 방법으로 진화를 해온 것입니다.

조금더 구체적으로 들어가보도록 하겠습니다. 모든 사람들이 이해를 하고 동의할 것으로 생각하지 않습니다. 왜냐하면 각자의 경험과 수준이 있기 때문에 보이는 것이 다르기 때문입니다. 

1. 모듈은 어떤 식으로 분리를 하는지?
천차만별이지만 원리는 있습니다. 책에서도 원리에 대해서 설명하기 위해서 노력을 했습니다. 
책이 있으니 한번 더 보시면 되겠지만 한번더 설명을 하면 "컴포넌트"와 "인터페이스"를 어떻게 나누느냐가 핵심인데, 어떤 툴이나 방법을 쓰냐는 중요하지 않습니다. 생각하는 방법도 서로 다르지만 대체로 설계단계에서 개발자들끼리 서로 모여서 종이나 칠판에 "컴포넌트"와 "인터페이스"를 그려가며 가장 깨끗하게 나오는 구조를 그려갑니다. 문제가 있으면 다시 지우고 그리고를 여러번 반복합니다.
이때 SRS가 없다면 모든 기능을 다 고려할 수 없기 때문에 제대로 아키텍쳐를 작성할 수 없습니다. SRS가 그냥 있기만 한다고 되는 것도 아니고 제대로 작성이 되어야죠. 아키텍쳐에는 회사의 미래전략도 모두 포함되기 때문에 단순히 기능만 다 있다고 되는 것도 아닙니다. SRS이슈로 넘어가면 또 하루 종일 설명을 해야 합니다.
아키텍쳐에 많은 영향을 미치는 사람들은 주로 선임 개발자들이고 개발팀 규모가 엄청나게 크면 한사람이 전체 모든 컴포넌트와 인터페이스를 분리할 수 없기 때문에 수직적으로 나뉘게 됩니다. 개발자들은 서로 여러 설계 리뷰에 참석을 하게 되고 리뷰자들은 서로 중첩이 됩니다. 선임개발자들은 최상위 아키텍쳐 리뷰에 참석도 하고 자신이 맡은 컴포넌트의 아키텍쳐 회의를 주도하고 여기에는 하위 개발자들도 참석을 합니다.
아키텍쳐 리뷰도 실제로 여러번 해보지 않으면 책을 아무리 봐도 어떻게 진행하는지 알기 어렵습니다.

2. 소스트리를 어떻게 구성하는지?
이 부분이야 말로 회사마다 천차만별입니다. 회사마다 제품의 특성이 다르고 프로세스가 다르기 때문에 같을 수가 없습니다. 소스트리를 구성할 때 고려해야 할 것들은 정말로 많고, 그 회사의 경험이 많은 고참 개발자가 아니면 좋은 결정을 할 수가 없습니다. 
소스트리는 한번 제대로 구성을 해놓으면 10년이상 지속될 수 있는 것이기 때문에 상당히 신중해야 합니다.
제품의 성격, 각 제품간의 관계, 사용하는 개발언어, 공통모듈 현황, 미래의 개발계획, 빌드 프로세스, 테스트 프로세스 등이 모두 고려되어야 합니다.
일반적으로 한번에 제대로된 소스트리를 만드는 것은 거의 불가능에 가깝습니다. 대부분은 몇년 해보다가 뒤엎는 경우를 수차례 반복합니다. 
그렇다고 Google이나 Microsoft의 소스트리를 흉내낸다고 제대로 되지는 않습니다. 아마 100% 실패할 것입니다.

3. 중복되는 소스코드를 어떻게 제거하는지?
완벽한 제거란 있을 수 없습니다. 최소화 하는 것이지요. 이것을 이해하려면 SRS, Architecture Design, Peer Review를 모두 잘 이해하고 있어야 하는데 쉽지 않습니다.
우리나라와 같이 각 개발자들이 모두 슈퍼맨에 되어서 알아서 개발하는 구조에서는 해결이 불가능한 이슈입니다.
책에서도 꽤 설명을 하고 있지만 다시 설명을 해보겠습니다. Peer Review를 한다고 가정을 하고 SRS, Architecture, Source Code 모두를 Review한다고 가정을 해보죠. 일단 Review를 충분히 한다는 것이 중요합니다. 개발자들은 이미 상당히 많은 내용을 서로 공유하고 있습니다. 보통 개발하는 시간의 20%는 Review를 위해 사용한다고 합니다. 그리고 고참이 될 수록 더 많은 시간을 Review에 할애 합니다. 
대부분은 개발할 시간도 없는데 언제 Review를 할 시간이 있냐고 합니다. 또한 "SRS는 언제 쓰고 있느냐, 빨리 개발해야지"라고 주장합니다. 그러면 "SRS쓰고 Review할 시간은 없어도, 개발하고 고치고, 개발하고 또 고치고 할 시간은 있느냐?"라고 반문을 하죠.
Review를 적절하게 하는 것이 개발을 가장 빨리 하는 방법이기 때문에 소프트웨어공학에서 주장하는 것이지요.
이런 리뷰를 거친 설계과정에서 중복되는 모듈은 컴포넌트로 빠지고 코딩과정에서도 서로 중첩된 리뷰를 하기 때문에 중복된 코드가 발생할 가능성도 적어지고 있다고 하더라도 쉽게 발견되고 공통 모듈화 할 수 있습니다.

4.공통모듈은 어떻게 공유하는지?
이또한 회사마다 다릅니다. 하지만 공통모듈이 없는 회사를 본적이 있습니다. 아니 많습니다. 각 개발자들이 다 알아서 개발을 하고 있어서 어디에 중복된 모듈이 있는지 알지도 못합니다.
공통모듈은 분석, 설계 과정을 통해서 잘 분리가 되어야 하고 당연히 이를 담당한 개발자나 개발팀이 별도로 존재합니다. 공통모듈이 이를 사용하는 개발자나 개발팀에서 잘 사용할 수 있도록 적절한 프로세스를 갖추고 있어야 합니다. 공통모듈은 소스코드 수준에서 공유하는 회사도 있고, Static library 또는 Dynamic library형태로 공유하기도 합니다. 그에 따른 적절한 공통모듈 Release프로세스를 가지고 있어야 하며 절적한 스케쥴도 유지를 해야 합니다.
회사의 공통모듈은 한개가 아닙니다. 수십개, 수백개가 될 수도 있습니다.
컴포넌트간의 공통모듈이 있고, 제품간의 공통모듈이 있고, 회사 전체 공통모듈이 있을 수 있습니다. 공통모듈은 소스코드가 될 수도 있고, Text파일일 수도 있고, 이미지파일일 수도 있습니다.
이런 공톰모듈을 적절하게 잘 사용할 수 있는 소스트리 구성이 중요합니다. 따라서 최고의 고참이 아니면 소스트리 구성이 어렵습니다.

5.코멘트는 어떤 규칙으로 작성하는지?
이부분도 회사마다 다르지만 규칙은 있다는 겁니다. 
아무것도 제대로 갖춰지지 않은 회사에서 코멘트는 정말 중요합니다. 달랑 소스코드 하나 있는 것이기 때문에 코멘트가 없으면 소스코드를 파악하기 정말 어렵습니다. 특히 해당 개발자가 퇴사를 하고나면 정말로 난감합니다.
하지만 제대로 된 소프트웨어 회사에서는 모든 것이 서로 얽혀 있고 정보들이 서로 중첩되어 있어서 코멘트만이 유일한 정보는 아닙니다. 모든 소스코드의 History는 소스코드관리시스템에 등록이 되어 있어서 Blame을 해보면 누가 언제 등록을 한 소스코드이고 해당하는 Message와 관련된 Issue의 번호를 가져올 수 잇습니다. 그리고 왠만한 소스코드는 서로 중복되어서 리뷰가 되었고, 소스코드관리시스템에 누가 리뷰를 했는지 기록이 되어 있습니다. 
즉, SRS - Architecture - SCCM - Issue Track - Source Code - Brain(뇌, 리뷰) 들이 서로 관련이 있고 얽혀 있어서 코멘트에 목숨거는 상황은 아니게 됩니다.
그래도 코멘트는 작성을 하고 규칙은 각 회사마다 별도로 가지고 있어야 합니다. 
우리나라 같은 경우 영어로 작성을 해야 하는지 한글로 작성을 해야 하는지 정해야 하고, 파일주석, 함수주석, 라인 주석에 대한 규칙을 정해야 하고, 내용, 형식에 대해서도 정의를 해야 합니다.
하지만 너무 복잡한 규칙과 지키기 어려운 엄격한 규칙은 없느니만 못하기 때문에 적절히 규칙을 정해야 합니다.

 결론 
 
위의 모든 것을 한꺼번에 할 수는 없습니다. 회사의 규모에 따라서 3~5년 이상 걸릴 것들도 있습니다. 결코 계단 10개를 한걸음에 뛰어오를 수는 없습니다. 용어만 알고 있거나 한번씩 경험해 봤다고 아는 척해서도 안됩니다. 회사 전체가 같이 움직일 수 있어야 합니다. 현실은 많은 의욕이 넘치는 개발자들이 머리속의 지식과 이상은 level 10인데 실제 실력과 경험은 level 2에서 헤매고 있는 겁니다. 그래도 다른 개발자들보다 용어도 많이 알고 말싸움에서 이기고 잘 안되는 것은 다른 사람들 탓을 하곤 합니다. 이것이 제가 여러 현장에서 겪는 현실입니다.
차근 차근 노력해 가는 것이 올바른 방법이고 전문가의 도움을 통해서 제대로 된 길로 가장 빠르게 가는 것이 유일한 방법입니다.

2010년 5월 4일 화요일

Hotfix에서의 소스코드관리

아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.







우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.
계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.
Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.
Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 
Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

 Hotfix 정식 Patch
계획되지 않은 긴급한 패치
보통 충분히 테스트 되지 않고 릴리즈
또다른 문제를 일으킬 가능성이 매우 높음
다른 개발일정에 영향을 줌
고객은 수정된 버전을 바로 받아볼 수 있음
미리 계획됨
계획된 테스트를 수행하고 릴리즈
일상적인 수준의 리스크를 가지고 있음
계획된 일정대로 개발이 가능
고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

 Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.
1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?
2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 
1. 그때 그때 다르다.
2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.
Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.
그럼 개발팀 바깥이란 무엇일까요? 
테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.
이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.
Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.
  1. 상세한 버그 내용
  2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
  3. 버그로 인해서 발생하는 고객의 예상 피해
  4. 버그를 얼마나 빨리 해결해야 하는지
  5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
  6. 버그 수정에 투입해야 하는 인력 및 자원
  7. 기존 개발일정에 미치는 영향
여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 
Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.
그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.



Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

 마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.
지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?

2010년 5월 3일 월요일

혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

소스코드관리에 대해서 얘기를 하다보면 혼자서 개발을 하기 때문에 별 고민 없이 대충 소스코드를 관리하는 경우를 많이 봤습니다.

Subversion 등의 소스코드관리시스템을 쓰더라도 그냥 소스코드를 백업 받는 수준으로 사용하고 많이 사용하면 Baseline설정(Tagging)정도 하곤하더군요. 그러면서 혼자서 개발을 하기 때문에 소스코드의 브랜치/머지가 필요 없다고 생각합니다. 하지만 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황은 꼭 발생하기 마련입니다. 만약에 이러한 상황에서 브랜치/머지를 능수능란하게 하지 못하면 기존의 수작업에 의존하는 방식으로 처리를 하면서 소스코드관리시스템이 주는 큰 혜택을 누리지 못하게 됩니다.

또, 개발자는 한명이 아니더라도 마치 혼자서 개발을 하는 것처럼 개발자들끼리 담당 소스코드를 철저히 나눠서 서로 충돌이 나는 일이 없도록 개발을 하는 경우가 허다합니다. 이런 것을 Component Owner라고 하고 이런 체제에서는 개발자들 간의 기술의 공유가 어려워지고 회사의 규모가 커질수록 개발 효율성은 점점 떨어지게 됩니다.

그럼, 어떤 상황에서 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황이 발생하는지 알아보도록 하겠습니다.

첫째, Hotfix인 경우입니다.
소프트웨어의 종류는 워낙 다양하기 때문에 획일적으로 말할 수 없습니다. 그래서 간단한 예를 하나 들어보죠. 매일 한번씩 패치를 만들어서 정해진 시간에 인터넷으로 업데이트를 하는 소프트웨어를 개발하고 있다고 칩십니다. 오늘 오후 5시에 내보낼 패치에 들어갈 Bug fix와 Feature를 열심히 넣고 있는데 긴급 Hotfix 상황이 발생한 겁니다. 따라서 정식 패치때까지 기다릴 수는 없고 일단 시급한 버그 하나만 고쳐서 서둘러서 업데이트를 해줘야 합니다. 이러한 상황에서 소스코드관리시스템을 사용하는 능숙도에 따라서 대처하는 방법들이 매우 다릅니다.

 하수

소스코드관리시스템을 거의 제대로 쓰지 못하는 경우, 오늘 고치고 있는 소스코드를 수동으로 하나씩 지워서 원래 버전을 만들어냅니다. 이러한 경우는 믿기 힘들겠지만 제가 컨설팅을 하면서 많은 회사들이 이렇게 하고 있다는 것을 접했습니다. 이렇게 원래 버전을 만들어서 Hotfix를 만들어서 내보낸 후에 다시 재작업을 합니다.

 중수
이보다 조금더 나은 경우, 원래 고치고 있던 소스코드의 디렉토리를 임시로 백업 받아 놓고 소스코드관리시스템에 있는 어제 버전의 소스코드를 다시 Check out합니다. 이렇게 Check out한 소스코드를 가지고 Hotfix를 만들어서 내보내고 오늘 작업하던 백업을 받아 놓은 소스코드와 Merge tool을 이용해서 Merge를 한 후에 정기 업데이트 버전을 만들어서 내보내는 방법입니다. 아까보다는 조금 나아 졌지만, 여전히 수작업에 많이 의존을 하고 귀찮은 작업들을 해줘야 합니다.

 고수
Subversion등의 소스코드 관리시스템을 제대로 사용한다면 이보다 좀더 손쉽습니다. 
우선 어제 릴리즈를 한 소스코드의 Baseline(Tag)에서 Hotfix용 브랜치를 만듭니다. 기존에 개발하고 있던 디렉터리는 그대로 놔두고 새로운 디렉터리에 Hotfix를 Check out 받습니다. 보고된 버그를 수정하여 자동화된 빌드스크립트를 이용해서 Hotfix를 만들어내고 업데이트에 올립니다. 정상적으로 Hotfix가 배포된 것을 확인하고 Hotfix 브랜치는 Trunk로 Merge를 합니다. 이때 3Way Merge 툴을 이용하면 됩니다. 
3Way Merge를 적용하려면 3개의 기준점이 필요합니다. 3개의 기준점은 다음과 같습니다.

Base - 어제 릴리즈한 Baseline(Tag)
Their - 오늘 Hotfix 릴리즈한 Baseline(Tag)
Mine - Trunk의 Head revision(최신소스)

3Way Merge를 통하면 거의 99% 자동으로 Merge가 되고 Conflict가 나는 소스코드들도 KDiff3나 P4Merge등의 GUI가 뛰어난 3Way Merge툴을 이용하여 쉽게 Merge를 할 수 있습니다.

그리고 현재 로컬에서 고치고 있던 소스코드와 통합을 해야 합니다. 이를 Rebase라고 하는데 SVN에서는 Update명령을 내리면 서버에서 바뀐 내용이 자동으로 Working copy와 통합이 됩니다. 이때도 3Way Merge를 이용하게 됩니다.

즉, 개발자는 소스코드 내용 고치는데만 신경을 쓰면 되고 나머지는 소스코드관리시스템이 다 알아서 해 줍니다. 소스코드 통합하는데 불과 얼마 걸리지 않고 혼동도 없습니다. 시간은 하수,중수의 수십분의 1이면 가능하게 됩니다.

혼자 개발하더라도 제대로 하지 않으면 이렇게 혼동이 있고 소스코드관리시스템의 기능을 잘 사용만하며 이렇게 손 쉬운데 개발자가 수십명, 수백명이서 하수, 중수의 방법으로 어떻게 소프트웨어를 제대로 개발할 수 있을까요?

물론 이것이 다는 아니죠. 기능을 충분히 사용하는 것은 이제 시작입니다. 더 큰 조직에서 조직적으로 제대로 사용하려면 프로세스, 규칙, 문화 등과 접목되어서 돌아가야 하는데, 이는 더 어렵습니다. 그러데 하물며 기능도 제대로 사용을 못하는 회사가 대부분인데 그 다음은 말할 필요하고 없죠.

Hotfix 경우 외에도 기존 소스코드에 큰 변경을 가해서 성공 여부를 확신할 수 없는 기능을 추가할때.
시간이 오래 걸리는 기능을 추가하면서 중간 중간에 다른 변경에 대한 릴리즈를 해야 할 때.
등 혼자서 개발을 하더라도 Branch/Merge를 해야 할 경우는 수도 없이 나오게 됩니다.

소스코드관리를 너무 쉽게 생각하면 안됩니다. 잘해 놓으면 무척 쉽고 개발에 매우 큰 도움을 주지만, 대충대충 하다보면 큰 발목을 잡히게 됩니다. 혼자 개발하더라도 제대로 하겠다는 마음가짐을 가지고 완벽하게 전체 기능을 다 알아야 합니다. 그리고 나면 이좋은 것을 왜 지금까지는 제대로 하지 않았을까 아쉬움이 들겁니다.

책을 보고 해보는 방법도 있지만 시간이 좀 많이 걸리겠지요. 주변에서 잘아는 사람에게 물어보는 것은 시간을 절약할 수 있는 좋은 방법입니다. 주변에 그런 사람이 없다면 블로그에 궁금한 것을 올려주세요. 제가 힘이 닿는한 잘 설명드리겠습니다. 제가 쓴 책(소프트웨어개발의 모든 것)에서는 이러한 부분이 이론적이 아닌 실제 방법을 자세히 설명하고 있으니 보시는 것도 도움이 많이 될 것입니다.

2010년 4월 20일 화요일

맥에서 Subversion 사용하기

최근에 맥북을 구매해서 아이폰 개발 작업을 하고 있는데 맥에서 Subversion을 사용하는 환경이 그리 좋지 않다는 것을 알게 되었습니다. 그래서 맥에서 Subversion을 제대로 활용하기 위한 글을 적어보려고 합니다.

Subversion 자체에 대해서는 블로그의 다른 글들을 보시기 바랍니다.

일단 Xcode에는 기본적인 Subversion연동 기능이 포함되어 있습니다. 그런데 막상 써보면 기존에 TortoiseSVN의 뛰어난 기능과 성능에 익숙한 사람들은 불만스럽기 짝이 없습니다. 그래서 맥에서 Subversion을 쓰기 위한 방법을 비교해보도록 하겠습니다. 

  • Xcode 기본 기능 
  • 유/무료 맥용 SVN Client 사용 - Syncro, Diffly
  • 터미널
  • 가상머신 + TortoiseSVN 
Subversion 서버는 이미 구축되어 있다고 가정합니다. Subversion서버가 아직 구축되지 않았다면 제 을 참조하여 Subversion을 구축하시기 바랍니다. 또는 Google Code를 이용하는 방법도 있습니다. Google Code를 이용하면 소스코드가 공개가 되니 소스코드를 공개해도 되는 경우라면 Google Code를 이용하면 편리할 것입니다.

 Xcode의 기본 기능 사용

사실 Xcode의 기본 Subversion연동 기능은 그렇게 편리하지 않습니다. 그래도 사용법에 대해서 잠시 알아보죠.


우선 Xcode의 Preferences의 SCM항목에서 이미 구축된 Repository를 등록해야 합니다. 그래야 Xcode에서 해당 Repository와 Xcode 프로젝트를 연결 할 수 있습니다.

그리고 Xcode>SCM>Repositories에서 해당 Repository의 디렉터리를 만들어야 합니다. 

위 그림과 같이 branches, tags, trunk로 나누면 됩니다. 디렉터리를 어떻게 나누냐 하는 이슈는 전략이 필요한 항목이므로 신중하게 판단해야 합니다.

소스코드를 서버에 등록하기 전에 먼저 설정할 것이 있습니다. Subversion에 등록되면 안되는 파일을 설정해야 합니다. ~/.subversion/config파일을 열면 global-ignores 항목이 있습니다. 여기에 등록되면 안되는 파일의 패턴을 적어주면 됩니다. 저는 일단 build 디렉터리만 등록되지 않도록 했습니다. 그외에도 빌드시 생기는 임시 파일들이 있거나 하면 그 패턴을 등록해서 Subversion에 등록되지 않도록 해야 합니다.


그리고 Import 메뉴를 이용해서 Mac에 저장되어 있는 소스코드를 모두 Subversion 서버에 등록합니다. 
이제 서버의 소스코드를 내려 받아야 하는데, 기존에 소스코드가 있던 디렉터리에는 내려 받을 수 없으니 소스코드의 디렉터리를 임시로 바꿔놓고 Check out을 통해서 소스코드를 내려받습니다. 소스코드를 내려 받았다고 해서 Xcode와 바로 연결되지는 않습니다. Xcode연동 기능을 사용하지 않을 거라면 여기까지만 하면 되지만 Xcode와 연동해서 사용하려고 하면 Xcode Project와 Subversion repository를 연결해 줘야 합니다.

Xcode에서 Check out하여 내려 받은 프로젝트를 Open하고 Project info를 보면 우상단에 "Configure Roots & SCM..."이 있습니다.



그 버틑을 클릭하면 이미 등록한 리파지토리중에서 본 프로젝트와 연결한 리파지토리를 선택하도록 되어 있습니다. 간단하게 고르면 됩니다.



그리고 Groups & Files에서 마우스 오른쪽 버튼을 눌러서 SCM을 선택하면 SCM과 연동 상태를 확인할 수 있습니다.


이제 Xcode의 SCM 메뉴를 통해서 소스코드를 관리할 수 있게 됩니다.
기본적으로 소스코드를 Check out하고 Commit하고 Tag, brach까지 이 기능을 이용해서 할 수 있도록 되어 있습니다. 하지만 제가 간략하게 본 바로는 Conflict를 해결하고 Merge를 하는 등의 협업이 필요한 작업은 지원이안되는 것 같더군요. 혹시 제가 모르는 방법이 있다면 알려주세요. 
그래서 이럴 때는 다른 솔루션들을 추가로 사용해야 하겠더군요.

 맥용 SVN Client 사용

Syncro, Diffly등 몇몇 유/무료 SVN Client가 있습니다. 하지만 이 부분은 제가 Evaluation을 해보지 않았습니다. 추후 써보게 되면 내용을 보강하도록 하지요.

 터미널 사용

Command line에서 SVN을 사용할 수 있다면 Windows, Linux, Mac 어느 OS에서든지 동일하게 SVN을 사용할 수 있습니다. SVN의 모든 기능은 Command line에서 사용할 수 있도록 되어 있습니다. 단지 Merge등의 몇몇기능이 GUI환경에서 더 편한 것 뿐입니다. Mac에서도 Command line 명령어를 이용하여 SVN을 사용할 수 있습니다.



 가상머신 + TortoiseSVN 사용

마지막으로 제가 최종적으로 선택한 방법은 TortoiseSVN을 이용하는 방법입니다.
Windows에서 TortoiseSVN을 오랫동안 사용한 개발자라면 그 편리함을 잊지 못할 겁니다.
저는 Parallels Desktop에 Windows7을 설치한 다음에 TortoiseSVN을 사용하고 있습니다.
Mac의 모든 디렉터리가 Windows에서 접근 가능하니 Windows에서 사용하는 것과 거의 동일하게 TortoiseSVN을 사용할 수 있습니다. 이렇게 하여 Windows에서 사용하던 Merge tool도 그대로 쓸 수 있게 되었습니다.
Windows에서 TortoiseSVN을 사용할 경우는 Mac에서 SVN을 설정하는 것과 별도로 Windows에서 SVN을 설정해줘야 합니다. C:\Users\{사용자ID}\AppData\Roaming\Subversion\config 파일을 열어서 아까와 같이 global-ignores를 설정하면 됩니다.


저는 기본적인 SVN Commit기능만 쓸때는 Xcode기본 기능을 사용하고 브랜치, 태그, 머지 기능을 사용할 때는 Tortoise SVN을 사용하고 있습니다. 또한 개발자가 여러명이라면 그냥 TortoiseSVN을 사용하는 것도 좋을 것 같습니다.

이상으로 Mac에서 Subversion을 사용하는 방법을 알아봤습니다. Subversion을 제대로 사용하는 방법은 완전히 별개 이슈이니 제 책과 블로그의 다른 글들을 참고하세요.

수정하거나 덧붙일 내용이 있으면 댓글 남겨 주세요.

2010년 3월 29일 월요일

소스코드는 어디 있나요?

나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다.

"소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다.

그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다.
대부분 아래와 같은 답변들이 돌아옵니다.
  • 내 PC에 소스코드가 저장되어 있습니다. 
  • 아직 정리가 안되서 소스코드관리시스템에 등록하지 않았습니다.
  • 빌드는 IDE(Eclipse 등)에서 해야 합니다.
  • 빌드하기 위해서는 이런 저런 라이브러를 알아서 직접 설치해야 합니다.
  • 아참, 설정을 이렇게 바꿔야 하는데 깜빡했습니다.
  • 지금 내가 소스코드를 고치고 있어서 공유가 어렵습니다.
이런 얘기가 진행되는 동안에 일은 정상적으로 진행이 되지 못하고 여러 번 만나서 대화로 소스코드 공유 문제를 해결해나가야 합니다. 

혼자서 또는 개발자들끼리 익숙해져서 나름대로 방식으로 소스코드를 관리하면서 스스로 아무 문제가 없다고 생각하고 있는 개발자들은 냄비 안에서 물이 점점 뜨거워져서 죽는 개구리처럼 소스코드관리 문제가 점점 커져서 문제가 얼마나 심각한지 인식하고 있지 못하고 있는 겁니다. 이는 기본 중에 기본으로 자꾸 소스코드 관리 문제를 가지고 얘기를 하면 민망하고 한심하기도 합니다.

소스코드를 꽉 쥐고 요청하는 사람들에게 '모이'주듯이 하나씩 던져 주는 개발자들은 이로 인해서 얼마나 많은 자신의 시간을 낭비하고 있고 정작 자신이 제대로 개발할 시간은 모자라고 회사에도 손해를 끼치며 자신의 발전도 가로막는다는 것을 알아야 합니다.

정상적인 경우는 다음과 같습니다.

개발자가 1명이든 100명이든 1000명이든 상관없이 모든 소스코드는 당연히 소스코드관리시스템에 등록이 되어 있어야 합니다. 
구차하게 이거 저거 물어보지 않아도 소스코드가 저장된 경로만 알면 누가나 소스코드를 Check out해서 클릭 몇 번이면 Build Script를 찾아내서 즉시 빌드를 할 수 있어야 합니다. 당연히 컴파일러 등의 빌드 환경은 설치가 되어 있어야죠.
여러명이 동시에 소스코드를 마구 고쳐도 전혀 걱정할 필요가 없어야 합니다.

이때 구차하게 이거 저거 물어 봐야 빌드가 되고 IDE를 실행 해야 하고, 빌드 중간에 명령어를 입력해야 하는 등의 바로 알기 어려운 행위들을 해야 하면 안됩니다.

이 정도는 되어 있어야 Daily Build가 가능해지고 프로젝트 내내 소스코드 관리 비용을 최소화 할 수 있습니다.
이 정도는 되어 있어야 엄청 복잡한 소스코드 상황을 깔끔하게 관리할 수 있습니다.
이 정도는 되어 있어야 내가 휴가를 가도 아무나 빌드를 할 수 있습니다.
이 정도는 되어 있어야 개발자들이 빌드를 하지 않고 빌드 담당자에게 빌드를 맡길 수 있습니다.
이 정도는 되어 있어야 누구와도 심지어는 외부인과도 협업을 할 때 말 한마디면 소스코드 공유 준비는 끝납니다.
이 정도는 되어 있어야 개발자는 진짜 개발에 집중할 수 있습니다.

이게 뭐 큰 일이냐라고 생각할지 모르지만 이렇게 생각하는 개발자는 위에서 얘기한 기초 중의 기초가 안되어 있다고 생각하면 됩니다.

소스코드 관리는 워낙 기초이기 때문에 누구나 제대로 방법만 익히면 제대로 수행하는데 오래 걸릴 일도 아닙니다. 똑똑한 개발자라면 일주일이면 방법을 다 터득합니다. 분석, 설계 작업이 방법을 제대로 익히고도 제대로 하는데 수년이 걸리는 것과는 안전히 딴판입니다. 그럼에도 아직도 많은 개발자들이 소스코드 관리를 제대로 하고 있지 못하거나 제대로 하려고 흉내는 내는데 엉뚱한 곳에서 헤매는 경우가 많습니다. 원리는 매우 간단한데 말입니다.

소프트웨어 개발이라는 것이 협업이라는 것을 깨달으면 됩니다. 혼자서 개발하더라도 협업과 똑같습니다. 그렇게 해야 더 혼자 개발하더라도 더 빨리 개발할 수 있고 여럿이 개발할 때는 더욱 더 중요합니다.

소스코드관리시스템을 쓰기는 하는데 어중간하게 흉내만 내고 있다고 생각한다면 한번 확실하게 제대로 배워 놓을 필요가 있습니다. 그렇지 않으면 평생 기초 중에 기초에 문제거리를 안고 가는 겁니다.