본문 바로가기

기반시스템

소스코드관리시스템 사용도 2차 조사 결과 2009년 2월에 이와 동일한 조사를 한 적이 있었습니다. 2009/02/22 - [기반시스템/소스코드관리] - 소스코드 관리 방법 조사 결과 그때도 약 20일간 조사를 했었고, 이번에도 마찬가지로 20일간 조사를 했습니다. 2009년에는 109명이 참여를 했는데 이번에는 370명이 넘는 인원이 참여를 해서 더 정확한 결과가 나왔을 것으로 기대합니다. 이번 설문의 핵심은 소스코드관리시스템을 사용하는지? 사용하지 않는지? 또, 사용한다면 어떤 시스템을 사용하고 있는지를 알아내는 것이었습니다. 2009년초와 비교를 해보면 꽤 많은 변화가 있었음을 알 수 있습니다. 가장 큰 변화를 요약하면 다음과 같습니다. 소스코드관리시스템 사용률의 향상 CVS, VSS의 몰락 Git의 약진 Subversion(SVN)의 꾸.. 더보기
2차 소스코드관리시스템 사용도 조사 Poll 약 2년전쯤 제 블로그에서 어떤 소스코드관리시스템을 사용하고 있는지 조사를 한 적이 있습니다. 시간도 꽤 흘러서 그동안 어떤한 변화가 있었는지 알고 싶어집니다. 특히 그동안 소스코드관리시스템을 사용하는 비율이 어느정도 높아졌는지가 가장 궁금하더군요. 또한 최근에 분산소스코드관리시스템에 대한 관심의 증가가 실제로 사용도에 영향을 주는지도 궁금합니다. 설문은 간단하게 사용하시는 소스코드관리시스템을 체크하면 됩니다. 만약에 보기에 없다면 Other 항목에 직접 적어 넣으시면 됩니다. 많은 참여 부탁합니다. image by Stéfan * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 더보기
마이크로소프트, 구글의 소스코드 트리의 비밀? 오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요. 책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다. 독자 블로그 글 : 소프트웨어 개발의 모든 것 -전규현 질문은 다음과 같습니다. 나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다. 그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다. 사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이.. 더보기
Hotfix에서의 소스코드관리 아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다. 2010/05/03 - [기반시스템/소스코드관리] - 혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까? 차우차우 2010/05/03 22:49 좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다. 우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니.. 더보기
혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까? 소스코드관리에 대해서 얘기를 하다보면 혼자서 개발을 하기 때문에 별 고민 없이 대충 소스코드를 관리하는 경우를 많이 봤습니다. Subversion 등의 소스코드관리시스템을 쓰더라도 그냥 소스코드를 백업 받는 수준으로 사용하고 많이 사용하면 Baseline설정(Tagging)정도 하곤하더군요. 그러면서 혼자서 개발을 하기 때문에 소스코드의 브랜치/머지가 필요 없다고 생각합니다. 하지만 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황은 꼭 발생하기 마련입니다. 만약에 이러한 상황에서 브랜치/머지를 능수능란하게 하지 못하면 기존의 수작업에 의존하는 방식으로 처리를 하면서 소스코드관리시스템이 주는 큰 혜택을 누리지 못하게 됩니다. 또, 개발자는 한명이 아니더라도 마치 혼자서 개발을 하는 것처럼 개발자.. 더보기
맥에서 Subversion 사용하기 최근에 맥북을 구매해서 아이폰 개발 작업을 하고 있는데 맥에서 Subversion을 사용하는 환경이 그리 좋지 않다는 것을 알게 되었습니다. 그래서 맥에서 Subversion을 제대로 활용하기 위한 글을 적어보려고 합니다. Subversion 자체에 대해서는 블로그의 다른 글들을 보시기 바랍니다. 일단 Xcode에는 기본적인 Subversion연동 기능이 포함되어 있습니다. 그런데 막상 써보면 기존에 TortoiseSVN의 뛰어난 기능과 성능에 익숙한 사람들은 불만스럽기 짝이 없습니다. 그래서 맥에서 Subversion을 쓰기 위한 방법을 비교해보도록 하겠습니다. Xcode 기본 기능 유/무료 맥용 SVN Client 사용 - Syncro, Diffly 터미널 가상머신 + TortoiseSVN Subve.. 더보기
소스코드는 어디 있나요? 나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다. "소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다. 그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다. 대부분 아래와 같.. 더보기
한방에 빌드 Visual Studio나 Eclipse를 실행해야만 빌드를 할 수 있습니까? "Yes"라고 대답하는 개발자들은 대부분은 이것이 무슨 문제인지 모르고 있는 상황입니다. Joel Test 12개 항목 중 하나를 차지할 정도 한방에 빌드를 만들어 내는 것은 중요합니다. Visual Studio나 Eclipse에서 버튼 하나만 누르면 빌드가 된다고 이것을 한방에 빌드를 만들어 내는 것이라고 착각하면 곤란합니다. 일단 Command line이 아니고 빌드를 위해서 사람의 손을 통해서 무슨 프로그램을 실행해야 한다면 한방의 빌드와는 거리가 먼 겁니다. 그럼 왜 한방에 빌드를 만들어 낼 수 있을까요? 빌드는 반복적인 작업이며 대단히 귀찮은 작업이면서 전문적인 작업이기도 하고 실수하기 쉽기도 하며 개발에서 많은 시간.. 더보기
베이스라인 "Baseline"이라는 용어가 생소한 개발자들이 있을 수 있습니다. 우리말로 번역을 하면 "기준선"이라고도 하는데, 헷갈리므로 그냥 Baseline이라고 사용해도 무관할 것입니다. 소스코드는 살아 있습니다. 매 순간 변화하고 있다고 봐도 됩니다. 실제로 몇 천명의 개발자가 참여하는 프로젝트에서는 소스코드 관리시스템의 로그를 보면 거의 매 순간 소스코드가 바뀌는 것을 알 수 있습니다. 또 작은 프로젝트라고 하더라도 어느 순간에 소스코드가 바뀔지는 알 수 없습니다. 그래서 Baseline을 관리하지 않으면 소스코드의 어느 의미 있는 순간을 잡아내는 것이 쉽지 않습니다. 그래서 Baseline을 관리합니다. Baseline을 설정하는 방법은 여러 가지가 있습니다. 소스코드를 통째로 특정 디렉터리에 복사를 해.. 더보기
이 소스코드는 나 밖에 못 건드려! "우리 팀은 각자 맡고 있는 소스코드가 다 달라서 서로 충돌 날 일이 전혀 없어요" "이 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게" "내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려" "지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 수 없어요. 이거 다 끝날 때까지 기다려주세요." 이와 같은 현상이 친숙하나요? 그럼 Parallel Development(병행개발)와는 거리가 멉니다. 개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 때 항상 Lock을 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다. 아키텍처적인 이슈를 제외하고는 개발자.. 더보기