본문 바로가기

기반시스템

서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System) 소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다. 이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다. 만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다. 그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단.. 더보기
이클립스 프로젝트 필수 유틸리티 개정판 : Subversion, Ant, JUnit, Trac 자바 개발자를 위한 책을 소개합니다. --------------------------------------------------------------------------- Trac을 비롯한 필수 유틸리티로 프로젝트 환경에 단비를 내리는 책 이 책은 Trac(위키와 이슈 트래커), Subersion, Mylyn, Subclipse 플러그인, CVS, Ant, JUnit을 사용해서 자바 프로젝트 환경을 개선하는 책이다. 이 책의 내용은 유틸리티의 설치와 사용법 그리고 이클립스에서 유틸리티를 통합해서 사용하는 방법에 중심을 두고 있다. 마지막 장에서 다루는 프로젝트는 책에서 다루는 모든 유틸리티와 플러그인을 사용해서 실제 개발 프로젝트를 보인다. 어떻게 개발자의 프로젝트 환경을 변화시키는지 직접 확인할 수 .. 더보기
VSS, CVS, SVN 비교 Google Trend에서 세가지 SCM(Software Configuration Management)의 경향을 살펴봤습니다. (아래 그림 참조) CVS가 여전히 압도적인 우위를 점하고 있고, 상대적으로 SVN은 꾸준히 성장을 하고 있습니다. 물론 Google Trend가 실제 제품의 점유율을 보여주지는 않지만 그만큼 사람들의 관심사는 엿볼 수 있을 것 같습니다. CVS의 감소는 SVN으로 대체되고 있는 듯 보입니다. 하지만 이렇게 더딘 이유는 CVS도 충분히 좋은 SCM이고 더 좋은 SCM이 나왔다고 함부로 바꿀 수 있는 것이 아니기 때문입니다. 물론 새로 시작하는 회사가 있다면 SVN을 쓰면 좋겠지만, 기존에 수년가 CVS를 쓰던 회사가 치명적인 문제도 없는데 SVN을 그냥 바꿀 필요는 없겠지요. (.. 더보기
하루에 몇 번 커밋하세요? 한 개발자가 하루에서 수도 없이 커밋(Commit)을 하고 있다면 소스코드관리시스템을 백업서버로 쓰고 있을 가능성이 높습니다. 사실 이러한 경우를 매우 자주 봤습니다. 혹시 코딩을 하다가 점심 먹으러 간다고 한번 커밋하고 중간 중간에 수시로 커밋을 하고 있으면 이건 좋은 방법은 아닙니다. 혹시 이런 방법으로 소스코드관리시스템(SVN, CVS, VSS, ClearCase 등)을 사용하고 계신지 확인해보십시오. 본인이 아니라도 이렇게 백업용도로 사용하고 있는 동료나 후배가 없는지 확인해보십시오. 커밋을 하면 소스코드의 Revision이 바뀌게 되는데, 각각의 Revision은 의미를 가지게 됩니다. 그 의미가 "점심 먹으러 나가면서 임시로 저장" 이렇게 되면 곤란합니다. 각 Revision의 정보는 우리회사.. 더보기
효과적인 버그 처리 방법 HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다. 의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다. 개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다. 주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다. 여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠. 개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기.. 더보기
우리 개발자는 뭐든 뚝딱 잘 만들어요. 소프트웨어를 개발하기 위해서는 기본적으로 갖춰야 할 인프라스트럭쳐시스템(Infrastructure System, 기반시스템)에 대해서 이미 본 블로그에 글을 올린 적이 있습니다. 그런데 여러 회사를 만나보니 이러한 시스템 중에서 일부를 직접 만들어서 사용하려는 경우를 종종 접하게 됩니다. 이런 회사를 "Tool company"라고 부릅니다. 자신들의 주력 제품이 아니고 개발하기 위해서 필요한 툴들을 만들어서 사용하려는 회사를 말합니다. 물론 워낙 특수한 형태의 툴로서 세상에 존재하지 않거나 구할 수가 없는 예외적인 경우도 있습니다. 하지만 개발 프로세스에 일반적으로 필요한 시스템들은 직접 만들어서 사용한다는 것은 큰 문제입니다. 특히, 버그관리시스템이나 프로젝트관리시스템을 만들어서 사용하거나, 만들려고 .. 더보기
Diff and Merge in SCM(Software Configuration Management) 헝그리맨님의 Subversion(TortoiseSVN)의 Diff에서 한글이 깨지는 문제... 에 관한 포스팅에 대하여 답변 겸 SCM에서의 Diff와 Merge에 대해서 글을 남겨 봅니다. 일단 헝그리맨님의 글에 대한 답변을 먼저 해야 겠군요. 사실 그동안 소스코드를 Diff하고 Merge하는데는 GUI Diff, Merge툴의 한글 깨지는 문제는 크게 신경을 쓰지 않았습니다. 대부분의 소스코드는 거의 영어로 되어 있고, 주석에 일부 한글이 들어 갔어도 이부분이 수정되서 Diff, Merge가 필요한 부분이 거의 없었고, 대부분의 머지는 줄단위로 이루어져서 줄 내에서 한글을 깨지게 표현하는 것은 사실 문제가 안되었습니다. 3-way merge를 할때는 오랫동안 Unified diff를 사용했기 때문에 .. 더보기
Release Branch, Function Branch and Customer Branch 서영아빠님의 "브랜치를 이용하여 운영환경에 선별적으로 배포하기"란 글을 보고 소프트웨어 프로젝트에서 브랜치란 어떤 의미를 가지는지 "소프트웨어 개발의 모든것"이라는 책에서 이에 대하여 소개한 내용이 있는데 이를 인용하여 설명을 하려고 합니다. 여기서 소개하는 브랜치에 대한 얘기의 핵심은 브랜치의 위험성에 대한 "경고"입니다. 브랜치는 위험하지만 소프트웨어 개발에서는 흔히 꼭 필요하게 되어서 철저히 통제가 되어야 한다는 것입니다. 브랜치(Branch) 브랜치란 필요에 의해서 소스코드를 분기하는 것이다. 브랜치를 얼마나 잘 통제하는가가 훌륭한 소프트웨어 회사와 평범한 소프트웨어 회사를 구별하는 핵심 요소 중 하나이다. 브랜치를 해야 하는 경우를 예로 들면 다음과 같다. 제품을 출시 후 유지보수를 하면서 동시.. 더보기
빌드와 컴파일의 차이 kenu님의 블로그에 빌드와 컴파일에 대한 차이를 묻는 글이 올라와서 간단히 설명해보려고 합니다. http://okjsp.tistory.com/1165643615 컴파일 : 소스코드 파일 등의 원시파일을 실행파일, 라이브러리 등의 Object 파일로 바꾸는 작업 빌드 : 소스코드 파일들을 컴퓨터에서 실행할 수 있는 소프트웨어로 변환하는 일련의 과정 컴파일은 빌드의 부분 집합입니다. 빌드 과정은 제품마다 서로 다르지만 간단한 예를 하나 들어보면 다음과 같습니다. 보통 아래 과정은 Build Script에 의해서 한번에 자동으로 실행됩니다. 실제 예는 아래 나열한 것보다 수십배는 더 복잡합니다. ^^ 소스코드관리시스템에 태그(베이스라인) 작성 작성된 태그(베이스라인) 체크아웃을 통해 빌드 전용시스템으로 소소.. 더보기
빌드가 먼저일까? 베이스라인 설정이 먼저일까? 빌드와 베이스라인 순서에 대해서 이슈가 있다는 글을 보고 아래 글을 작성합니다. 몇몇 빌드관련 솔루션들이 빌드를 해서 성공을 하면 베이스라인(Tag, Label)을 설정하는 것이 있더군요. 이는 원칙에 어긋나는 겁니다. 원칙은 베이스라인을 설정한 후에 해당 베이스라인을 가지고 빌드를 하는 것입니다. 작은 소프트웨어는 사실 이러한 것이 거의 문제가 되지 않습니다. 하지만 대규모 프로젝트는 빌드에 24시간이 넘게 걸리는 것도 있습니다. Windows NT 개발팀은 Daily Build가 48시간이 걸려서 몇대의 장비가 교대로 Daily Build를 수행했다고 할 정도 입니다. 이 경우 빌드가 끝나고 나서 베이스라인을 설정하려고 하면 이미 소스코드는 엄청나게 바뀌어 있게 됩니다. 베이스라인 설정, 태깅 한 후.. 더보기

티스토리툴바