(조금 길수도 있어 시간여유 되시고 피곤하시지도 않은 상태이신분들은 한번쯤 읽어보셔도 좋습니다.)
필자가 운영했던 Jira&Confluence에는 큰 문제가 있었다.
Project(Jira) 및 Space(Confluence) 생성에 별다른 제약이 없었기 때문에
User들이 무분별하게 Project와 Space를 생성했다...쓰지도 않을거면서:(
그 결과 issue 검색에도 오래걸리고 Re-Indexing 하는데도 반나절이 걸리기 쉽상이었다.
무엇보다 빈 깡통이 너무 많아 사용이력 분석이 제대로 될리 없었다.
간략히 설명하자면 위 모식도처럼 User가 사내시스템을 통해 Project&Space 생성을 요청하면
바로 REST를 날려서 생성해줬다.
그렇게 운영을 하던중...
기회가 되어 모우소프트(현 플래티어)에서 개최한 Atlassian 컨퍼런스에 참여하게 됐고,
카카오에서는 어떻게 Project&Space 생성 요청을 받는지 들을 수 있었다.
(근데 가장 기억에 남는건 그 분이 카카오 제주 근무하시고 취미로 낚시하시고
요즘 젊은 사람들은 제주로 안 오려한다 등등... 아이스브레이킹이 인상적인 분이셨다.)
각설하고 그분 설명에 따르면 카카오에서는 Project&Space 생성을 받는 Jira Project를 하나 생성해뒀고
User가 해당 Project에 issure를 등록하면 담당자가 컨펌해서 하나씩 생성해주는 방식이었다.
그 당시 필자와 사수님은 갓카오의 현명한 프로세스에 감명을 받아 사내에 도입하게 됐다.
여기서 잠까아아아아안!!! 아래나오는 프로세스는 모두 Adaptavist社의 ScriptRunner라는Add-on을 기반으로 설계했다. Workflow의 Transition마다 Condition을 줄 수도 있고 Post Function을 줄 수도 있다. 이 밖에도 너무 유용한 기능들이 많아서 Jira 비용 감축할 때도 어떻게든 들고 간 Add-on이다. 아마 대부분의 기업들이 이 Add-on을 쓰지 않을까 싶다.
우리는 갓카오와 같이 Project&Space 생성용 Project를하나 생성했고 Workflow는 대략 이렇다.
각 State에 대해서만 간단히 설명하면
Open : User가 Issue를 생성한 상태
Inspection : 담당자가 생성 여부 검사하는 상태
In Progress : 사내 시스템으로 Project&Space 생성 요청한 상태
Success : 생성에 성공한 상태
Failed : 생성에 실패한 상태
Resolved : 생성에 성공한 건에 대해 완료 처리한 상태
Closed : 생성에 실패한 건에 대해 강제 종료한 상태
좀 더 이해를 돕기 위해 아래 모식도를 첨부했다.
User가 Jira Project로 Project&Space 생성 요청을 하면 담당자는 검열을 하고
통과된 issue에 한해 Jira에서 사내 시스템으로 Webhook을 날려줬고
Webhook을 받은 사내 시스템은 다시 Jira나 Confluence에 REST를 날려서 생성해줬다.
결과적으로 효과는 좋았다.
사용이력 분석에도 용이했고 깡통 Project&Space들이 없어서 좀 더 효율적으로 이용할 수 있었다.
댓글