아이폰 게임 <팔라독>개발에 적용한 버그 트래킹 시스템 맨티스(Mantis) 를 적용 해보자!!

문기영

Fazecat

강연자 소개 • 개발

– FazeCat • 팔라독 아이패드 • DressUp Baby • New Project!

– Hammer Game Studio • Attack of the Pig

– EA Canada • EURO, FIFA 08~12 • Referee decision engine, CPU AI, Practice Mode, User celebration

– SonoV • Shaiya

– Namo Interactive • Freelancer

– 그 외 다수의 회사들 하지만 적고 싶지 않음. • 저자

– 비주얼 베이직6 게임 만들기 – 게임 개발 테크닉 – 게임 프로그래밍으로 배우는 C#

• 번역 – 언리얼 게임 엔진 UDK 3 – Ogre 3D 1.7 Application Development Cookbook

• 강연 – NDC12 (인디 개발자로써 iPhone게임을 만드는 방법 그리고 개발 및 북미 취업 이야기들)

• 컨퍼런스 – SXSW 부스 참가 업체(KBS1 뉴스에 나옴. 1.3초…)

버그 트래킹 시스템이란?

• http://en.wikipedia.org/wiki/Bug_tracking_system

• 버그 트래킹 시스템은 소프트웨어의 품질 보증 및 프로그래머가 소프트웨어 버그를 트래킹할 수 있도록 도와주는 시스템이다. 버그 트래킹 시스템은 이슈 관리 시스템이라고 말하기도 한다.

버그를 왜 트래킹 하는가? (굳이 소프트웨어를 사용하는 이유)

• 버그 유실 – 보통 소규모 인원의 팀인 경우 버그 관리를 구두로 하는 경우가 많으나 이럴 경우에 중요한 이슈들을 까먹거나 유실할 소지가 많다.

• 관리의 어려움. – 종이 혹은 포스트잇과 같은 도구는 버그를 관리 및 공유하기가 어렵다.

• 멀티미디어 소스를 첨부하여 공유할 수 있다. – 가령 사진, 로그 기록, 동영상을 공유하고자 할 때.

• 스케쥴 관리 – 사람에 따라서 작은 단위로 업무를 쪼갠 태스크로 이슈/버그를 관리하면 일 처리를 더 잘하는 경우가 많다.

그… 아주 그… 유명한 버그 트래킹 시스템 솔루션

• http://devtrack.com/ – 제가 다녔었던 북미의 중소기업 회사의 경우 데브트랙(DevTrack)을 사용함.

• 중소기업이라는 표현은 루리웹 농담입니다. – 편리성 : 좋음(웹버전, PC버전 모두 존재, 전세계 모든 스튜디오 연결 가능) – 가격 : 1명당 60만원

• http://www.bugzilla.org/ – 한국의 몇몇 스튜디오는 버그질라(BugZilla) 사용. – 편리성 : 좋지 않음 – 가격 : 공짜

• http://www.mantisbt.org/ – 많은 사람들이 사용.(한국의 게임개발 회사들도 많이 사용함) – 편리성 : 쓸만함 – 가격 : 공짜

그래서 FazeCat은 무엇을 사용하는가?

• Mantis를 사용하기로 하였음.

• 왜? –공짜!

–사용하기가 편리함.

–웹으로 관리

–데이터베이스를 외부로 빼지 않고 회사 내부 서버에 설치 가능.

Fazecat Mantis 서버 구조

Mantis를 설치하기 위해 필요한 것들

• VirtualBox – 공짜

• Ubuntu Server 12.04.1 – 공짜

• MySQL 5.5.28 – 공짜

• Apache 2.2.22 – 외쳐 EE!

• PHP5 5.3.10 – 공짜

• 드디어 Mantis – 공짜

• 이 모든 게 다 공짜…

강연을 왜 했을까?

• 설치에서 시작해서 실제로 사용하는 것까지 모두 다룰 예정.

• 웬만한 프로그래머라면 대부분 구글신의 도움으로 설치에서 사용까지 가능하지만 여러분의 시간을 조금이라도 단축 시켜드리고자 강연 하기로 했음.

VirtualBox를 설치해보자.

• VirtualBox란 X86, AMD64/Intel64를 가상화 시키기 위해서 필요한 어플리케이션.

• 오라클에서 제공하고 있으며 공짜임!

• 다운로드

– https://www.virtualbox.org/wiki/Downloads

프로그램을 다운로드 받고 실행하여 다음과 같은 스탭으로 설치한다.

오라클님은 무조건 오케이

새로 만들기를 클릭해서 가상 머신을 만들자

가상 머신이 생겼다!

참… 쉽죠?

이제 우분투를 설치할 차례

• 우분투(Ubuntu)란?

• http://en.wikipedia.org/wiki/Ubuntu_(operating_system)

공짜 리눅스

• 이제 우분투를 버추얼박스에 설치하면 된다!

• 다운로드

– http://releases.ubuntu.com/precise/

다운로드 하면

다시 버추얼박스로 돌아가 설정 버튼을 누른다.

디스크 아이콘을 누른 다음에 다운로드한 우분투를 Open하자!

확인을 하고 나면 우분투가 실행된다!

• 한국어는 있지만 English를 선택했다.

• Install Ubuntu Server를 누른다!

ㅇㅏ… 그냥 엔터

• 기호에 맞게 설정해도 되지만 강연자는 테스트로 testuser로 하였다.

• 패스워드도 기호에 맞게. 강연자는 root로 하였다.

진심으로 이런 암호를 쓰겠다는 것인가?

• 아 몰라 Yes.

• 한국 사니까 Yes

잘 모르면 그냥 기본값을 선택

자동 업데이트는 No…

추후에 Git설치하기 용이하므로 OpenSSH까지는 설치하자

좋은거 같은건 Yes

우분투 서버가 설치되었다! 만세!!!

어때요 참… 쉽죠?

이제 MySQL을 설치하자

• MySQL이란?

–공짜 데이터베이스

로그인을 한 후에 다음 커맨드를 입력한다.

• 터미널에서 Sudo apt-get install mysql-server를 입력하고 엔터. 그러면 패스워드를 물어보는데 우리가 설정했던 패스워드인 root를 입력하고 엔터.

• 92메가를 소비한다고? Y를 눌러서 진행

설치중…

• 패스워드를 물어오면 똑같이 root로 하자.

MySQL 설치중…

제대로 설치되어 있는지 확인해보자.

• 터미널에서 다음의 명령어를 입력하고 엔터.

– Sudo netstat –tap | grep mysql

• MySQL이 돌아가고 있다.

이제 아파치, PHP5, 맨티스만 설치하면 된다. 참… 쉽죠?

아파치(Apache) 웹 서버 설치

• 아파치란 무엇인가요?

– Apache is the most commonly used Web Server on Linux systems. Web Servers are used to serve Web Pages requested by client computers. Clients typically request and view Web Pages using Web Browser applications such as Firefox, Opera, orMozilla.

아파치 웹 서버는?

• 공짜로 쓸 수 있는 웹 서버 솔루션

일단 맨티스를 사용하려면 필요하다. 그러니까 사용하자.

터미널에서 다음의 커맨드를 입력하고 엔터 치자!

• Sudo apt-get install apache2

• 그냥 무조건 Y를 누르자.

무언가 설치가 되고 있다

설치가 끝나면 실제로 제대로 설치 되었는지 확인해보자.

• 터미널에서 다음의 커맨드를 입력하자.

– Sudo netstat –tap | grep apache2

• 굳.

PHP5를 설치하자

• PHP란 무엇인가?

– http://en.wikipedia.org/wiki/PHP

– PHP는 웹을 위한 서버쪽 스크립트 언어다.

–공짜

터미널에서 다음의 커맨드를 입력하고 엔터 치자.

• Sudo apt-get install libapache2-mod-php5

• Y를 누른다.

PHP5 설치중…

설치가 모두 끝났다면

• 모듈을 실행해 주도록 하자. 터미널에서 다음 커맨드를 입력한다.

• sudo a2enmod php5

• 강연자의 경우 모듈이 이미 실행되고 있다고 한다.

이제 정말 마지막!

• 맨티스 설치!

터미널에서 다음의 커맨드를 입력하고 엔터 치자.

• sudo apt-get install mantis

• 설치중…

• Libphp-adodb의 위치가 바뀌었다고 한다. 나중에 php.ini를 찾아서 수정 해주면 된다.

• 패스워드는 이전과 마찬가지로 root로 했다.

맨티스 설치가 끝났다! 야호!

포트 설정

• 현재 우분투는 버추얼박스에 설치되어 있으며 버추얼박스는 PC에 설치되어 있다. 그림으로 보면 다음과 같다.

포트 설정

포트 설정

• 현재 PC : A에서 ip를 확인해보자.

포트 설정

• A컴퓨터가 아닌 다른 컴퓨터에서 리눅스 서버에 설치된 맨티스에 접속하기 위해서는 다음과 같이http://192.168.0.120/mantis/login_page.php 로 접근해야 한다. 이를 위해서는 버추얼 박스에 포트를 포워딩 해주어야 한다.

포트 설정 • 버추얼박스의 설정에 들어가서 네트워크를 선택한다.

포트 설정 • 고급 버튼을 누른후 포트 포워딩 버튼을 클릭한다.

포트 포워딩 규칙 설정

• 오른쪽 상단의 + 기호를 클릭해서 규칙을 추가한다.

오라클은 믿음으로 Allow 한다.

포트 테스트

• 이제 PC : A가 있는 곳에서 테스트로 연결이 가능한지 확인해 보자. A에서 웹 브라우저를 실행한 후에 http://192.168.0.120/mantis/install.php를 실행해 보자.

• 유저 이름으로 admin, 패스워드로 root를 입력하고 로그인 한다.

아래의 화면이 나오면 대성공!

• 보통 패스워드는 전부 root로 설정해서 헷갈리지 않게 하자.

• 설정을 마친후에 오른쪽 하단에 있는 Install / Upgrade Database를 클릭한다.

• 멘티스의 설치된 상태가 표시된다.

• 화면을 가장 아래로 스크롤 하면 이제 로그인을 할 수 있는 화면이 나타난다. Continue링크를 클릭하자.

드디어 로그인 화면!

관리자 모드로 로그인.

• Username은 Administrator

• Password는 아까 입력했던 root

맨티스 한글화

• My Account를 누른 후 Preferences를 누른다.

• Korean을 선택 후 Update Prefs버튼을 누른다.

한글이다. Scene난다.

맨티스 Email설정

• 프로젝트에 새로운 인원이 들어오면 새로운 유저를 만들어야 하는데 이때 Verify하려면 email이 설정되어 있어야 함.

• 메일 서버는 gmail 계정을 이용하도록 예를 들어 설명.

맨티스 Email설정

• Email을 설정하기 위해서 config_inc.php혹은 config_local.php파일을 수정해 주어야 한다.

• 파일 경로

– /usr/share/mantis/www/config_inc.php

– /usr/share/mantis/www/config_local.php

맨티스 Email설정

• 이 파일을 수정하기 위해서 관리자 권한이 필요.

• 다음 명령어를 이용해서 수정할 수 있다.

– sudo vi config_inc.php

• Config_local.php를 포함하고 있음.

config_local.php를 수정하자.

Gmail계정을 추가해 보자.

새로운 유저 등록하기

• 새로운 유저를 등록하기 이전에 반드시 관리자 Email계정 설정이 필요하다.

• 왜?

– 새로운 유저를 등록하거나 이슈 관련한 사항들이 발견될 때 해당 유저에게 메일 전송을 해야 하기 때문이다.

새로운 계정이 생겼으니 메일을 확인해 보자!

• 보낸이는 Mantis Bug Tracker로 되어 있고 실제로 email계정은 앞서 맨티스 관리자의 email로 설정한 메일 주소로 보내졌다.

링크를 클릭해서 Verify해주자!

유의 사항

• Testaccount1로 유저가 생겼고 패스워드와 Real name과 같은 것들을 설정할 수 있다. Access level은 유저가 설정할 수 없고 관리자가 설정해 주어야 한다.

새로운 유저 등록 완료!

• 오… 아무런 이슈가 없다! (하지만 불안한걸…)

새로운 프로젝트를 만들어 보자! • 관리자 계정으로 로

그인 해야 한다.

• 프로젝트가 생겼다

프로젝트 설정 • 앞서 마찬가지로

관리자 권한으로 로그인.

• 사용자 관리 클릭

프로젝트 설정

프로젝트 설정 • 선택 후 사용자

추가.

프로젝트가 설정 되었다!

권한 설정이 필요할 경우

• 왜 하는가?

–프로젝트 매니저, 개발자, QA 등등

이슈 보고하기

• 새로운 이슈가 생겼을 때 이슈를 보고 한다.

• 첨부 파일 추가가 가능하다 (그림 파일, 동영상, 로그 등등)

프로젝트가 한 개도 아닌 두 개 라면! • 다음 그림이 이슈를 보고

할 때 마다 나오지 않음.

• 한번 이슈를 보고 하기 시작하면 해당 프로젝트에 이슈를 계속 보고하는 것으로 생각하고 프로젝트가 설정이 됨.

다른 프로젝트를 선택하고 싶다면?

새로운 이슈가 생겼다!

하지만 이슈가 할당 되지 않았다. • 이 이슈를 해결해야 할 사람에게 할당해 주어야 한다.

이슈 할당 하기 • 이슈를 누군가에게 할당을 하려면 권한 설정이 바뀌어야 함.

– 단순한 보고자는 이슈 할당을 할 수 없음.

• 관리자 계정으로 이슈를 보고하면 [할당하기]라는 메뉴가 있음.

관리자가 아니어도 할당이 가능! • 물론 권한 설정은 보고자가 아닌 다른 것으로 해야 함.

보통 권한 설정 구성은 어떻게?

개발자

개발자

개발자

매니저 보고자

보고자

모든 길은 매니저로 통한다.

• 매니저(보통 프로듀서가 이 역할을 맡는다)

–매니저가 이슈의 우선순위에 따라 이슈를 개발자에게 할당한 후 일을 진행하거나 버그를 Fix한다.

• 개발자는 매니저에게 받은 이슈를 최우선으로 고친다. – 우선 순위에 밀린 버그들이 고쳐지지 않는 단점도 있지만…

– 사소한 문제 때문에 개발 스케줄이 밀리는 것이 더 큰 문제.

아무튼 매니저가 이슈를 할당

• 테스트를 위해서 testaccount1가 개발자로 권한 설정을 바꿈.

개발자가 된 testaccount1

• 이제 매니저 혹은 관리자가 이슈를 testaccount1에게 할당 할 수 있다.

Testaccount1에게 할당 한 후 할당 버튼 클릭!

이슈 상태 수정하기

• 개발자가 된 testaccount1는 이슈를 하나 할당 받고…

–이제 이것을 고치기 위해서 노력한다.

• 하지만 일을 시작하기 전에 이슈의 상태를 변경.

이슈를 검토하고 있다면 이슈 검토를 선택하고 상태 변경 클릭

이걸 왜 하나?

• 매니저가 어떤 일이 진행되고 있는지 알 수 있음.

• 개인적인 경험상…

– 안 해도 상관은 없음. • 이슈를 보자마자 수정할 수 있다면!

–며칠이 걸리는 작업이라면 반드시 해야 함.

드디어 버그를 고쳤다!

• 그렇다면 이슈를 다시 매니저에게 돌려주자.

만세

이봐… 그게 끝이 아니라구

• 매니저는 해결된 이슈를 진짜 해결되었는지 확인 해야 함. – 보통은… QA에게 다시 이 이슈를 줌.

• QA가 해결된 이슈로 확인이 되면 그때 이슈를 [닫음] 처리 가능함.

– 작은 회사들은 보통 매니저가 직접 하던가 개발자가 직접 닫음 처리 함. • 하지만 개발자가 [닫음]처리 하는 것은 비추천.

– (믿을 수… 있겠니…?)

첨부 파일 추가

• BTS를 사용하는 최대 장점은 첨부 파일 추가 가능하다는 것. 그리고 까먹지 않는다는 것.

이슈를 보고 할 때

• 파일 업로드가 가능함.

Mantis로 스케줄 관리도 가능!

• 보통은 버그를 관리하기 위해서 BTS를 사용하지만 스케줄을 관리하는데 사용할 수도 있음.

• 태스크 단위로 일을 할당 받아서 일하는데 익숙한 사람들은 이런 형태로 일을 하는데 편하다는 것을 느낌. –성취감도 있음!

Mantis로 스케줄 관리

• 버그 발견 시 즉각적으로 처리할 수 있는 수준이라 하더라도 기존에 개발자가 하던 일이 있을 경우 인터럽트가 되면 시간 낭비가 생김.

• 이때 이슈를 보고해 매니저가 필요한 시기에 이슈를 각 개발자에게 할당 하면 됨.

Mantis로 스케줄 관리

• 개발자는 이슈를 하나씩 수정할 때 마다 얼만큼의 시간이 소요되는지 경험을 통해서 알 수 있게 되고 결과적으로 이후 프로젝트를 진행하면 할 수록 시간을 더 정확하게 할당해서 업무 처리가 가능.

Mantis로 스케줄 관리

• 강연자가 작업했던 축구 게임의 경우 막바지 작업을 할 때 버그 개수는 약 7천여 개 수준이며 이것을 주어진 기간 내에 몇 명의 개발자가 몇 개씩 수정해 나갔을 때 최종적으로 (7천여 개 모든 버그를 다 수정할 수는 없음) 릴리즈를 해도 되겠다는 수치가 나옴.

• 이것을 이용해 이후 프로젝트 혹은 진행되는 프로젝트에 적용해서 스케쥴을 미리 예측할 수 있음.

팔라독은?

• 강연자의 예를 들면…

–팔라독 아이패드의 경우 하루에 약 7개 정도 수정을 했으며 보통 QA가 테스트 할 때 마다 20개 정도가 나옴.

–물론 이때 매니저가 모든 이슈를 개발자에게 할당하지 않고 중요도에 따라서 할당함으로써 언제나 게임을 출시 할 수 있는 준비를 할 수 있음.

팔라독은?

• 이것을 통해서 알 수 있는 것은 예를 들어 평소 7개씩 수정 가능한 개발자가 7개 이하를 수정했을 때 매니저가 개발자에게 어떤 병목 사항이 있었는지 알 수 있음.

• 그리고 그 병목사항을 알아내서 고치려는 노력이 필요함. (예를 들어서 리소스가 늦게 나온다 던지 휴가가 있다던지, 아니면 LOL에 빠졌다던지… 등등)

• 팔라독 아이패드의 경우 프로젝트 막바지에 총 179개의 버그가 있었으며 모두 해결 하였음.

• 강연자의 경우 하루에 보통 3~7개까지 버그를 고칠 수 있었으며 계산해 보면 버그 고치는 데만 평균 44일 걸렸다는 것을 알 수 있음.

버그 트래킹 소프트웨어를 사용해서 얻는 장점?

• 유실의 가능성이 적어진다. • 프로젝트가 어떻게 진행되는지 더 구체적으로 알 수 있다.

• 계산이 가능하다.

–계산이 가능하기 때문에 예측이 가능하다.

마지막으로 팁…

• 버그 트래킹 시스템을 사용할 때 무엇보다 중요한 것은 빌드 번호를 관리하는 것이다.

• 빌드 번호가 무엇인가?

빌드 번호를 표시하는 이유?

• 가령 현재 빌드 번호가 10번이라고 치자…

–버그를 발견한 사람이 이슈를 보고할 때 어떤 빌드를 가지고 게임을 했을까?

–빌드 번호를 표시하지 않을 경우에는 개발자 외에는 이것을 알 수 있는 사람이 없다.

빌드 번호를 표시하는 이유?

• 이슈 보고자가 실행했던 빌드의 번호가 9번 이었다면?

–혹시 이 이슈는 이미 빌드번호 10번에서 해결된 이슈는 아닐까?

• 다른 예로…

빌드 번호를 표시하는 이유?

• 예를 들어 개발자가 이슈번호 19번을 해결했다. 그리고 메모에 다음과 같이 적는다. –이슈 19번 해결했습니다. 빌드번호 30번.

• 그리고 다시 QA가 게임을 실행했을 때… –이슈 19번이 해결된 것 같지가 않아!!

–그러면 이슈를 다시 개발자에게 돌려 보내야할까?

빌드 번호를 표시하는 이유?

• NO

– QA는 이슈를 테스트할 때 빌드 번호를 먼저 체크 해야 함. 왜냐하면 실행하고 있는 빌드 자체가 옛날 버전일 수도 있기 때문.

빌드 번호를 표시하는 이유?

• 멋있음

–팔라독 아이폰의 경우 버전이 3.0이 넘고 있으며 2년 이상 계속해서 업데이트하고 있음.

–물론 유저들은 잘 모름.

질문

감사합니다