오픈비 : 삽질은없다

trac을 설치하고, customization했으니 이제 trac에서 사용되는 용어의 개념과 흐름(workflow)을 살펴 보도록 하자.

Ticket System

trac 은 ticket이라는 것을 사용하여 project를 관리하고, bug를 관리한다. ticket은 간단히 말하면 업무 내용을 전달하기 위한 수단이다. 즉, "이런 저런 문제가 있으니 해결하라" 라든가 "이런 저런 기능이 필요합니다"라는 등의 내용이 들어간다. ticket은 이러한 업무를 보다 구체적이고 효율적으로 지시(혹은 전달)하기 위해 많은 정보를 가지고 발행된다.
이 ticket이 가지는 정보는 다음과 같은 것들이 있으며, 이는 trac project의 관리자가 Admin tab의 Ticket System 부분에서 관리할 수 있다.

Components

Components(구성요소, 성분)는 원래 단어의 뜻대로 project의 구성요소나 성분을 뜻한다. component는 해당 project의 규모에 따라 함수나 module 수준이 될 수 있다.

예 를 들어 사용자로부터 두 정수(integer)를 입력 받아 평균을 구하는 작은 project가 있다고 치면 component는 main 함수, sum 함수, average 함수, input 함수, output 함수 등의 수준에서 구성될 수 있다.
조금 더 복잡한 예로, 간단한 게임을 만든다고 하면(tetris나 그림 조각을 맞추는 등의) component는 input, output, user interface, sound engin, game logic, graphic engine 등의 부분으로 구성될 수 있다.

Components에는 component 이름(name)과 소유자(owner), 설명(description), 기본 값(default)을 설정할 수 있다. 기본 값이 check된 component는 ticket을 만들 때 component 항목의 기본 값으로 설정된다.

ticket을 만들때 component를 지정하면 component 소유자의 email로 전달된다.

Milestones

milestone은 사전적인 의미로 길을 따라 일정한 간격으로 세워져있는 이정표를 말한다 (참조 : http://www.letsmakegame.net/?mid=data_dic&page=2&document_srl=5721 ). 최종 목표 이전의 중간 목표 정도라고 볼 수 있겠다.

예 를 들어 게임을 만든다고 하면, 기본적인 playable한 게임 수준의 첫번째 milestone, 거기에 intro, menu, background music, effect 등이 추가되는 두번째 milestone, 이후 bug 수정, valancing 등이 적용된 세번째 milestone을 정의 할 수 있다.

예는 이렇게 들었지만, 꼭 시간이나 기능순으로 나열할 필요는 없으며, 꽤 커다란 project로 다른 여러 subproject들이 함께 맞물려 개발될 때에는 각 subproject의 이름과 version이 하나의 milestone을 구성할 수 있다.

ticket에 milestone이 지정되어 발행되면 trac의 Roadmap tab에서 해당 milestone에 발행된 ticket의 수와 해결된 ticket의 수를 graph로 보여주어 해당 milestone의 진행률을 쉽게 알아 볼 수 있다.

Milesotnes에는 milestone 이름(name)과 목표 날짜(due), 완료 날짜(completed), 기본 값(default)을 설정할 수 있다. 목표 날짜를 설정하면 현재 날짜로부터 얼마나 남았는지 혹은 얼마나 초과되었는지 알 수 있다. 완료 날짜는 milestone을 완료했을 때 check하면 된다. 기본 값을 check한 milestone은 ticket을 만들 때 milestone 항목의 기본 값으로 설정된다.

Priorities

ticket의 우선 순위를 뜻한다. 기본 값은 blocker, critical, major, minor, trivial 순이다. 이것들은 우선 순위를 바꾸거나 다른 이름을 줄 수 있다.

이 우선 순위와 나중에 나올 Severities(중요도)와 헷갈릴 수 있는데, priorities는 시간상으로 먼저 해결해야 할 문제라고 이해하면 될 듯 하다. 물론 Severities가 높다면 priorities도 높은 경우가 많으므로 따로 Severities를 정의하지 않고 priorities만 가지고 project를 관리할 수 있으며, 실제로 trac은 Severities의 기본 값들을 채워주지 않고 있다.

• blocker : 개발이나 test를 더 이상 진행할 수 없게 만드는 문제점.
• critical : program이 crash되거나 data 손상, memory leak이 발생하는 문제점.
• major : 기능상의 중요한 결점, 일반적인 문제로 반드시 고쳐야 할 버그.
• minor : 기능상 그리 중요하지 않은 결점, 쉽게 해결 가능한 문제.
• trivial : 오탈자, text 정렬 문제 등의 외형적 문제.

priorities에는 priority 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 priority는 ticket을 만들 때 priority 항목의 기본 값으로 설정된다.

Resolutions

ticket 이 만들어 진 후 실무자가 ticket에 쓰여진 업무를 내용을 확인하여 처리하면 실무자는 ticket을 닫게 된다. ticket을 닫을 때 이 문제를 어떻게 해결했는지 - 혹은 그냥 놔 두었는지 - 표시하는 것이 이 resolution이다. resolution은 fixed, invalid, wontfix, duplicate, worksforme의 기본 값들이 정해져 있다. 이것들은 물론 이름이나 순위를 바꿀 수 있다.

• fixed : 해결됨.
• invalid : ticket의 문제는 bug가 아님.
• wontfix : 해결될 수 없는 문제임.
• duplicate : 기존의 ticket과 중복된 문제임.
• worksforme : 파악할 수 없음. 동일한 현상을 재현하려 했으나 재현이 안 되고, code를 봐도 해당 문제의 원인을 파악 할 수 없는 상태.

resolution 에는 resolution 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 resolution은 ticket을 만들 때 resolution 항목의 기본 값으로 설정된다.

trac customization post에서 svn commit hook을 설정해 두었다면, svn으로 commit 할 때 남기는 log를 통하여 fixed 상태로 ticket을 닫을 수 있다.

Severities

심 각도, 중요도 등을 뜻한다. trac에서는 severity의 기본 값을 표시하고 있지 않다. priority가 시간적으로 처리해야할 순위를 뜻한다면, severity는 일의 심각성, 중요도를 나타낸다. 일상 생활의 예를 들면, 전기세를 안 내면 전기가 끊길지도 모르지만 납부 기한이 많이 남아있는 경우 priority는 다소 떨어지더라도 severity는 높다고 할 수 있다.

trac에서는 priority만 기본 값이 들어가있고 severity는 무시되어 있는데, bugzilla를 살펴보면 priority와 severity가 분리되어 있다. bugzilla의 priority는 단순히 p1~p5의 다섯 단계로 각각 즉시, 긴급, 보통, 낮음, 없음으로 구성되어 있으며 severity는 blocker, critical, major, normal, minor, trivial, enhancement로 trac의 priority와 비슷하지만 좀 더 세분되어 있다. bugzilla의 enhancement는 trac의 ticket type에 enhancement와 같다.

ticket type의 존재로 bugzilla보다 trac쪽이 더 세세한 분류가 가능하지만 기본 값은 ticket type과 priority만 있고, priority는 bugzilla의 severity에 가깝다. Priorities 부분에서 언급했듯이, priority와 severity는 비례하는 경우가 많으므로 편의를 위해 기본 값을 이렇게 둔 모양이다.

severities 역시 severity 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 severity는 ticket을 만들 때 severities 항목의 기본 값으로 설정된다.

Ticket types

ticket의 형태를 뜻한다. 업무의 종류라고 볼 수도 있겠다. trac이 기본 제공하는 ticket type은 defect, enhancement, task가 있다.

• defect : 문제점. 현재 있는 기능이 가지고 있는 bug나 문제점을 뜻 함.
• enhancement : 개선사항. 현재 기능이 제대로 작동하고 있으나 기능을 확장하거나 개선시켜야 할 것들.
• task : 새로 추가할 기능이나 해야 할 일.

ticket type도 ticket type 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 ticket type은 ticket을 만들 때 ticket type 항목의 기본 값으로 설정된다.

Versions

project 의 version을 뜻한다. milestone이 비공개된 미래지향적(앞으로 release할 code, 현재 완성을 위해 개발 중인 code)인 제품이라면, version은 release되어 공개된 과거 지향적(이미 상품화된, 배포된)인 제품이라고 할 수 있겠다.
따라서, ticket을 만들 때 현재 개발 중인 milestone이 대상이라면 version 부분은 비워 놓아야 하며, 이미 개발 되어 release된 제품이 대상이라면 versions 부분을 채워야 할 것이다.

versions 도 version 이름(name)을 가지며, 날짜(Released)와 기본값(default)을 설정할 수 있다. 기본 값을 check한 version은 ticket을 만들 때 version 항목의 기본 값으로 설정된다.

Workflow

trac에서 ticket을 만들고, 실무자에게 할당하고, 해결하고, ticket을 닫을 때까지의 흐름(workflow)을 정리해 보자.

trac에서 기본으로 제공하는 workflow는 다음과 같다. 이 workflow가 마음에 들지 않는다면 새 workflow를 작성하여 적용할 수도 있다.

new

새 로운 ticket을 생성한다. TICKET_ADMIN이나 TICKET_CREATE 권한을 가진 사용자는 새 ticket을 만들 수 있다. 새 ticket은 trac의 main menu중 "New Ticket" tab을 선택하여 생성할 수 있다.
다음 정보들을 입력하여 새 ticket을 생성한다.

• Summary : ticket에 관한 요약된 정보.
• Reporter : ticket을 발행한 사람의 id.
• Description : ticket에 대한 자세한 설명. 설명은 trac wiki 문법을 사용하여 꾸밀 수 있다.
• Type : ticket 종류. Ticket Type 부분 참조.
• Milestone : 이정표. Milestones 부분 참조.
• Version : 판 번호. Versions 부분 참조.
• Cc : 참조(carbon copy). ticket을 mail로 보낼 때 참조할 사람.
• Priority : 우선 순위. Priority 부분 참조.
• Component : 구성. Components 부분 참조. 해당 component의 owner가 지정되어 있을 경우 owner에게도 ticket mail이 날아간다.
• Keywords : ticket의 내용에 대한 주요 단어.
• Assign to : ticket을 실무자에게 할당하기 위해 적어주는 id.
• I have files to attach to this ticket : ticket에 첨부할 file이 있을 경우 check.

ticket이 생성되면, component owner, Cc, Assign to, 관리자(trac.ini에서 mail을 함께 받도록 설정된)에게 ticket mail이 발송된다.
Assign to에 실무자 id가 할당되어 있으면 ticket은 발행되면서 assigned 상태로 옮겨진다.

new ticket을 받은 사람이 TICKET_MODIFY 권한을 가지고 있다면 해당 ticket을 실무자에게 할당(reassign) 할 수 있다.
new ticket을 받은 사람이 실무자이고 자신의 업무 분야가 맞다면 수락(accept) 할 수 있다.
new ticket을 받은 사람이 실무자이고 자신의 업무 분야가 맞다면 수락(accept) 과정을 생략하고 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
new ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 그대로 두면서 자신의 의견을 남길 수 있다(leave).

assigned

assigned는 할당된 상태를 뜻한다. 할당되어진 ticket을 받은 사람은 다음의 action을 취할 수 있다.

assigned ticket을 받은 사람이 TICKET_MODIFY 권한을 가지고 있으며 할당된 업무가 다른 사람의 업무라면 다른 실무자에게 ticket을 할당(reassign) 할 수 있다.
assigned ticket을 받은 사람이 자신의 업무 분야가 맞다면 수락(accept) 할 수 있다.
assigned ticket을 받은 사람이 자신의 업무 분야가 맞다면 수락(accept) 과정을 생략하고 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
assigned ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

accepted

accepted는 수락된 상태를 뜻한다.

accepted ticket을 받은 사람은 다시 수락할 수 있다(accept).
accepted ticket을 받은 사람이 자신의 업무 분야가 아니거나 자신의 범위에서 해결할 수 있는 문제가 아니라면 다른 사람에게 ticket을 할당(reassign) 할 수 있다.
accepted ticket을 받은 사람은 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
accepted ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

closed

해 결(resolve)되어 닫힌(close) 상태를 뜻한다. 실무자의  해결 방법에 따라 fixed, invalid, wontfix, duplicate, worksforme로 표시될 수 있다. 각 해결 방법은 Resolution 부분을 참조한다.

closed ticket을 받은 사람은 해당 ticket의 문제가 해결되지 않았다고 판단 될 경우 닫힌(close) ticket을 다시 열 수(reopen) 있다.
closed ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

reopened

문제가 해결되어 닫힌(close) ticket에 동일한 문제가 있어 다시 열린(reopen) 상태이다.

reopen된 ticket을 받은 사람은 다른 사람에게 ticket을 다시 할당(reassign) 할 수 있다.
reopen된 ticket을 받은 사람이 자신의 업무 분야가 맞다면 수락(accept) 할 수 있다.
reopen된 ticket을 받은 사람은 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
reopen된 ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

Time Line, Roadmap and View Tickets

위의 개념과 흐름을 참조하여 trac을 사용하다 보면 Time Line, Roadmap, View Tickets tab에 여러 가지 것들이 보이게 된다.

Time Line tab은 시간 순으로 ticket의 발행, repository의 변화(changeset), ticket의 상태 변화 등을 알 수 있다.

Roadmap tab은 milestone 기준으로 발행된 ticket, 진행된 ticket(closed), 마감 기한(혹은 초과한 기한)등을 확인 할 수 있다.

View Tickets tab은 여러 종류의 option을 통해 ticket을 정렬시켜 확인 할 수 있다. report라고도 하는데, report용 query 직접 만들어서 자신의 입맛에 맞게 ticket들을 살펴 볼 수 있다.

마치며

trac 의 기본 개념과 workflow 부분은 내가 충분히 이해할만큼 잘 정리되어 있는 한글 문서를 찾아내지 못 해서 따로 정리한 것이다. trac의 사용이 미숙하기 때문에 정확한 사용법까지는 posting하지 못 하지만, 여기에 정리된 개념을 사용하여 study하면 보다 세부적인 기능까지 다룰 수 있으리라 생각된다.

trac의 실제 사용법에 대해 깔끔하게 정리되어 있는 page가 있어 link를 걸어 둔다.