박승필 
추석 연휴 마지막 날이다. 3일간 가족들에게 열심히 봉사했으니, 마지막 날은 나만의 시간을 가지리라 생각하고 커피숍으로 향했다.
오늘 하고자 했던 일은 인수인계 받게 될 프로젝트의 히스토리 파악하기였다. 초기 개발팀의 컨플루언스에 남겨진 이벤트스토밍, 회의록 등을 보면서 참 재밌게 일하는 팀이라는게 느껴졌고 보는 나도 즐거운 마음으로 읽어내려갔다. 운영팀으로 이관한 후의 릴리즈 이력도 보았다. 회사에서 나를 고용한 이유가 DEVOPS 문화 정착에 있기 때문에, 더 유심히 살펴보았다. 3~5 일 간격으로 배포작업이 있었고 몇가지 이슈를 한번에 처리하고 있었다. 얼마만큼의 공수가 동원되는지 커밋이력도 비교해 살펴보았다.
CICD 배포 시스템은 구축하였지만, 배포가 좀 편해지고 에러 추적이 편리해졌다.. 라는 점 이외에는 고객이 실제 느끼는 장점은 현재 없다. 여기서 더 나아가 고객이 체감하기까지는 업무적 시스템이 뒷받침 되어야 하는데, 혼자 정할 수 있는 것도 아니고 팀 내 공감대도 형성되어야 하고, 시간적으로도 시기적절한 때가 와야 할 수 있는 것이기에.. 일단은 내가 할 수 있는 부분만큼은 미리 공부 해 놓기로 했다.
오늘 공부의 멘토는 디프로그웍스의 신철민 대표님이시다. 몇년 전 알아둔 지인분으로, 현재는 프로세스 혁신 컨설팅 (JIRA를 베이스로 하는 업무기반시스템 구축), BPMN(Business Process Model & Notation) 교육, Atlassian Toolset 전문가 등으로 활동 중이시다. 예전에 기억으로는 JIRA 워크플로우를 굉장히 잘 짜셨던 걸로 생각이 난다. 책도 쓰셨지만 사서 보지는 않았다. 인터넷에 관련 강의 자료를 찾아보았는데 동영상 강의가 있었다. 한시간 알차게 이론 교육을 들었고 실무는 자료를 찾아가며 독학으로 진행하였다.
워크플로우 구성
회사 JIRA 에 어드민 권한이 없으므로, 트라이얼 계정을 하나 만들어 진행하였다.
JIRA 워크플로우를 만들기 전에 현재 팀이 가지고 있는 제반사항들을 살펴보았다.
- 릴리즈 싸이클
- 릴리즈 일자를 정해놓고 이슈사항들을 한번에 배포한다.
- 릴리즈 전/후로 매뉴얼 테스팅을 진행하는 듯 하다.
- 릴리즈 전/후로 기획자는 리뷰 겸 테스팅을 함께 진행하는 듯 하다.
- CICD 도입으로 활용가능한 싸이클
- 개발/퍼블리셔가 Merge Request 한 것은 개발서버로 즉시 배포된다.
- QA/기획자 선에서 리뷰 후 배포 버튼 클릭으로 배포가 가능하다.
- QA/기획자 선에서 배포 후 롤백 버튼 클릭으로 롤백이 가능하다.
해당 제반 사항들을 바탕으로, JIRA 워크플로우를 다음과 같이 구성 해 보았다. 릴리즈 일자를 정해놓는 방식이 아니라, 이슈 해결시 바로 배포하는 프로세스를 가정하였다.
Admin -> Settings -> Workflow
개발 -> 개발배포 -> 리뷰(기획) -> 테스트 대기 -> 메뉴얼테스팅 -> 프로덕션 배포 -> 롤백 의 대략적인 큰 틀을 잡고, 각 상태 전환시 버그가 발견되거나, 기획의 의도와 맞지 않아 재개발 해야 되는 플로우를 추가하였다. 그리고 바쁜 QA 를 위해서 QA 일정 대기 상태도 추가하였다.
워크플로우 활성화를 위해서는 Custom Field, Issu type, Screen 등을 추가로 구성해 주고, 각각의 Schema 구성을 통해 Project 를 지정해 주어야 한다. 생각보다 복잡한 과정이지만 Jira 문서로 대체할 수 있으므로 상세히는 적지 않는다.
Screen 구성
제작한 워크플로우에 맞는 몇가지 Screen 을 구성 해 보았다.
Putting on hold
작업이 홀딩 상태에 들어갈 때 이유를 적음.
OPEN -> Putting on hold -> ON HOLD
작업 기록과 시간 추적
소요 시간, 시작일, 남은 예상 작업 시간 등을 기록하는 JIRA 제공 필드이다. 시간이 소요되는 작업인 경우에 쓰이도록 하였다.
- 개발 서버 배포 완료 시
- 리뷰 실패 시
- 리뷰 성공 시
- 메뉴얼 테스팅 중 버그 발견 시
- 메뉴얼 테스트 성공 시
Code improvements needed
리뷰 실패시 이유를 적음.
IN REVIEW -> Code improvements needed -> REVIEW FAIL
KANBAN 구성
신규 프로젝트이거나 릴리즈 배포 단위에는 스플린트 보드가 어울리고, 애자일 개발에는 칸반 보드가 시각화 하기 더 좋다는 멘토의 강의에 따라 칸반 보드를 설정 해 보았다.
칸반 설정 화면
시간의 흐름대로 칼럼을 나열하고, 각 Status 를 배치하였다. 재작업 대기, 테스트 대기 등 대기 목적에 따라 다른 대기 상태로 있는 경우 별도의 칼럼을 생성하도록 설정하였다.
칸반 보드
이후 실제 사용에서는, 이슈 상태를 변경하거나, 칸반 보드에서 좌우로 드래그 하면 그에 맞추어 보드와 이슈 상태가 동기화 되는 것을 확인하였다. 프로젝트를 조망하는 입장에서는 미결 이슈들의 진행 상태를 한눈에 파악하기 용이해 보였다.
GITLAB / CICD 연동
남은 것은 소스코드 이력과 JIRA 이슈 연동인데, 다음 동영상을 참조 하면 좋다.
지라 이슈트래커와 깃랩 연동하기
또 CICD 상황 (개발/프로덕션 배포 완료되었다든지, 배포나 빌드가 실패하였다든지) 에 따라 ISSUE 들이 자동으로 상태가 바뀌어야 이슈 관리하는 입장에서 편할 것인데, 이것은 팀 내 공감대가 형성되고 실제적으로 수행하자는 분위기가 되었을 때 맞추어 개발 해 주면 될 것 같다. 해가 가기 전에 때가 왔으면 좋겠다.
QueryDSL Example