JIRA 이슈 등록 <OPEN>
Last updated
Last updated
새로운 개발 안건을 시작하거나 버그를 발견한 경우에 Jira 이슈를 생성합니다. 이슈 생성 절차 및 작성할 항목은 이슈 작성 절차에서 설명합니다. 이슈의 초기 상태는 “OPEN”으로 설정되지만, Triage를 통해 승인을 받기 위해서는 이슈 작성 완료 후 메인테이너에서 이슈를 "To Triage" 버튼을 눌러 프로젝트 메인테이너에게 전달해야 합니다.
이후 필요에 따라 각 상태로부터 다시 “OPEN” 상태로 되돌아갈 수 있습니다. 이슈 진행 중 어떤 상태 (CONFIRMED, ANALYSIS, DEVELOP, HANDOVER, RESOLVED)에서도 해당 이슈의 재확인이 필요한 경우 “Ask Reconfirmation” 버튼을 눌러 이슈의 상태를 “OPEN” 으로 되돌리면 자동으로 프로젝트 메인테이너에게 이슈가 할당됩니다. 또한, 완료된 (CLOSED) 이슈도 추후에 문제가 발생되면 “Reopen Bug” 버튼을 눌러 해당 이슈의 상태를 “OPEN” 으로 변경할 수 있습니다.
이슈를 생성할 때에는 하나의 이슈로 여러 문제를 다루지 말고, 가급적 문제를 쪼개어 여러 이슈로 나누어 처리하는 것이 좋습니다.
1. JIRA (jira.cubrid.org)에 로그인 후 상단의 오렌지색 “CREATE” 버튼을 클릭합니다.
2. 새로 열린 “CREATE Issue” 창에서 각 필드를 다음 표의 설명에 맞게 작성하고 하단의 “Create” 버튼을 클릭합니다.
Field
Description
Project
프로젝트 범주를 선택합니다.
CBRD: CUBRID CAS, DB SERVER
APIS: CCI, JDBC 등 Driver
CUBRIDMAN: CUBRID 매뉴얼
TOOLS: CUBRID Manager, CUBRID Migration Tool
CUBRIDQA: QA 시스템, QA 테스트 케이스
Issue Type
이슈의 성격에 맞는 타입을 선택합니다.
Summary
이슈의 제목을 입력합니다.
Priority
기본값인 Minor로 항상 지정합니다.
메인테이너가 Triage 시에 필요하다면 변경합니다.
Components
모듈 단위 또는 프로젝트 단위의 범주를 지정합니다.
Description
“이슈 내용 템플릿”을 참고하여 작성합니다.
Affects version/s
이슈 생성자가 분석 과정에서 버그나 문제를 찾은 버전을 기록합니다. * 중요!: 버그이슈 등록 시 최신 develop 버전 뿐만 아니라 릴리즈된 이전 버전에 대한 확인이 필요합니다.
만약 이전 릴리즈 버전에서도 버그가 발생한다면 Affectd Version(s) 항목에 해당 버전을 추가합니다.
Label
자유롭게 설정할 수 있습니다.
* 메인테이너가 관리하는 레이블: cubrid.com, Good First Issue
Type name
Description
Correct Error
버그 또는 에러를 수정하는 이슈입니다.
Improve Function/Performance
기존의 기능을 개선하거나 성능을 향상시키는 이슈입니다.
Development Subject
새로운 기능을 추가하는 이슈입니다.
Internal Management
내부 관리를 위한 이슈입니다.
외부 기여와 관련없는 변경일 경우에 사용합니다.
예) 프로그램 또는 코드 내 버전 변경 10.2.0 -> 11.0.0
Refactoring
불필요한 코드 정리, 코드 구조 및 repo 분리 등을 변경하는 이슈입니다.
Task
위 이슈 타입에 해당하는 범주가 없을 경우 사용하지만, 권장하지 않습니다. (사용 예 : release)
Sub-task
이슈 내부에 생성되는 작은 단위의 이슈일 경우 사용합니다.
위의 이슈 타입의 sub issue로 사용 가능합니다.
Category Component
QP SM DS Utility
Module Component
Build
CI
Coding Style
Community
Document
Broker/CAS
Server Communication
CSQL
Query Parser Query Semantic Check Query Rewriter
Query Optimizer XASL Generator
Query Executor
Scan Manager
Schema Manager
Java SP
Backup/Restore
Buffer pool Catalog Disk/File DWB FBO
Heap Index Locator
Lock Log/Recovery
MVCC TDE Transaction
Vacuum
Failover HA Heartbeat Logcopier Logapplier
Replication
Component는 모듈 단위로 설정합니다. Component는 계층 구조로 구성되며 점점 세분화 됩니다. 이슈에서 다수의 Component를 선택할 수 있습니다. 위의 탭은 각 프로젝트 별 큐브리드 프로젝트에서 사용할 수 있는 Component입니다. 표에서 보는 것과 같이 CUBRID는 SM, QP, JavaSP, DS, Utility 등을 포함하고, 각 모듈 또한 다수의 모듈을 포함합니다.
이슈 생성 시, 해당 시점에 알 수 있는 연관 모듈을 선택합니다. 이슈를 분석하는 과정에서는 해당 이슈와 연관된 모듈 정보를 추가 선택할 수 있습니다. 예를 들어 SM 모듈에서 Buffer Manager를 개선하는 이슈인 경우, 이슈 생성 시 CUBRID, SM, Buffer를 선택할 수 있고, 이슈 진행 중에 File, Lock 모듈에 영향을 주는 경우 추가 선택할 수 있습니다.
CTE, TDE, JSON, Java SP등 여러 모듈에 영향을 주는 프로젝트인 경우 새로운 component를 생성하여 설정할 수 있습니다. 필요한 경우 프로젝트 메인테이너에게 요청하여 새로운 component를 생성할 수 있습니다.
이슈 생성 시 이슈 타입에 따라 다음의 템플릿을 복사하고, 필요한 항목을 작성합니다. > 필요한 경우 섹션을 추가 가능 > 템플릿의 섹션은 필요 없는 경우 제거하지 않고 N/A로 남겨두고 작성 > 아직 작성하지 못한 필드에 대해서는 TBD로 적어두고 확정되면 내용을 작성
템플릿은 이슈 타입에 따라 세가지 형태를 사용합니다.
Description
Test Build
Repro
Expected Result
Actual Result
Additional Information
Description: 이슈 설명
Test Build: Repro, Actual Result와 동일한 현상을 보여주는 빌드 버전을 commit 번호까지 상세히 기입합니다. 예를 들어 다음과 같이 기입할 수 있습니다:
CUBRID-11.0.0.0248-b53ae4a
JIRA 필드의 Affected version/s은 Major와 Minor 버전까지만 표시하는 반면, Patch와 Revision을 포함하여 실제로 버그가 발생한 구체적인 버전 명을 입력해야합니다.
버전명의 규칙은 Release/Version 섹션을 참고합니다.
빌드한 OS의 버전도 함께 명시할 수 있습니다.
Repro: 버그를 재현하기 위한 절차를 입력합니다. 버그 재현에 대한 설명을 적기 보다는 환경 재현/스키마 생성/질의 실행/유틸리티 실행 등의 모든 절차를 복사-붙여넣기로 재현 가능하게 작성해야합니다. (재현을 위한 테스트 프로그램은 첨부해야 합니다.)
Expected Result: 기대 결과 (고쳐져야 할 예상 결과)
Actual Result: 현재 결과 (문제가 있는 결과)
Additional Information: 추가로 버그 분석과 이해에 도움을 주기 위해 참고할 자료나 내용이 있다면 적어줍니다.
예시) CBRD-23903
Description
Specification Changes
Implementation
Acceptance Criteria
Definition of done
Description: 이슈에 대한 설명을 적습니다.
Specification Changes : 변경될 스펙을 정리하여 작성합니다. QA 테스트 정의, 매뉴얼 작성 등에서 활용할 수 있습니다.
Implementation: 이슈를 해결하기 위해 디자인 명세, 구현 컨셉 및 상세를 작성합니다.
Acceptance Criteria: 해당 이슈에 대해 요구사항에 따라 디자인과 구현을 수행하면서 선택하게 된 이슈의 범위 내에서 만족해야 하는 동작/결과를 정의합니다. 이 내용은 디자인/구현의 완료 판단(리뷰)의 기준이 됩니다. 만약 정의하지 않은 동작/결과가 크리티컬 하다면 디자인/구현에 대해 재검토할 필요가 있습니다.
Definition of done: 이슈를 완료하기 위해 어떠한 방법으로 검증할 수 있을지를 작성합니다. 다음 예시와 같이 기입할 수 있습니다.
Acceptance Criteria를 만족시킨다.
QA 테스트를 통과한다.
예시) CBRD-23894
Description
Description: 작업 내용에 대한 목적과 설명을 적습니다.
자세한 내용은“” 섹션을 참고합니다.
자세한 내용은 “” 섹션에서 설명합니다.
