CUBRID는 Open Source DB로 국내 데이터베이스 제품이다.
CUBRID DB Engine 스터디를 통해 12주 동안 코드 분석을 진행하였고, 그 스터디의 마지막 과정으로 이슈를 할당받아 해결하는 것으로 스터디를 마무리하게 되었다.
CUBRID 개발 프로세스는 다음 두 도구를 기반으로 운영된다.
CUBRID의 모든 프로젝트, 기능추가, 버그수정은 JIRA 이슈 생성으로부터 시작된다.
JIRA의 Issue workflow에 따라 문제를 정의, 분석하는 단계를 지나 설계 및 구현을 시작하게 된다.
설계 및 구현 단계에서는 Github에서 브랜치 생성, Pull Request, 코드 리뷰를 통해 검토/검증 과정을 거친 후 CUBRID에 코드를 반영한다.
큐브리드는 JIRA를 사용하여 프로젝트를 관리하며 모든 변경사항은 이슈를 단위로 하여 관리한다.
JIRA 이슈는 진행 상황에 따라 위 그림과 같이 7가지의 상태 (OPEN, CONFIRMED, IN PROGRESS, REVIEW IN PROGRESS, REVIEWED, RESOLVED, CLOSED) 를 가진다. 처음 이슈를 생성하면 “OPEN” 이고, “CLOSED” 로 모든 기여 작업이 완료된다.
예를 들어 “OPEN” 상태에서는 프로젝트 메인테이너가 해당 이슈에서 Triage(분류)를 진행하고, “CONFIRMED”에서는 지정된 개발자가 이슈에서 개발을 진행한다. 또 “RESOLVED”에서는 QA 메인테이너가 이슈의 QA 수행을 관리한다.
다음과 같은 화면에서 이슈 등록을 진행한다.
개발자 가이드 문서에 가보면 이슈 등록시 지켜야 할 양식이 정해져 있으니, 양식을 지켜서 이슈를 등록해야 한다.
https://www.cubrid.org/contributor_agreement
ICLA (Individual Contributor License Agreement) 라이센스를 얻어야 기여를 진행 할 수 있다.
홈페이지의 링크로 이동하여 절차에 따라서 ICLA 라이센스를 얻는다.
Issue가 confirm되고 작업을 하는 과정이다.
Start work 버튼을 눌러 이슈를 시작한다.
CUBRID의 레포를 내 github로 fork해와서 작업을 진행하게 된다.
작업 하는 브랜치는 CBRD-Issue번호
브랜치로, JIRA 이슈번호와 동일한 숫자이다.
이슈에 해당되는 문제의 코드를 수정한 뒤, 내 브랜치 (CBRD-XXXXX)에서 CUBRID의 develop브랜치로 PR을 작성한다. PR 역시 정해진 양식이 있으며, JIRA 링크로 시작해야 한다.
PR을 작성한 후에는 Jira에 다시 돌어와서 submit a fix 버튼을 눌러 리뷰 준비가 되었음을 표시해 준다.
Reviewer분들이 리뷰를 진행해 주는 과정이다.
어느 부분이 더 개선되면 좋을 것 같고 이 방식보단 저렇게 고쳐보는것이 어떻겠느냐? 등등 많은 조언을 해주시고, 3명의 리뷰어에게 승인을 받아야 Merge 될 수 있다.
내가 진행 한 이슈
12주동안 Cubrid라는 데이터베이스의 모듈인 Double Write Buffer 분석을 진행하였는데, 작은 문제라도 할당 받아 기여하는 과정을 경험해 볼 수 있어서 값진 경험이였다.
오픈소스의 매력을 느낄 수 있엇고, 현업에서의 PR과 Review 문화를 체험해 볼 수 있는 과정이었다.