들어가며
팀 프로젝트를 진행하면서 frontend 코드와 backend 코드를 GitHub의 다른 레포지토리에 저장하고 있다. 이렇게 관리하니 문제가 발생했다. 버그를 발견했을 때, 이를 해결하기 위해서는 하나의 작업을 하기 위해 각각의 이슈를 찾아야 하는 문제가 발생했다. 이러한 문제를 해결하기 위해서는 이슈를 관리하는 방법이 필요했다. 이번 기회에 GitHub Project를 활용한 이슈 관리 방법을 정리해보려고 한다.
알아본 결과
프로젝트를 진행하면서 이슈를 관리하는 방법은 여러가지가 있다. 그 중에서도 내가 생각한 방법은 아래와 같다. 1개의 이슈 관리 레포지토리를 만들고 그 안에 모든 이슈를 관리하는 방법이다. 프로젝트에서 발생하는 문제는 이슈 레포지토리에서 이슈를 생성하고 frontend 레포지토리와 backend 레포지토리에 서브 이슈를 생성하서 관리하는 방법이다.
지금부터 이슈 트레킹 레포지토리는 I 레포지토리, frontend는 F 레포지토리, backend는 B 레포지토리라고 하겠다.
구조도를 그려보면 이렇게 된다.
graph TD
A[이슈 트레킹 레포지토리] --> B[프론트엔드 레포지토리]
A[이슈 트레킹 레포지토리] --> C[백엔드 레포지토리]
이렇게 하면 모든 이슈를 한 곳에서 관리할 수 있고, 버그를 발견했을 때 이슈를 생성하고 해결하기 위한 작업을 할 수 있다.
프로젝트 이슈 처리 프로세스
시퀀스 다이어그램을 그려보면 다음과 같다:
sequenceDiagram
participant 작업 발생
participant 이슈 트레킹
participant 프론트엔드
participant 백엔드
participant 작업
작업 발생 ->> 이슈 트레킹 : 1. 이슈 생성
이슈 트레킹 ->> 프론트엔드 : 2. 서브 이슈 생성
이슈 트레킹 ->> 백엔드 : 3. 서브 이슈 생성
프론트엔드 ->> 작업 : 4. 브랜치 생성 및 작업 진행
백엔드 ->> 작업 : 5. 브랜치 생성 및 작업 진행
작업 ->> 프론트엔드 : 6. PR 생성 및 머지
작업 ->> 백엔드 : 7. PR 생성 및 머지
프론트엔드 ->> 이슈 트레킹 : 8. 서브 이슈 완료
백엔드 ->> 이슈 트레킹 : 9. 서브 이슈 완료
이슈 트레킹 ->> 작업 발생 : 10. 메인 이슈 완료
I레포지토리에서 이슈를 생성한다.I레포지토리에서 이슈의 내용을 상세하게 작성한다.I레포지토리에서F레포지토리 서브 이슈를 생성한다.I레포지토리에서B레포지토리 서브 이슈를 생성한다.F레포지토리에서 이슈 번호로 브랜치를 생성하고 작업을 진행한다.B레포지토리에서 이슈 번호로 브랜치를 생성하고 작업을 진행한다.F레포지토리에서 PR을 생성하고 머지한다.B레포지토리에서 PR을 생성하고 머지한다.F와B레포지토리의 서브 이슈를 완료 처리한다.I레포지토리의 메인 이슈를 완료 처리한다.
앞으로의 계획
프로젝트에서 이슈를 관리하는 방법을 정리해보았다. 정리해본 방법은 완벽한 방법이 아니라 추후 변경될 수 있다. 팀원들과 함께 경험해보면서 좋은 방법을 찾아봐야겠다.
매일 반복되는 일상 속에서도 특별한 순간을 찾을 수 있기를 😊
최상단으로 이동했습니다!
Leave a comment