Jira 프로젝트들을 독립적으로 사용하기 위해 알아야 할 지식

무엇을 알려주려고 쓰는 글?

Jira에서 각자 프로젝트별로 독립된 스키마를 유지하기 위해서 명심하는건 개별 Project 메인화면 - Project settings에서 확인가능한 각 스키마를 단독으로 사용하는지 화면 상단에 Alert 박스로 보이는 Used by n Projects 부분을 잘 확인하면 된다. 단독사용이라면 ‘1’로 보일 것이다. 공통 스키마라면 공통으로 사용중인 프로젝트의 이름이 보일 것이다. 1이 아니라면 스키마를 복제해 독립하면 된다. 하지만 이런 원칙을 지켜도 가끔 프로젝트의 수정이 다른 프로젝트에 영향을 미치기도 하는 게 문제다. 이 글에선 그런 문제를 유발 할 수 있는 지라의 예외적인 케이스와 잘 모르면 오해하기 쉬운 케이스로 “1. 워크플로 내부의 State, Transition 네임수정 2. Simplified workflow 기능 3. Glbal scheme” 를 소개하려고 한다.

CASE (1) Workflows - State, Transition

명시적으로는 잘 표시가 안되어 있어서 생기는 문제인데. 워크플로의 State와 Transion 이름을 수정할 경우 스키마를 무시하고 해당 이름을 사용중인 모든 Workflowrk에 영향을 미친다. 예를 들어 A 워크플로에 ‘Backlog’ 란 이름의 State를 만들어 쓰고 있는 상태에서 B 워크플로에서 ‘Backlog’란 이름의 State를 만들어 쓰다가 ‘Todo’라고 이름을 바꿀 경우 A워크플로의 ‘Backlog’ State도 ‘Todo’가 된다. 이때 리눅스 파일 시스템으로 따지자면 State, Transition 파일들은 같은 이름의 ‘원본 오브젝트’를 하드링크한 상태라고 생각하라. 이런 영향을 경고하는 메시지가 수정할 때 뜨긴 하지만 스키마가 독립되어 있다는 생각에 메시지를 무시하기가 쉽다. 따라서 이를 수정하는 것은 예상하지 못한 변경을 일으킨다.
예를 들어 워크플로 A의 ‘Backlog’갯수를 대시보드에서 JQL를 통해 추적하고 있는데 ‘Backlog’의 이름이 ‘Todo’가 되면 쿼리가 깨지게 된다. 더 나쁜건 없는 상태 값을 찾는 JQL은 값을 0으로 돌려주는게 아니라 완전히 Query를 실패한 것으로 보고 응답을 주지 않아 대시보드 전체를 먹통으로 만든다.
이런 문제를 피하기 위해서 만약 이름을 바꿀때 다른 워크플로우에 영향을 끼친다고 경고를 할경우 이름을 바꾸지 않아야한다. 그 대신 워크플로에서 새로운 오브젝트를 만들고 그 이름을 바꿀 이름으로 하는게 안전하다. 대신 지라에선 state가 사용중일땐 state를 지울 수 없으니 임시 Transition을 만들어서 새로운 이름의 Issue로 옮기면 된다. 이렇게 하면 다른 프로젝트에 간섭없이 워크플로를 수정할 수 있다.

CASE (2) Simplifed workflow

프로젝트 생성시 shared configuration 또는 project copy 기능을 쓰지 않고 프로젝트를 생성하게 되면 Software Simplified Workflow for Project <이름>라는 워크플로가 생성되어 할당된다. 이 워크플로는 다음과 같은 description을 기본적으로 가진다. Generated by JIRA Software version 7.1.9-D20151208T191112. This workflow is managed internally by JIRA Software. Do not manually modify this workflow 뭔가 무서워 보이는데 이걸 수정해보면 정말로 큰일은 안난다. 이것을 수정하게 되면 무엇이 안되는가 하면 simplified workflow 기능을 쓸 수 없게 된다. (만약 수정한 상태에서 simplify workflow 기능을 쓰려고 하면 ERROR가 발생하면서 활성화 시킬 수 없다고 나온다.) 이 기능은 DASHBOARD-configure-좌측 Columns메뉴로 이동하면 볼 수 있다. 이 기능은 대시보드에서 컬럼과 상태 값을 만들면 그걸 workflow에 바로 반영시켜주는 기능이다. 하지만 이렇게 대시보드와 워크플로를 하나로 만들어버리면 Transition과 상태변화에 조건을 붙이는것과 같은 지라만의 컨셉이 배제된 극소적 기능만 사용하게 된다. 지라는 각 Transition에 대해서도 여러함수를 붙이거나 별도의 스크린을 만드는것도 지원하므로 그런 기능을 사용하지 못하는건 아쉽다. 따라서 프로젝트를 매우 유연하게 관리하려는게 아니라면 무섭게 보이는 이 문구는 지워버려 불필요한 오해는 피하고 수동으로 워크플로를 작성하는게 베스트다.

CASE (3) Default issue type scheme

Issue type scheme은 프로젝트가 어떤 issue들을 사용할지 정의하는 스키마다. 예를 들어 ‘A프로젝트는 버그, 이슈, AS를 사용합니다.’할때 버그, 이슈, AS가 바로 이 스키마다. 기본적으로 Jira에서 프로젝트를 생성하게 되면 자동으로 Issue types scheme을 생성해 프로젝트마다 하나씩 사용하게 해준다. 하지만 관리자 메뉴에서 할당된 스키마를 제거하거나 Project settings-Issue Types-Actions-Use a different scheme 메뉴를 통해 바꾸게 되면 Default issue Type Scheme이란 스키마를 사용하게 된다. (이 이름은 설정에 따라 바뀔 수 있다.) Default issue Type Scheme엔 지라에서 생성된 모든 Issue가 다 담겨 있고 edit을 통해 Issue를 뺴거나 지울 수 없는 유일한 특징을 가지고 있다. 모종의 글로벌 변수. 이 global 스키마를 쓰게되면 이슈 종류를 고를때 리스트가 너무 길어지고 사용자들도 어떤 이슈를 써야할지 몹시 난감할것이다. 다만 그런 행정적 이슈 말고는 기술적으론 문제가 되지는 않는다. 각 이슈가 가지는 Screen과 Workflow는 같은 이름의 ‘이슈’라도 프로젝트별로 독립적으로 설정이 되기 때문이다. 따라서 글로벌로 변수를 쓴다해도 너무 걱정할 필요는 없다. issue Type Scheme는 지울 수 있지만 프로젝트를 생성하면 자신의 프로젝트를 명으로 생성되는 Default Issue Screen과 Software Simplified Workflow는 지울 수가 없다. 따라서 안정적으로 각자의 스크린과 워크플로를 적용할 수있다. 하지만 나중에 별도의 이슈 type들만 사용하려고 뒤늦게 Issue type scheme을 설정하려고 할때는 Scheme Migration을 거쳐야하고 이때 대시보드의 필터가 뭉게지는 등의 사소한 사이드이펙트를 감수해야하니 global 스키마를 사용하지 않도록 관리하는게 베스트다. 더욱이 ‘Issue’는 workflow와 screen 등 조직의 핵심로직을 담아야하니 글로벌로 쓰는것은 옳지않다.