$g_hostname = 'localhost';        // 호스트 이름 
$g_db_type = 'mysql';             // 데이터 베이스 타입 
$g_database_name = 'mantis';      // 데이터 베이스 이름 
$g_db_username = 'root';          // 데이터 베이스 루트 계정 
$g_db_password = '********';      // 데이터 베이스 루트 패스워드 (평문) 
$g_enable_email_notification    = ON;   // 이메일 알림 사용할 것인지. 
 
// gmail은 POP과 SMTP 모두를 지원한다. 
// gmail SMTP를 이용해서 메일을 전송하기로 했다.  
$g_phpMailer_method             = PHPMAILER_METHOD_SMTP; 
$g_smtp_host                    = 'smtp.gmail.com:465'; 
$g_smtp_connection_mode = 'ssl'; 
$g_smtp_username = 'yundream@gmail.com'; 
$g_smtp_password = 'gkwlak74'; 
 
// OFF로 할경우 신규등록을 하면 공백 패스워드가 만들어진다. 
// ON이면 등록한 유저 메일 주소로 확인 메일이 발송된다. 
$g_allow_signup                 = ON; 
 
// 한국어도 지원한다. 
$g_default_language             = 'korean'; 
 

1.3 사용기

대개의 Ticket 기반 이슈 관리 시스템이 그렇듯이 매우 단순하다. 또한 딱 이슈관리 기능만을 포함하고 있어서, 쉽게 사용할 수 있다. UI도 직관적이다. 뭐, 이런 단순한 시스템을 복잡하게 제공하는 게 더 어렵긴 하겠지만 말이다.

이슈 관리는 아래의 전형적인 방식을 따른다.

1. 이슈가 발생하면
   
2. 새로운 티켓을 생성하고
   
3. 이것을 개발자에게 할당 한다.
   
4. 해결 되면 Close 한다.
   
5. 문제가 다시 발생하면 reopen, reassign 한다.
   
   

다음은 티켓을 만드는 인터페이스와 자신에게 할당된 티켓의 목록을 보유주는 인터페이스를 보여준다.

보낸 사람 Linux

보낸 사람 Linux

버그만을 관리하기로 한다면, 상당히 쓸만한 도구다. 설치하기도 쉽고, 사용도 매우 직관적이다. 직관적이다라는 건 특히 나에게 중요했다. 왜냐하면 코쟁이 얘들이 만든 관리 프로그램들은 지나치게 추상적인 경우가 많았기 때문이다. 아마도 문화적인 차이에 기인한거 같다. 뭐든지 쪼개고 개인화 하고 분석하는데 지나치게 집착하는 서양식 문화 때문인지 몰라도, 그들의 관리도구는 때때로 지나치게 이해하기가 복잡하다. 예컨데 제대로 사용할려면 수백페이지의 문서는 물론이고, 관리 체계 부터 다시 배워야 하는 경우가 허다 했다.

반면 mantis는 설치 즉시 사용가능 하다. 물론 아주 대규모의 프로젝트를 관리해야 할 경우에도 제대로 사용할 수 있을지 모르겠지만, 왠만해선 큰 문제가 없을 것 같다. 지나치게 도구를 고도화 하는 것 보다는, 도구의 부족함은 장인의 경험을 살려서 채워넣으면 되지 않겠는가 하는게 내 생각이다.

2 위키 그리고 svn과의 통합

프로젝트 진행의 지원을 위해서 필요한 최소한의 도구라면 다음과 같은 것들이 있을 것이다.

• 이슈 츄적 시스템 : mantis, bugzilla와 같은 프로그램
  
• 문서화 시스템 : 요즘은 개발 문서도 wiki로 관리하는 곳이 많은 것 같다. 나는 모든 문서를 위키로 관리한다.
  
• 형상관리 시스템 : svn 혹은 cvs
  

프로젝트 관리 시스템은 범위가 광범위 하기 때문에 여기에서 언급하지는 않았다. 좁은 의미로는 위의 3개 시스템을 더한 정도를 프로젝트 관리 시스템이라고 하기도 하고, 범위를 넓히면 일정관리/개발자 관리/프로그램 모듈관리를 포함한 모든 자원을 관리하기 위한 거대한 시스템을 프로젝트 관리 시스템이라고 한다. 전자와 같은 프로그램으로는 trac이 있다.

프로젝트를 진행하게 되면, 항상 고민하는게 이들 3가지 시스템을 어떻게 통합 할 것인가 하는 거다. svn따로 wiki 따로 이슈추적 시스템이 따로 구성되는 경우가 많기 때문이다. trac과 같이 어느정도 통합한 툴이 있기는 한데, 글쎄 뭐라고 해야 할까. 어느 하나도 만족하지 못한 상태에서 얽혀 있다는 느낌이 든다고나 할까 ? 아뭏든 맘에 들지 않는다. 그나마 쉽게 기능을 확장시킬 수 있다면, 수정해서 쓸건데 쉽게 확장시키기도 힘든 것 같다. 아!! 확장에 어려움을 겪는 것은 APM 환경을 선호하는 개인적인 취향 때문일 수 있다.

현재는 이 세가지를 모두 독립적인 시스템으로 구축하고 wiki(moniwiki)로 통합하는 방식을 사용하고 있다.

앞에서 언급했듯이, moniwiki로 이 세가지를 모두 통합하고 싶긴 하다. (moniwiki는 기능의 확장이 매우 쉽다.)

태그 : svn bugzilla 프로젝트 wiki

category_TOOL