이 글은 월간 마이크로소프트웨어(일명 마소) 2008년 2월호에 기고한 글입니다. 물론 구성이나 내용 상의 차이가 있을 수 있습니다.
지난 시간에는 지속적인 통합 환경을 갖춰놓으면 개발하는 하루하루가 어떤 모습으로 변할지 알아봤다. 사무실에 아침 일찍 도착하면 빌드 서버가 안녕한지 알아본다. 녹색 아이콘이 눈에 들어오면 한숨 놓고, 지난 밤에 누군가 밤샘 코딩을 하진 않았나 확인한다. 누리끼리한 아이콘이 보이면 “Update” 버튼을 눌러 버전 관리 저장소에서 새 코드를 내려 받는다. 이제 웹 브라우저를 열어 이슈 관리 시스템 Trac에 접속한다. “Timeline”을 보면 한밤중에 열심히 일한 사람이 누구인지, 무슨 일을 했는지 알 수 있다. 일주일이나 기다렸던 기능이 완성됐다는 메시지를 보고, 기쁜 마음에 당장 새 소프트웨어를 돌려보고 싶어서 Test.bat 배치파일을 실행한다. 배치 파일은 로컬 소스코드를 뒤져 리소스 파일을 복사하고 소스 코드를 빌드한 다음, 테스트용 데이터베이스와 데이터를 생성하고, 레지스트리를 살짝 손보고 나서 마침내 개발 중인 서버 애플리케이션과 테스트용 클라이언트 프로그램을 띄워준다. 테스트용 클라이언트에 귓말 채팅을 해보라고 명령을 내리고 순식간에 응답이 네트워크를 건너 날아온다. 소프트웨어는 어제만큼 완전하고, 더불어 멋진 기능이 하나 더 늘었다.
최재훈 | SK 아이미디어에서 게임 서버 개발을 하고 있다. 프로젝트 관리, C++, 닷넷 기술, 데이터베이스 등 여러 분야에 관심을 두고 있으며, 빌드 자동화나 테스트 기법을 실천하는 것에 역량을 기울인다.
이 모든 게 소설이 아닌 평범한 진짜 세상의 하루이다. 이렇게 일하는 곳이 많아졌지만, 어쩌다 운 없게도 괴로운 나날을 보내는 개발자에겐 꿈 같은 이야기일 것이다. 불과 2년 전만 해도 그런 환경에서 일해봤기 때문에 그 고통을 잘 안다. 이번 시간부터는 아무것도 갖추지 못한 팀이 어떻게 하면 과거와 작별하고 즐거운 미래를 맞이할 수 있을지 하나씩 알아보겠다. 그리고 그 첫 번째 단계로써, 버전 관리 시스템과 이슈 추적 시스템을 갖추는 법을 살펴보자.
빌드 자동화의 중심 – 버전 관리 시스템
지속적인 통합이라 이름 붙이긴 했지만, 어쩌면 적절한 이름이 아닐지도 모른다. 지속적인 통합은 다양한 실천 방법을 한데 묶어 일컫는 표현이기 때문에 빌드 자동화뿐만 아니라 코드를 조금씩, 자주 개선하는 활동도 포함하기 때문이다. ’지속적인 통합’ 연재에서는 주로 빌드 자동화에 중점을 두지만, 코드 개선 활동도 지속적으로 강조하고 언급할 것이다.
그런데 코드 개선 활동이 아닌 빌드 자동화에 초점을 맞추면, 그 핵심이라 할 수 있는 것이 버전 관리 시스템이다. 근래에 “Continuous Integration”을 번역하는데, 이 책에 가장 많이 등장하는 단어가 지속적인 통합을 뜻하는 “Continuous Integration”와 버전 관리 저장소를 뜻하는 “Version Control Repository”이다. 그만큼 버전 관리 저장소는 빌드 자동화에 없어서는 안 될 도구다. 버전 관리 저장소가 없으면 최신 소스 코드를 팀 구성원들이 공유하기 힘들다. 네트워크 드라이브를 사용하는 원시적인 방법으론 대규모 시스템은 도저히 개발할 수 없다. 지금 개발 중인 게임 서버는 큼지막한 애플리케이션만 10여 개가 동원되는데, 각 애플리케이션이 공유하는 라이브러리만 해도 세 개가 넘는다. 이런 판국에 누군가 핵심 라이브러리를 왕창 고쳐서 네트워크 드라이브에 올렸다고 생각하면 아찔하다.
자동화의 관점에서 봐도 버전 관리 저장소는 말 그대로 핵심이다. 누군가 소스 코드를 고쳐서 올리면, 빌드 서버가 저장소에서 최신 소스 코드를 내려 받는다. 컴파일하고 테스트를 돌려보고 나서 뭐라도 하나 깨지면 개발자에게 알려준다. 버전 관리 저장소가 없으면 사람이 직접 빌드 서버에 최신 소스 코드를 올리고 빌드 스크립트를 실행해야 한다. 날이 갈수록 오르는 인건비를 생각하면 전담 빌드맨을 두고 소프트웨어 세계의 안전을 지키게 하기란 현실적으로 어렵다. 설사 돈이 남아도는 회사라서 전담 빌드맨을 두었다 하더라도, 지루하기 짝이 없는 빌드 과정을 하루에 몇 번씩 해내려면 노이로제에 걸리고 말 것이다. 그래서 우리에겐 버전 관리 시스템이 필요하다.
버전 관리 시스템 - 서브버전
왜 그 많은 버전 관리 시스템 중에 하필이면 서브버전인가? 무엇이 더 잘났기에 서브버전을 골라야 하는가? 솔직히 말해 꼭 서브버전이어야 할 이유는 없다. 세상엔 멋진 도구가 많지만, 그 중 극히 일부만 직접 경험했을 뿐이고 실제로 1년 이상 꾸준히 써본 것은 서브버전뿐이다. 경험 많은 개발자라면 대여섯 개의 시스템을 경험해봤을지도 모르겠다. 어쨌거나 서브버전은 대중적인 인기를 누리는 소프트웨어이고, 무료로 사용할 수 있다. 그리고 마찬가지로 무료인 멋진 클라이언트 도구인 TortoiseSVN이 있다. 수년 간 잘 써왔고 특별히 불만스러운 점이 없었으며 다른 사람도 대체로 만족한다는 점에서 서브버전을 택했다. 좀더 그럴듯한 이유를 대면 좋지만, 여기서는 솔직하고 실용적인 선택을 하겠다.
서브버전의 종류
서브버전 커뮤니티는 리눅스용과 윈도우용 모두 배포한다. 각각 장단점이 있는데, 윈도우용은 설치하기 쉽지만 리눅스용은 조금 더 손이 간다. 그런 반면 서브버전의 고급 기능을 쓰거나 이슈 추적 시스템 같은 Trac 등과 연동할 때는 리눅스용이 더 쉬울 수 있다. 대부분의 문서가 리눅스 환경에 맞춰 작성되기 때문에, 윈도우 환경에 알맞은 방법을 찾기가 쉽지 않을 때가 많고, 그런 탓에 문제가 발생했을 때 해결하기 쉽지 않은 게 사실이다. 하지만 윈도우용은 장점이 하나 더 있는데, 특히 이 칼럼에서 다루는 환경에서 빛을 발한다. 윈도우 프로그래밍을 하는 만큼 윈도우를 빌드 서버로 써야 한다. 만약 윈도우용 서브버전을 선택한다면, 한 컴퓨터에 빌드 자동화 환경을 모두 갖출 수 있다. 특히 자동화 환경을 갖추는 데 투자를 꺼려하는 곳이라면, 추가적인 하드웨어 구매 비용이 발생하지 않는 편이 좋을 수 있다.
여기선 리눅스용 서브버전에 중점을 둔다. 프로젝트에 정식으로 참가했을 무렵에 이미 리눅스 환경에 서브버전과 Trac을 설치해서 쓰고 있었기 때문인 탓도 있지만, 어느 정도 규모를 넘어선 프로젝트라면 어차피 한 컴퓨터에 버전 관리 시스템과 빌드 서버를 함께 두긴 힘들다. 빌드 서버가 열심히 제 할 일을 하느라 CPU 사용률이 마구 치솟는 상황에선 최신 소스 코드를 올리고 내려 받기 힘들다.
서브버전 설치하기 – 리눅스 서버가 갖춰져 있을 때
리눅스 배포판에는 다양한 종류가 있다. 그리고 각 배포판마다 특징이 있어서 소프트웨어를 설치하는 방법이 달라지곤 한다. 그러니 모든 경우를 다 다루기는 힘들고 여기선 인기 있는 배포판 중 하나인 Ubuntu 7.10이 설치되어 있는 상황이라고 가정한다.
먼저 할 일은 Ubuntu를 최신 상태로 업그레이드 하는 것이다. 간단히 명령어 두 개를 실행시키면 된다.
$ sudo apt-get update
$ sudo apt-get dist-update
그러고 나서 아파치 웹 서버와 서브 버전을 설치한다. 아파치는 웹을 통해 서브버전 저장소에 접근할 수 있게 해주고, 후에 이슈 추적 시스템 Trac을 설치할 때도 필요하다.
$ sudo apt-get install apache2
$ sudo apt-get install subversion subversion-tools
아파치와 서브버전이 무사히 설치되었으면 이제 서브버전 저장소를 만들어보자.
$ sudo mkdir –p /var/lib/svn/myproject
여기선 임의로 프로젝트 이름을 myproject로 정했는데, 프로젝트가 여러 개 있다면 /var/lib/svn에 각 프로젝트에 해당하는 디렉토리를 만들어주면 된다.
이제 프로젝트 디렉토리를 서브버전 저장소로 초기화해준다.
$ sudo svnadmin create /var/lib/svn/myproject
$ sudo svn mkdir file:///var/lib/svn/myproject/trunk -m “Trunk”
svnadmin create로 저장소를 만들고, svn mkdir를 사용해 저장소 안에 디렉토리를 생성했다. 지금 당장 trunk 디렉토리를 만들 필요는 없고, 잘 설치됐는지 확인하려는 것뿐이다. 모든 게 정상이라면 이제 웹 브라우저를 통해 SVN에 접근할 수 있게 해보자. 우선 아파치와 서브버전을 연동해주는 패키지부터 설치한다.
$ sudo apt-get install libapache2-svn
설치가 무사히 끝났으면 “vim /etc/apache2/mod-available/dav_svn.conf” 명령어를 쳐서 파일을 열고 다음과 같이 편집한다. 파일의 내용은 이미 써져 있을 테고 주석만 선택적으로 풀고 일부 값을 바꿔주면 된다(지면 관계상 주석을 제거했다).
<Location /svn>
DAV svn
SVNParentPath /var/lib/svn
AuthType Basic
AuthName "Subversion Repository Access"
AuthUserFile /etc/apache2/htpasswd
AuthzSVNAccessFile /etc/ apache2/dav_svn.passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
dav_svn.conf 파일을 다 수정했으면 앞으로 사용할 계정을 만든다.
$ sudo htpasswd –c /etc/apache2/dav_svn.passwd 내아이디
이제 “sudo chown –R www-data.www-data /var/lib/svn” 명령어를 쳐서 웹을 통해 저장소에 접근할 수 있도록 권한을 부여한다. 다 끝났으면 웹 서버가 새 설정 파일을 읽어 들이도록 하자.
$ sudo /etc/init.d/apache2 restart
이제 “웹 브라우저를 열어 웹으로 접근해본다. http://내_아이피/svn/myproject 를 치면 아래와 같은 화면이 보인다.
- [그림 1] 웹으로 SVN 접근하기
여기까지 왔으면 나머지는 서브버전 설치가 아닌 관리에 속하는 일이다. 프로젝트 디렉토리 구조를 정하고 소스코드를 커밋해 넣는 일이 남았는데, 리눅스 환경에 친숙하지 않은 사람이라도 걱정할 것 없다. 저장소를 만드는 일까지 끝났으면 나머지는 로컬 윈도우에서도 할 수 있다. 혹 리눅스나 윈도우 콘솔 환경에서 서브버전을 관리하고 싶다면 서브버전 윈도우 바이너리에 포함된 설명서(http://subversion.tigris.org)나 웹 문서 또는 관련 서적을 참고하면 된다.
서브버전 관련 문서
서브버전의 인기만큼 관련 문서나 서적이 많은데, 지면이 부족하니 온라인 서점에서 검색하면 바로 나오는 책은 빼고 웹 문서만 몇 개 소개한다.
안될경우 아래와 같이 함.
SVN 폴더 생성
sudo svnadmin create /home/svn
sudo chown www-data:www-data /home/svn -R
SVN 환경 설정
sudo vi /etc/apache2/mods-enabled/dav_svn.conf
<Location /svn>
DAV svn
SVNPath /home/svn
AuthType Basic
AuthName "Subversioin Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
</Location>
sudo htpasswd -cm /etc/apache2/dav_svn.passwd hulryung
sudo /etc/init.d/apache2 restart
Trac 설치하기
이슈 추적 시스템은 버전 관리 시스템과 비교하면 그리 중요한 요소라 할 수 없다. 그러나 Trac은 설치하기 쉽고, 설치 시간에 비하면 그 효과가 매우 크다. Trac 같은 웹 기반 도구가 있으면 지난밤에 누가 밤샘 코딩을 했는지, 무엇을 고쳤는지, 내가 모르는 사이에 어떤 버그를 발견했는지 쉽게 파악할 수 있다. 특히 개발자마다 일하는 시간대가 조금씩 다른 게임 개발팀이나, 오픈 소스 프로젝트 같이 지역적으로 서로 떨어진 개발자들이 함께 일해야 하는 경우에 이슈 추적 시스템이 있으면 참 좋다. 자, 이제 Trac을 설치해보자.
우선 Trac 설치에 필요한 패키지부터 설치한다.
$ sudo apt-get install trac libapache2-mod-python python-setuptools
무사히 설치했으면 서브버전 저장소와 같은 이름으로 Trac 프로젝트를 만들자.
$ cd /var/lib/trac
$ sudo trac-admin myproject initenv
trac-admin을 실행시키면 이것저것 물어보는데, 서브버전 저장소 경로에 “/var/lib/svn”을 적어주고 다른 값은 기본값 그대로 놔두면 된다.
마지막으로 서브버전을 설치할 때와 마찬가지로 아이디를 생성하고, Trac 프로젝트 디렉토리를 웹에서 접근할 수 있도록 권한을 부여하면 끝이다. 모든 게 끝나면 http://내아이피/trac/myproject 에 접속해본다. 붉은 색이 인상적인 Trac 이슈 추적 시스템의 메인 메뉴가 보일 것이다.
$ sudo htpasswd -c /etc/apache2/dav_svn.passwd 내아이디
$ sudo chown -R www-data.www-data /var/lib/svn
- [그림 2] Trac
편안하게 설치하기
새 리눅스 서버를 설치해서 쓸 생각이라면 ThoughtWorks사가 배포하는 Buildix를 진지하게 고려해보자. Buildix는 다른 게 아니라 버전 관리 시스템 서브버전, 이슈 추적 시스템 Trac, 프로젝트 관리 도구 Mingle, 그리고 빌드 서버 CruiseControl가 설치해놓은 리눅스 배포판이다. 실제로 다운로드 받아 살펴보면 상당히 깔끔하게 구성해놨다는 걸 알 수 있다.
Buildix는 여러 방법으로 배포된다. 맛부터 보고 싶다면, LiveCD를 내려 받아 체험해볼 수 있다. 하드디스크에 설치하지 않고 CD만으로 부팅할 수 있다. VMWare 이미지 역시 배포하므로 하드웨어 구매 예산은 없지만, 넉넉한 성능을 갖춘 컴퓨터가 하나 남는다면 임시로 가상 머신을 쓰면 되겠다. 하드디스크에 Buildix를 까는 방법은 크게 두 가지인데, 하나는 Buildix CD를 넣고 설치하는 것이고, 다른 하나는 Ubuntu 배포판부터 설치하고 Buildix 패키지를 설치하는 것이다.
후자의 경우엔 설치법이 Buildix 사이트에 잘 나와 있는데, 간략하게 설명하면 이렇다.
-
/etc/apt/sources.list 파일을 열고 다음 코드를 추가한다.
deb http://buildix.thoughtworks.com/repos/debian buildix main
-
Buildix 패키지를 내려 받는다.
wget http://buildix.thoughtworks.com/repos/debian/buildix-key.gpg
apt-key add buildix-key.gpg
-
저장소 목록을 갱신하고 Buildix를 설치한다.
aptitude update
aptitude install buildix
만약 Buildix CD를 넣고 설치했다면 당연히 위의 과정조차 필요 없다.
Buildix를 설치하고 부팅하면 로그인 창이 뜬다. 그런데 Buildix 사이트에는 로그인 계정과 암호를 언급한 곳이 없어서 처음에 당황할 수 있다. 다행히 누구나 생각해낼 법한 아이디와 암호를 쓰는데 어이없게도 root/root 이다. 첫 로그인 후에 암호는 바꾸면 되겠다.
이제 로그인도 했고 프롬프트에 뭔가 쳐 넣어야 할 것 같다. 하지만 도대체 뭘 해야 할까? 딱히 매뉴얼이 있는 것도 아니고, 운 나쁘게도 여러분이 리눅스에 친숙하지 않다면 머리가 아파올 것이다.
우선 웹 브라우저를 열고 http://내_아이피/ 에 접속해보자. 반갑게도 Thoughtworks 로고가 드러난 메인 메뉴가 나온다.
- [그림 3] Buildix 메인 메뉴
Buildix 환경 설정
Buildix는 앞서 직접 서브버전과 Trac을 설치했을 때와 미묘하게 다른 환경을 설정한다.
-
서브버전 저장소 루트 경로가 “/var/lib/svn”이 아닌 “/var/svn”이다.
-
Trac 프로젝트 루트 경로가 “/var/lib/trac”이 아닌 “/var/trac”이다.
-
“/etc/apache2/mods-available/dav_svn.conf” 파일 대신 “/etc/apache2/sites-available/buildix”를 사용한다.
-
인증 파일의 경로가 다르다. “/etc/apache2/dav_svn.authz”는 “/etc/buildix/dav_svn.authz”가 되고, “/etc/apache2/htpasswd”는 “/etc/buildix/htpasswd”가 된다.
여러 설정 파일 중에 “/etc/apache2/sites-available/buildix”을 열어 자세히 보면, 여러 가지 사실을 알 수 있다. 예를 들어 http://내아이피/usermanager 에 접속하면 사용자 계정을 웹 인터페이스를 통해 생성할 수 있다. 번거롭게 명령창에 htpasswd 명령어를 치지 않고도 웹에서 바로 계정을 발급 받아서 Trac 등에 접속할 수 있으니 더할 나위 없다.
전에 서브버전과 Trac을 설치했을 때와 마찬가지로 저장소와 프로젝트를 만든다. 이때 “Buildix 환경 설정”에 언급한대로 서브버전 저장소 루트 경로와 Trac 프로젝트 루트 경로가 전과는 다르다는 점에 유의한다.
$ sudo svnadmin create /var/svn/myproject
$ cd /var/trac
$ sudo trac-admin myproject initenv
그러고 나서 웹 사이트 메인 메뉴의 Subversion 버튼이나 Trac 버튼을 누르면, 서브버전 저장소와 Trac 프로젝트 홈페이지가 보일 것이다.
마지막으로 CruiseControl과 Mingle에 대해 간단히 언급하고 마치겠다. CruiseControl은 자바 플랫폼용 빌드 서버인데 이 칼럼은 주로 윈도우 개발팀을 대상으로 삼기 때문에 쓸 일이 없다. 설치 후에 Buildix 메인 메뉴에 접속하면 “Mingle is installed but not configured”라는 메시지가 보인다. 프로젝트 관리 도구인 Mingle을 사용하지 않으려면 “aptitude remove mingle”만 쳐주면 된다. 만약 Mingle을 쓸 거라면 라이선스에 유의해야 한다. 상용의 경우 5명까지는 무료로 사용할 수 있지만, 사용자가 늘어나면 비용을 지불해야 한다. 교육용이나 비상업적 용도 또는 오픈 소스 프로젝트에 쓸 것이라면, Mingle 홈페이지의 설명에 따라 지원하면 된다.
끝마치는 말
이번 호에선 간략하게 버전 관리 저장소와 이슈 추적 시스템을 설치해봤다. 사실 조직마다 요구사항이 달라서 어떤 곳은 SSL 로그인을 지원해야 할 수도 있고, 다른 곳에선 Trac의 웹 관리자 기능을 추가하고 싶을 수도 있다. 이런 세세한 부분까지 다루기엔 지면이 부족하거니와 자칫 지속적인 통합의 다른 부분을 다루기도 전에 진이 빠져버릴 위험도 있다. 그래서 정말 당장 필요한 것만, 핵심적인 것만 다루었다. 물론 빼먹은 중요한 사항도 있지만, 그것들에 대해선 차차 하나씩 알아볼 것이다. 더 많이 알고 싶다면 관련 서적이나 웹 문서 등을 검색해보거나 http://kaistizen.net 에 문의해주길 바란다. 능력이 닿는 한 최대한 도울 생각이다. 좀더 인간적으로 살고자 자동화 도구의 도움을 받고 싶다면 언제라도 환영이다.
다음엔 다시 윈도우의 세계로 돌아와 CruiseControl .NET를 활용해 기초적인 빌드 자동화를 이루는 방법에 대해 알아보는 시간을 갖겠다. 리눅스 환경에 익숙하지 않아 힘들었던 독자라면 다음 칼럼이 반가울지도 모르겠다.
출처 :http://kaistizen.net/EE/index.php/imaso/continuousintegration_2008_02/
Image.nrg
Windows7-USB-DVD-tool.exe
