윈도우 프로젝트 필수 유틸리티 1장 - 소프트웨어 개발 자동화

1장 소프트웨어 개발 자동화

이재홍 http://www.pyrasis.com 2007.10.27 ~ 2008.04.20

목차

1. 일하기 편한 환경 만들기
2. 버전 관리 시스템
   1. 버전 관리 시스템의 필요성
   2. 버전 관리 시스템의 유형
   3. CVS vs. Subversion
   4. CVS와 비교한 Subversion의 장점들
   5. 주요 버전 관리 시스템들
   6. 버전 관리 시스템의 용어들
   7. Subversion 저장소에 대한 이해
   8. Subversion 저장소의 디렉터리 배치
3. 이슈 관리 시스템
   1. 이슈 관리 시스템의 필요성
   2. 이슈 관리 시스템의 종류
4. 빌드 자동화 시스템
   1. 빌드 자동화 시스템의 필요성
   2. 빌드 자동화 시스템의 종류

일하기 편한 환경 만들기

어떤 소프트웨어 개발팀이 있습니다. 물론 전담 테스트팀도 갖추고 있습니다.

이 개발팀의 환경은 이렇습니다. 소스 코드는 개발자 각자 PC에서 알아서 관리하고, 고객에게 판매되는 제품도 개발자 PC에서 직접 빌드합니다. 그리고 빌드된 exe와 dll 파일을 취합하여 FTP 서버에 업로드합니다. 이제 테스트팀은 FTP 서버에 접속하여 빌드된 파일을 받아들고 테스트를 시작합니다. 별 문제없이 돌아갈 듯한 환경입니다. 모든 구성원이 정신 바짝 차려서 일한다면 말이죠.

이런 환경에서 일을 하다보니 여러가지 문제점이 보이기 시작합니다.

개발자는 개발을 하면서 소스 코드가 든 폴더를 날짜별로 복사해가며 관리하기 시작합니다. 그래도 이런 사람은 양반입니다. 어떤 개발자는 그냥 귀찮아서 소스 코드가 든 폴더 하나로 개발을 진행합니다.

테스트팀은 개발팀에서 전달받은 파일로 테스트를 합니다. 마침내 여러 가지 버그를 발견하였고, 버그에 대한 내용을 종합하여 엑셀로 작성한 뒤 개발팀에게 넘겨줍니다. 하지만 정해진 전달 경로가 없기 때문에 메일로 보내기도 하고, 메신저로 보내기도 합니다. 더 나아가서 버그 내용을 말로 전달하고 끝낼 때도 있습니다.

개발 업무에 쫓기는 개발자는 버그 내용을 기록한 엑셀 파일을 자신의 PC 어딘가에 방치한 채 그냥 넘어가기도 하고, 말로 전해들은 버그 내용은 쉽게 잊어버립니다. 이런 일이 반복되면서 제품의 버그는 점점 늘어납니다. 결국에는 모든 것을 뒤엎고 새로 개발하자는 말이 나오기도 합니다.

테스트팀 입장에서는 버그 보고를 해도 함흥차사가 되어버리고, 테스트를 제대로 안해서 제품의 질이 떨어졌다는 비난만 받게 되니 일할 의욕을 잃게 됩니다.

그래도 이런 저런 고생 끝에 제품이 출시되었습니다. 이제 기술 지원 파트와 고객 지원 파트를 통해서 여러 가지 버그가 보고되기 시작합니다. 그래서 개발팀은 버그를 수정하기 위해 담당자가 누구인지 찾게 되었는데, 버그가 발생한 파일의 담당자는 이미 퇴사를 하여 소스 코드가 다른 사람에게 인수인계된 상태였습니다. 물론 새 담당자가 버그를 처리하면 됩니다. 하지만 문제는 이것이 아니었습니다. 퇴사한 개발자는 소스 코드가 든 폴더 하나로 개발을 진행하던 사람이었고, 새 담당자도 이 소스 코드 폴더 하나만 달랑 받은 상태였습니다. 이미 소스 코드의 구조는 엄청나게 바뀌어 있었고, 하위 호환성도 고려되지 않은 채 개발되었기 때문에 버그를 고치려면 구 버전을 다시 만들어야 하는 상황이 되어버린 것입니다.

인수인계 과정에서 소스 코드가 분실되는 경우도 비일비재 합니다. 새 담당자에게 소스 코드를 넘겨 줄 때 모두 넘겨주지 않고 실수로 한두 개 빼먹은 상태로 넘겨주기도 합니다. 사고가 터졌을 때는 이미 퇴사자의 PC가 회수되어 소스 코드를 찾을 수 없을 때도 있습니다.

빌드된 파일 자체도 관리가 되지 않아 FTP 서버에 보관된 파일은 언제나 최신 버전뿐입니다. 버그가 보고되어도 해당 버전의 파일이 없으니 버그를 재현하는 것도 힘들어집니다. 고객 PC에서 해당 파일을 가져오는 수 밖에 없습니다. 물론 소스 코드 관리가 제대로 되지 않으니 해당 버전을 빌드해서 만들어내는 것도 쉬운 일이 아닙니다. 게다가 심볼 파일(PDB)도 따로 보관을 하지 않는 경우가 많아서 덤프 파일을 입수해도 분석이 힘들 때가 많습니다. 또 디스어셈블된 코드를 보고 버그를 찾는 것도 한계가 있습니다.

고객에게 판매되는 제품을 개발자 각자가 빌드하다 보니 바이러스에 감염된 파일이 제품에 포함되어 배포되는 사고가 발생하기도 합니다. 정말 믿기지 않는 상황들이지만 필자도 겪은 일들이고, 지금도 어디선가 이러한 일들이 벌어지고 있을 것입니다.

이제 엉뚱한 곳에 시간을 빼앗기지 않고 개발에만 집중할 수 있는 일하기 편한 환경을 구축한 개발팀의 일하는 모습을 들여다보겠습니다.

일하기 편한 환경을 구축한 이 개발팀은 소스 코드를 Subversion으로 관리합니다. 그리고 각 개발자는 TortoiseSVN을 사용하여 소스 코드를 체크아웃 및 업데이트하고 수정된 내용을 커밋 합니다. 고객에게 판매되는 제품은 빌드 서버에서 빌드합니다. 파일의 버전도 개발자가 올리지 않고 빌드 서버가 알아서 올려줍니다. 빌드 서버는 빌드된 파일을 버전 별로 차곡차곡 모아둡니다. 물론 심볼 파일(PDB)도 심볼 서버 형식으로 보관해줍니다.

버그 보고는 Trac으로 받습니다. 테스트팀은 버그를 발견하면 해당 프로젝트의 Trac 사이트에 접속하여 버그에 대한 내용을 자세히 기록한 티켓을 생성합니다. 개발팀은 버그 티켓을 확인하여 버그를 수정한 뒤 버그를 수정했다고 답글을 달아놓습니다. 다음날이 되면 자동빌드가 되어 버그가 수정된 새 버전이 올라와 있을 것입니다. 급할 때는 강제 빌드 명령으로 즉시 빌드를 할 수 있습니다. 테스트팀은 빌드 서버에 접속하여 버그가 수정된 새 버전을 받아 테스트한 뒤 버그가 수정된 것을 확인하고 해당 티켓을 닫습니다.

개발자는 버그 보고를 티켓으로만 받기 때문에 Trac 사이트만 잘 확인하면 버그 내용에 대해서 잊어버리고 넘어갈 일은 없습니다. 테스트팀 또한 버그가 수정되면 버그가 수정되었다는 답글이 달리고, 빌드 서버에서 새 버전을 바로 받아 볼 수 있기 때문에 테스트에만 전념할 수 있습니다.

인수인계 과정에서 생기는 각종 문제점들도 이 개발팀에서는 다른 세상 이야기일 뿐입니다. 모든 소스 코드의 내용과 변경 사항에 대한 이력은 모두 Subversion으로 관리되기 때문에 따로 소스 코드를 넘겨줄 필요가 없습니다. 단지 담당하고 있는 프로젝트의 저장소 URL만 알려주면 끝입니다. 이전 버전에서 버그가 발생하더라도 Subversion을 이용하면 해당 버전의 소스 코드를 그대로 가져 올 수 있습니다. 또한 모든 소스 코드가 Subversion 서버에서 관리되기 때문에 특정 소스 코드를 분실하는 일도 발생하지 않습니다.

빌드된 파일도 버전별로 보관하기 때문에 버그가 보고되면 해당 버전을 빌드 서버에서 받아 곧바로 재현해 볼 수 있습니다. 그리고 자동빌드를 하면서 Subversion 저장소 정보를 심볼 파일에 기록해놓았기 때문에, 덤프 파일을 열면 디스어셈블된 코드 대신 Subversion 저장소에서 소스 코드를 가져와 에러가 발생한 부분을 표시해줍니다. 또한 심볼 서버 형태로 심볼(PDB) 파일을 보관하므로 개발자가 따로 심볼 파일을 보관할 필요가 없습니다.

빌드 서버에서 자동빌드를 하기 때문에 개발자들은 제품을 빌드하고 테스트팀에 넘겨줄 때 소요되는 시간을 절약할 수 있습니다. 또한 제품의 모든 파일은 빌드 서버에서 빌드되므로 빌드 서버만 잘 관리하면 바이러스에 감염된 파일이 배포되는 일은 발생하지 않습니다.

여러분들은 어떤 개발팀에서 일하고 싶습니까?

버전 관리 시스템

버전 관리 시스템(Version Control System)이란 소프트웨어의 소스코드를 체계적으로 관리하기 위해 사용하는 도구를 의미하는 말입니다. 리비전 관리 시스템(Revision Control System), 소프트웨어 형상 관리(Software Configuration Management), 소스 관리 시스템(Source Control System)이라고도 하는데, 이 책에서는 버전 관리 시스템이라는 용어를 사용하겠습니다.

버전 관리 시스템의 필요성

소프트웨어를 만드는데 버전 관리 시스템이 왜 필요할까요? 예전과는 달리 지금은 소프트웨어가 복잡해지고 거대해졌기 때문에 여러 사람이 함께 개발하고 있습니다. 따라서 여러 사람이 공동 작업을 할 때 소스 코드의 일관성을 유지하려면 버전 관리 시스템의 사용이 필수적입니다.

버전 관리 프로그램을 사용하면 다음과 같은 장점이 있습니다.

• 개발 버전과 릴리스 버전의 소스가 섞이지 않고 쉽게 관리 할 수 있습니다.
• 소스를 잘못 수정 했더라도 기록이 남고 되돌리기가 쉽습니다. 파일이 많은 경우 유용합니다.
• 수정, 추가, 삭제 등의 기록이 모두 남고 변경 사항을 추적하기 쉽습니다.
• 개발자들이 소스 코드를 따로따로 백업하지 않아도 됩니다.

가장 유용한 장점은 아무래도 잘못 수정한 소스를 쉽게 되돌릴 수 있다는 것입니다. 프로젝트가 커지다 보면 소스가 꼬이게 되고 골치 아픈 상황이 한두 번 발생하는 것이 아닙니다. 그리고 변경 사항이 모두 기록되기 때문에 무엇을 변경했는지 쉽게 볼 수 있습니다. 또한, 옆 사람이 수정한 것을 쉽게 볼 수 있습니다. 우리나라 소프트웨어 개발자들의 경우 윈도우 공유 폴더를 이용해서 개발하는 경우가 많습니다. 이렇게 되면 누가 무엇을 수정했는지 알 수도 없고, 남이 작성해 놓은 소스 위에 잘못된 소스를 덮어쓰는 경우도 많이 발생하고 있습니다. 그리고 가장 큰 문제를 일으키는 백업을 하지 않아 소스를 분실하는 최악의 상황도 쉽게 해결됩니다.

한 사람이 개인적으로 진행하는 프로젝트가 있더라도 버전 관리 프로그램을 사용하는 것이 매우 편리합니다. 앞서 말한 장점들은 여러 명이 개발하는 것과 한 사람이 개발하는 것에 모두 해당하는 것들입니다.

버전 관리 시스템의 유형

현재 버전 관리 시스템은 수십 가지 종류가 나와있습니다. 이 버전 관리 시스템을 구분할 때는 기능적인 특성으로 구분하게 됩니다. 먼저 저장소 방식으로 구분하는데, 중앙에 서버를 두고 각 사용자가 접속하여 사용하는 클라이언트-서버(Client-Server) 방식과 사용자들이 각자의 저장소를 가지고 있는 분산형(Distributed) 방식으로 구분할 수 있습니다. 잠금(Lock) 방식으로도 버전 관리 시스템을 구분하기도 합니다. 한 사용자가 특정 소스 코드를 체크아웃하여 작업을 하고 있을 때는 다른 사용자가 해당 소스 코드를 수정할 수 없도록 잠금(Lock)을 거는 방식과 여러 사용자가 동시에 체크아웃하여 같은 소스 코드를 수정할 수 있도록 하는 방식으로 구분할 수 있습니다. 기능적인 특성 이외에도 제품 형태에 따라 상용 제품과 오픈소스로도 구분할 수도 있습니다.

이 책에서 소개할 버전 관리 시스템인 Subversion은 클라이언트-서버 방식이며, 여러 사용자가 동시에 체크아웃하여 같은 소스 코드를 수정할 수 있습니다. 또한 잠금도 지원합니다. 오픈소스로 배포되고 있기 때문에 무료로 사용할 수 있습니다.

CVS vs. Subversion

CVS(Concurrent Version System)는 1986년 Dick Grune에 의해서 개발된 버전 관리 시스템입니다. CVS는 파일 하나만을 관리할 수 있는 버전 관리 시스템인 RCS를 기반으로 하고 있습니다. 여러 가지 프로토콜을 지원하고 있으며, 윈도우 버전, 웹 인터페이스, GUI 클라이언트 등 다양한 프로그램들이 개발되어 있습니다. 하지만 CVS는 파일, 디렉터리의 이름 변경 및 이동 불가, 바이너리 파일 미지원, 느린 속도 등의 기능적인 한계가 있었기 때문에 2004년부터 CVS의 핵심 개발자들이 CVS를 대체하기 위해 Subversion을 개발하게 되었습니다.

CVS와 비교한 Subversion의 장점들

• 커밋 단위가 파일이 아니라 체인지셋이라는 점입니다. CVS에서라면 여러 개의 파일을 한꺼번에 커밋하더라도 각각의 파일마다 리비전이 따로 붙습니다. 반면 Subversion에서는 파일별 리비전이 없고 한 번 커밋할 때마다 변경 사항별로 리비전이 하나씩 증가합니다.
• CVS에 비해 빠르게 업데이트, 브랜칭/태깅 됩니다.
• CVS와 사용법이 거의 동일해서 CVS 사용자라면 누구나 어려움 없이 금방 배울 수 있습니다.
• 파일 이름변경, 이동, 디렉터리 버전 관리, 파일, 디렉터리 이름에 유니코드가 지원됩니다.
• 원자적(atomic) 커밋. CVS에서는 여러 파일을 커밋하다가 어느 한 파일에서 커밋이 실패했을 경우 앞의 파일만 커밋이 적용되고 뒤의 파일들은 그대로 남아있게 됩니다. Subversion은 여러 개의 파일을 커밋하더라도 커밋이 실패하면 모두 이전 상태로 되돌아 갑니다.
• 디렉터리별, 파일별 접근 제어 리스트, 저장소 쓰기 접근을 가진 개발자라도 아무 소스나 수정하지 못하게 조절할 수 있습니다.

주요 버전 관리 시스템들

• CVS(Concurrent Versions System) : 파일 하나의 변경 사항을 관리해주는 RCS(Revision Control System)라는 도구를 기반으로 하고 있고, 클라이언트-서버 모델로 네트워크 상에서 여러 사람이 공동 작업을 할 수 있게 만든 것입니다. 많은 오픈소스 프로젝트 및 기업에서 사용하고 있습니다. 하지만 기능상의 한계 때문에 점차 Subversion으로 이전하는 추세입니다. 오픈소스이며 GPL로 배포되고 있습니다. (http://www.cvshome.org)
• Subversion : 기능상 한계가 있는 CVS를 대체하고자 개발되었습니다. 오픈소스 프로젝트이며 BSD 라이센스입니다. 미국의 CollabNet사가 개발을 지원하고 있습니다. 이 책에서 다룰 버전 관리 시스템입니다. (http://subversion.tigris.org)
• Visual Sourcesafe : Microsoft의 버전 관리 시스템입니다. 윈도우 기반 환경에서 많이 사용되고 있으며, Microsoft 개발 도구와 통합성이 뛰어납니다. 현재는 Visual Sourcesafe 2005까지 나와 있습니다. (http://msdn.microsoft.com/ssafe)
• ClearCase : Rational이라는 회사에서 만든 버전 관리 시스템이며, 현재는 IBM에 합병되었습니다. 가격이 상당히 비쌉니다. (http://www-306.ibm.com/software/awdtools/clearcase)
• BitKeeper : BitMover사의 제품이며, 리눅스 커널이 이 BitKeeper를 이용해서 개발 한 적이 있습니다. (http://www.bitkeeper.com)
• Perforce : Perforce Software사의 제품입니다. 속도가 빠른 것이 장점입니다. (http://www.perforce.com)
• Bazaar : Ubuntu 리눅스로 유명한 Canonical사가 개발을 지원하고 있는 버전 관리 시스템입니다. 서버-클라이언트 모델 및 분산형을 모두 지원합니다. 오픈소스이며 GPL로 배포되고 있습니다. (http://bazaar-vcs.org)
• Mercurial : 오픈소스로 개발되고 있는 분산형 버전 관리 시스템입니다. 오픈 솔라리스 개발에 사용되고 있습니다. (http://www.selenic.com/mercurial/wiki)
• Git : 리누스 토발즈가 개발한 버전 관리 시스템입니다. 현재 리눅스 커널 개발에 사용되고 있습니다. (http://git.or.cz)
• Team Foundation Server : Microsoft Visual Sourcesafe는 단순한 버전 관리 시스템이지만 Team Foundation Server는 버전 관리 시스템 기능에 프로젝트 관리, 팀 빌드, 팀 프로젝트 포털 등을 지원하는 통합 개발 환경입니다. Visual Studio Team System 2005, 2008을 통하여 사용합니다.

버전 관리 시스템을 주요기능으로 구분하여 정리하면 다음과 같습니다.

필자는 Subversion을 주로 이용하지만, 필자의 웹 사이트인 http://www.pyrasis.com은 Mercurial로 관리하고 있습니다. 필자의 웹 사이트는 모니위키와 텍스트큐브(테터툴즈)로 구성되어 있어서 php 소스 코드를 수정할 일이 많습니다. 그래서 버전 관리 시스템이 필요했는데, 이런 저런 버전 관리 시스템을 알아보던 중 Mercurial이 원하는 기능을 가지고 있었습니다.

Mercurial은 분산형이라 별도의 저장소가 필요 없고 웹 사이트 디렉터리 자체가 저장소이기 때문에 소스 코드를 수정하고 그 자리에서 바로 커밋하면 됩니다. 백업을 할 때는 hg pull 명령을 사용하여 웹 사이트의 변경 사항을 필자의 컴퓨터로 가져오기만 하면 됩니다. hg serve 명령을 실행하면 Subversion의 ViewVC와 같은 웹 인터페이스를 사용할 수 있도록 해주는데, 여기서 로그 메시지와 수정 내용을 확인할 수 있습니다.

리눅스 서버로 운영되는 웹 사이트 관리에는 Subversion과 같은 중앙집중형 보다는 Mercurial과 같은 분산형 버전 관리 시스템을 추천합니다. Mercurial은 명령행 도구 밖에 없지만 최근 TortoiseSVN과 동일한 인터페이스의 TortoiseHg가 개발되어 배포되고 있습니다.

버전 관리 시스템의 용어들

버전 관리 시스템을 처음 사용하게 되면 생소한 용어들 때문에 사용에 어려움을 겪을 때가 많습니다. 여기서 설명하는 버전 관리 시스템 용어들은 가장 기본적인 것들이기 때문에 용어들이 뜻하는 개념을 꼭 이해하고 넘어가야 합니다.

• 저장소 : 리포지토리(Repository)라고도 하며 모든 프로젝트의 프로그램 소스들은 이 저장소 안에 저장됩니다. 그리고 소스뿐만 아니라 소스의 변경 사항도 모두 저장됩니다. 네트워크를 통해서 여러 사람이 접근할 수 있습니다. 버전 관리 시스템마다 고유의 저장소 포맷이 있습니다.
• 체크아웃 : 저장소에서 소스를 받아오는 것입니다. 체크아웃한 소스를 보면 프로그램 소스가 아닌 다른 디렉터리와 파일들이 섞여 있는 것을 볼 수 있습니다. 이 디렉터리와 파일들은 버전 관리를 위한 파일들입니다. 임의로 지우거나 변경하면 저장소와 연결이 되지 않습니다. 이 체크아웃에는 권한을 줄 수 있습니다. 오픈소스 프로젝트에서는 대부분 익명 체크아웃을 허용하고 있습니다.
• 커밋(Commit) : 체크아웃 한 소스를 수정, 파일 추가, 삭제한 뒤 저장소에 저장하고 갱신하는 것입니다. 커밋을 하면 CVS에서는 수정한 파일의 리비전이 증가하고 Subversion에서는 전체 리비전이 1 증가하게 됩니다. 버전 관리 시스템에 따라서는 리비전이 해쉬값인 경우도 있습니다.
• 업데이트(Update) : 체크아웃을 해서 소스를 가져 왔더라도 다른 사람이 커밋을 하였다면 소스가 달라졌을 것입니다. 이럴 때는 업데이트해서 저장소에 있는 최신 버전의 소스를 가져옵니다. 물론 바뀐 부분만 가져옵니다.
• 리비전(Revision) : 소스 파일 등을 수정하여 커밋하게 되면 일정한 규칙에 따라 숫자가 증가합니다. 버전 관리 시스템에 따라 해쉬값을 사용하는 경우도 있습니다. 저장소에 저장된 각각의 파일 버전이라 할 수 있습니다. Subversion은 파일 별로 리비전을 매기지 않고 한번 커밋 한 것으로 전체 리비전을 매깁니다. 따라서 리비전을 보고 프로젝트 진행 상황을 알 수 있습니다.
• 임포트(Import) : 아무것도 들어 있지 않은 저장소에 맨 처음 소스를 넣는 작업입니다.
• 익스포트(Export) : 체크아웃과는 달리 버전 관리 파일들을 뺀 순수한 소스 파일을 받아올 수 있습니다. 오픈소스 프로젝트에서는 소스를 압축해서 릴리즈 할 때 사용합니다.

Subversion 저장소에 대한 이해

Subversion의 저장소는 저장 포맷에 따라 두 가지 형태로 구분할 수 있습니다. Subversion이 최초에 개발될 당시에는 파일 데이터베이스인 Berkeley DB(BDB)를 사용한 방식만 있었습니다. 하지만 이 BDB 방식은 안정성에 문제가 있다는 목소리가 커지자 파일시스템에 바로 저장하는 방식인 FSFS 방식이 개발되게 되었습니다. 현재는 저장소를 만들면 기본적으로 FSFS 방식의 저장소가 만들어지게 됩니다.

Subversion 저장소를 만들면 저장소 디렉터리가 만들어지고 그 아래에는 기본적으로 여러 개의 디렉터리와 파일들이 들어가 있게 됩니다. 필자가 받은 질문 중의 하나는 Subversion 저장소 디렉터리를 아무리 살펴봐도 커밋한 파일들이 보이지 않는다는 것이었습니다. CVS에서는 커밋한 파일들이 CVS 저장소 디렉터리 안에 hello.c,v 처럼 파일 명에 ,v가 붙은 채로 보이게 됩니다. 하지만 Subversion은 파일을 저장할 때 자체 포맷(BDB, FSFS)으로 저장하기 때문에 커밋한 파일명이 드러나지 않게 됩니다. Subversion 저장소 디렉터리 아래 db라는 디렉터리에 커밋한 내용이 저장되는 것입니다. BDB 방식이라면 db 디렉터리 아래에 BDB 방식의 파일들이 여러 개 보일 것입니다. 그중에서 strings라는 파일에 커밋한 파일의 실제 내용이 저장됩니다. FSFS 방식은 db 디렉터리 아래에 revs 디렉터리를 보면 1, 2, 3, 4 ... 처럼 숫자로 된 파일이 여러개 보일 것입니다. 이 숫자들은 리비전을 뜻하며 커밋한 파일의 내용은 리비전 별로 저장됩니다.

저장소에 접속할 때 사용하는 프로토콜은 여러 가지가 있습니다. file://은 로컬에 있는 저장소에 접근할 때 사용합니다. svn://은 svnserve.exe를 실행하여 사용합니다. http://와 https://는 아파치 웹 서버와 연동하여 사용합니다. svn+ssh://는 ssh를 통하여 저장소에 접근할 때 사용합니다. 이 책에서는 svn://과 http:// 및 https://를 사용하는 방법에 대해서 설명합니다.

Subversion 저장소의 디렉터리 배치

이 책에서는 Subversion을 중심으로 설명할 것이기 때문에 Subversion을 기준으로 디렉터리 배치 방법을 설명하겠습니다.

저장소에 바로 소스를 넣어 프로젝트를 진행 할 수 있습니다. 그렇지만 버전 관리 시스템에서 권장하는 디렉터리 배치 방법이 따로 있습니다.

Subversion은 클라이언트-서버 모델을 채택하고 있기 때문에 클라이언트와 서버가 통신할 표준 프로토콜을 결정해야 합니다. 사용하는 프로토콜은 svn입니다. 따라서 접속할 저장소의 URL은 'svn://서버명:[포트]/repos/저장소명'의 구조를 가집니다. 설정에 따라 웹을 통한 접근을 허용한 경우 http로 시작하는 URL을 통해서도 내용을 볼 수 있으며, 중요한 데이터라면 SSH를 통해 보안성을 높일 수도 있습니다.

Subversion의 저장소(Repository)는 버전 관리되는 대상들이 저장되는 곳입니다. 저장소 안에는 어떤 파일이 어떤 이유에서, 누가, 언제, 어떻게 변경했는지와 같은 메타정보도 함께 저장됩니다.

Subversion은 내부적으로 Berkeley DB를 사용해서 파일을 관리합니다. SVN의 저장소는 관례적으로 trunk, branches, tags라는 세 개의 디렉터리를 가지고 시작하는 것이 좋습니다. trunk는 나무의 몸통을 뜻하는데 프로젝트의 원본이 관리되는 곳입니다. branches는 몸통에서 뻗어나온 나뭇가지를 뜻하는데, 개바를 하다 보면 고객시연용 개발 등과 같이 원본과는 다른 목적으로 프로젝트가 분기되는 경우가 있습니다. 이런 경우, 프로젝트의 원본을 분기시킨 버전을 branches에 만들어 관리하게 됩니다. tags는 꼬리표를 뜻하며, 정기적으로 1.0 버전, 2.0 버전과 같은 식으로 특정 시점의 릴리스를 따로 관리하기 위한 곳입니다.

-- http://svn.samplerepository.org/svn/sample
 +--+---+- branches
    |   +--+- dav-mirror
    |   |  |--- src
    |   |  |--- doc
    |   |  +--- Makefile
    |   |
    |   +--- svn-push
    |   +--- svnserve-thread-pools
    |
    +---+- tags
    |   +--- 0.10
    |   +--+- 0.10.1
    |   |  |--- src
    |   |  |--- doc
    |   |  +--- Makefile
    |   |
    |   +--- 0.20
    |   +--- 0.30
    |   +--- 0.50
    |   +--- 1.01
    |
    +---+- trunk
        |--- src
        |--- doc
        +--- Makefile

위에 보이는 구조는 보통 자주 사용되는 디렉터리 구조입니다. 저장소 디렉터리 아래 branches, tags, trunk 라는 3개의 디렉터리가 있습니다. 이 디렉터리들은 각각의 용도가 있습니다. CVS는 branch와 tag를 위한 명령이 따로 존재 합니다. Subversion의 경우 명령이 있긴 하지만, 단순한 디렉터리 복사와 같은 효과를 냅니다.

• trunk : 단어 자체의 뜻은 본체 부분, 나무줄기, 몸통 등 입니다. 프로젝트에서 가장 중심이 되는 디렉터리입니다. 모든 프로그램 개발 작업은 trunk 디렉터리에서 이루어집니다. 그래서 위의 구조에서 trunk 디렉터리 아래에는 바로 소스들의 파일과 디렉터리가 들어가게 됩니다.

• branches : 나무줄기(trunk)에서 뻗어져 나온 나무 가지를 뜻합니다. trunk 디렉터리에서 프로그램을 개발하다 보면 큰 프로젝트에서 또 다른 작은 분류로 빼서 따로 개발해야 할 경우가 생깁니다. 프로젝트안의 작은 프로젝트라고 생각하면 됩니다. branches 디렉터리 안에 또 다른 디렉터리를 두어 그 안에서 개발하게 됩니다.

• tags : tag는 꼬리표라는 뜻을 가지고 있습니다. 이 디렉터리는 프로그램을 개발하면서 정기적으로 릴리즈를 할 때 0.1, 0.2, 1.0 하는 식으로 버전을 붙여 발표하게 되는데 그때그때 발표한 소스를 따로 저장하는 공간입니다. 위에서 보면 tags 디렉터리 아래에는 버전명으로 디렉터리가 만들어져 있습니다.

이슈 관리 시스템

이슈 트래킹 시스템, 버그 트래킹 시스템 등 여러 이름으로 불리고 있습니다. 각각 약간의 차이점이 있긴 하지만, 대부분 개념은 동일 하므로 이 책에서는 이슈 관리 시스템이라고 하겠습니다.

이슈 관리 시스템은 대형 오픈소스 프로젝트와 소스포지 SourceForge.net 같은 곳에서 쉽게 접할 수 있습니다. 이슈 관리 시스템은 단독으로 사용되는 경우도 있고 버전 관리 시스템과 연동하여 사용하는 경우도 있습니다.

이슈 관리 시스템은 버그, 요구 사항, 작업 내용 등이 있을 때 해당 시스템에 게시물 형태로 올리고 개발자, 테스터들이 작업 진행상황을 기록하는 시스템을 말합니다. 일반적으로 인터넷 상의 게시판과 비슷한 형태이며, 해당 이슈(버그, 요구 사항, 작업 내용 등)에 대한 제목에, 이슈 형태, 담당자, 프로그램 버전, 우선 순위 등의 속성을 지정하고 내용을 올립니다. 이슈에 대한 작업이 진행 되면 작업 결과를 답글 형식으로 올립니다. 하나의 이슈에 대한 작업이 끝나면 이슈를 닫습니다(Close). 이미 해결한 이슈지만 또다시 문제가 생겼을 경우 다시 열 수 있습니다(Reopen). 또는 보류(Pending)할 수도 있습니다.

파일 첨부도 가능하며, 버그나 요구사항에 대한 관련 파일도 첨부 할 수 있습니다. 이슈에 답글이 달리거나 속성(이슈 형태, 담당자, 버전, 우선순위 등)의 변경, 이슈 해결 등의 동작에 따라 이메일 주소에 통지 메일(Notification Mail)을 보낼 수도 있습니다. 대부분의 이슈 관리 시스템은 RSS 출력을 지원하므로 RSS 리더를 사용하여 이슈의 진행 상황을 받아 볼 수 있습니다.

이슈 관리 시스템의 필요성

소프트웨어를 개발하다 보면 일반적인 기능 구현 작업과 함께 버그 수정과 요구 사항 반영 작업을 많이 하게 됩니다. 이슈 관리 시스템을 사용하지 않고 개발을 하는 경우 버그나 요구 사항을 엑셀 파일에 저장하여 관리하는 경우가 많습니다. 혹은 엑셀 파일에 조차 버그와 요구 사항을 기록하지 않는 경우도 많습니다.

이슈 관리 시스템은 게시판 형태로 되어 있기 때문에 웹에서 쉽게 이슈를 조회 할 수 있고, 이슈에 저장된 속성들을 이용하여 여러 통계 자료를 얻을 수 있습니다. 그리고 이러한 통계들을 통해 현재 프로젝트의 진행 상황을 일목요연하게 확인 할 수 있습니다. 또한 속성 및 이슈 형태를 이용한 검색이 가능하기 때문에 언제 어디서든 예전에 해결 했던 이슈를 쉽게 찾아 다시 살펴 볼 수 있습니다. 이렇게 이슈가 쌓이면 나중에 똑같은 문제가 발생하거나 비슷한 문제가 발생할 때 예전 자료를 참고하여 손쉽게 일을 처리 할 수 있습니다.

버그나 요구사항뿐만 아니라 기능 구현 작업도 이슈 형태로 올리고 이슈를 얼마나 해결 했는가에 따라 프로젝트의 진행 상황을 알 수도 있습니다. 이렇게 이슈 관리 시스템을 사용하면 막무가내식의 개발이 아닌 체계화된 개발을 할 수 있습니다.

이슈 관리 시스템의 종류

이슈 관리 시스템에는 여러 가지 종류가 있지만 대표적인 것을을 소개하겠습니다.

• Trac : 이 책에서 다룰 이슈 관리 시스템입니다. 위키, 이슈(티켓) 관리, Subversion이 절묘하게 조화를 이루고 있는 시스템입니다. Subversion의 사용자 계정을 연동하여 사용할 수 있습니다. 이슈를 티켓이라고 부르며, 이 티켓에 위키 문법을 지원하며, Subversion 커밋 로그 메시지에도 위키 문법을 지원합니다. 또한 Subversion 커밋 로그 메시지를 티켓에 바로 답글을 달 수 있는 기능이 있습니다. 티켓에 마일스톤, 컴포넌트, 버전, 담당자 등을 지정할 수 있고, 로드맵 메뉴에서 해결된 티켓의 개수를 막대(상태진행 바) 형태로 표시해 주며 백분율로 알려줍니다. 마일스톤, 컴포넌트 버전, 담당자 별로 막대를 표시해 줄 수도 있습니다. Subversion 뿐만 아니라 CVS, Bazaar, Mercurial, Darcs, Perforce, Monotone, SVK, Arch, ClearCase, Git 등의 버전 관리 시스템도 지원합니다. 플러그인 형태로 여러가지 기능을 추가 할 수 있습니다. 오픈소스로 개발되고 있으며, 예전에는 Edgewall이라는 회사에서 GPL 라이센스로 개발하여 배포하였지만 회사가 없어지면서 BSD 라이센스로 배포되고 있습니다. (http://trac.edgewall.org)
• BugZilla : 모질라 재단에서 개발하고 있고 모질라, 리눅스 커널, GNOME, KDE, Apache, OpenOffice, Eclipse등 대형 오픈소스 프로젝트에서 사용되고 있는 이슈 관리 시스템입니다.
• Mantis : PHP로 작성되어 있고, MySQL, PostgreSQL을 사용하는 이슈 관리 시스템입니다. 이슈에 다양한 속성을 지정할 수 있는 것이 특징입니다. 버전 관리 시스템은 CVS와 Subversion을 지원합니다. 오픈 소스로 개발되고 있으며 GPL로 배포되고 있습니다. (http://www.mantisbt.org)
• FogBugz : 『조엘 온 소프트웨어』 책으로 유명한 조엘이 운영하는 Fog Geek Software의 제품입니다. 위키, 이슈 관리, 프로젝트 관리, 그래픽화 된 일정관리, 토론 게시판 등을 지원합니다. 버전 관리 시스템은 Subversion, Perforce, CVS, Visual SourceSafe를 지원합니다. (http://www.fogcreek.com/FogBugz)

아래는 이슈 관리 시스템에 버전 관리 시스템, 위키, 게시판, 릴리즈 시스템, 메일링 리스트, 프로젝트 관리를 통합한 시스템입니다. 오픈 소스가 아니며 사용하려면 구입해야 하는 제품입니다.

• CollabNet Enterprise Edition : Subversion을 만든 CollabNet의 CDE 시스템입니다. 15명 까지 무료로 사용할 수 있습니다. CollabNet의 오픈소스 호스팅 사이트인 http://tigris.org가 이 시스템을 사용하고 있습니다. (http://www.collab.net/products/enterprise_edition)
• SourceForge Enterprise Edition : 오픈소스 프로젝트 호스팅 사이트로 유명한 SourceForge.net의 엔터프라이즈 버전입니다. 이것도 15명까지 무료로 사용할 수 있습니다. 트래커, 문서화, 태스크, 게시판, 소스코드 저장소 뷰어, 리포트, 파일릴리즈, 위키등의 기능을 가지고 있으며, SourceForge.net과는 전혀 다른 모습을 보여줍니다. 현재는 CollabNet이 인수하여 판매하고 있습니다. (http://sourceforge.net/powerbar/sfee)
• GForge : SourceForge.net의 오픈소스 버전입니다. 국내에서는 http://kldp.net에서 사용하고 있습니다. 오픈소스로 개발되고 있으며 GPL로 배포되고 있습니다. (http://gforge.org) GForge Advanced Server는 15명까지 무료로 사용할 수 있고 오픈소스 버전보다 기능 및 편의성이 더 좋습니다. (http://gforgegroup.com/es)

빌드 자동화 시스템

빌드 자동화 시스템은 사람이 일일이 빌드하는 불편함을 덜어주는 도구입니다. 시스템을 구성하기에 따라 일일빌드는 물론이고, 주간, 월간, 시간 단위로 빌드되게 할 수 있습니다. 또는 커밋을 하는 순간 빌드가 되도록 하거나 원하는 시점에 바로 빌드를 하도록 할 수도 있습니다. 빌드 자동화 시스템은 자체적인 빌드 스크립트를 통해 프로젝트 마다 세부적인 설정이 가능하고 스크립트 언어, 명령행(커맨드라인) 도구들을 이용하여 부가적인 기능을 수행할 수도 있습니다.

빌드 자동화 시스템의 필요성

빌드 자동화 시스템은 프로젝트가 클 경우 꼭 필요합니다. 작은 프로젝트의 경우 빌드 하는데 시간이 얼마 걸리지 않지만 큰 프로젝트의 경우에는 한번 빌드하는데도 시간이 오래 걸립니다. 개발자 각자가 빌드하여 릴리즈하는 경우 빌드하는 동안에는 개발 작업을 할 수 없게 됩니다. 따라서 시간이 많이 낭비됩니다. 빌드 서버에서 빌드 자동화 시스템으로 빌드 한다면 개발자는 빌드하는 동안에도 계속 개발 작업을 할 수 있고, 지정된 시간에 빌드하도록 해놓았다면 개발자는 개발에만 전념할 수 있습니다. 테스터 입장에서도 빌드 자동화 시스템은 아주 유용합니다. 주기적으로 빌드된 결과물이 빌드 서버에 계속 저장되기 때문에, 어떤 버전에서 버그가 발생했는지 보고하기도 쉽고, 수정된 결과물을 확인하는 것도 편리합니다.

빌드 자동화 시스템의 종류

• CruiseControl : 자바로 개발된 빌드 시스템입니다. 다양한 플러그인을 지원하며, 웹 인터페이스로 빌드 상황을 확인 할 수 있습니다. 오픈소스로 개발되고 있으며 BSD 라이센스 입니다. (http://cruisecontrol.sourceforge.net)

• CruiseControl.NET : CruiseControl을 .NET으로 포팅 한 버전입니다. 윈도우 환경에서 사용하기 편리하며, 서비스로 실행되고, 웹 인터페이스 및 GUI 클라이언트를 지원합니다. 다양한 버전 관리 시스템을 지원합니다. 오픈소스로 개발되고 있습니다. 이 책에서 다룰 빌드 자동화 시스템입니다. (http://ccnet.thoughtworks.com)
• Ant : Apache 프로젝트에서 개발하고 있는 빌드 자동화 시스템입니다. 자바로 되어 있으며, 자바에 특화되어 있습니다. (http://ant.apache.org)
• NAnt : Ant의 .NET 버전입니다. .NET에 특화되어 있습니다. (http://nant.sourceforge.net)

소프트웨어 개발 자동화를 이루는 구성요소들인 버전 관리 시스템, 이슈 관리 시스템, 빌드 자동화 시스템의 종류와 기본적인 개념에 대해서 알아보았습니다. 다음 장에서는 버전 관리 시스템인 Subversion의 기본적인 사용 방법에 대해 알아보겠습니다.

• 전체 목차
• 1장 - 소프트웨어 개발 자동화
• 2장 - Subversion으로 소스코드 관리하기
• 3장 - PowerShell로 자동화하기
• 4장 - Subversion과 Symbol 파일 연동
• 5장 - CruiseControl.NET으로 빌드 자동화하기
• 6장 - Apache와 Subversion 연동
• 7장 - Trac
• 8장 - CruiseControl.NET
• 9장 - Release Server
• 10장 - 백업
• 11장 - Subversion 관련 도구
• 12장 - 문서화
• 13장 - 프로젝트 준비
• 14장 - 프로젝트 진행
• 15장 - 실전에서 발생하는 문제들
• 부록