Github Projects로 옮기면서 개발 프로세스를 조금은 다르게 가져가야겠다 싶은 생각에 나름 정리해본 프로세스 인데 이제 죄다 갈아엎은

---

작업 단위 개발 흐름

다른 곳에서 어떤 식으로 티켓을 진행하는지 많이 참고해봤는데, 거의 모든 흐름이 사실 기존에 있던 회사 서비스를 유지보수하는, 말 그대로 일반적인 '이슈'의 영역이라 저희(취준생)가 진행하는 사이드 프로젝트와 사뭇 다른 점이 많았어요.

그래서 나름대로 괜찮은 부분들을 뽑아내고, 복잡하지 않되 부족함이 없게 흐름을 잡고자 했어요. 덕분에 두통을 좀 호소

프로젝트(Projects) Board 구조

저희는 다음과 같은 Status로 정의했어요.

Ticket Status

Status	설명
Draft Todo	FE, BE가 해야할 일을 초안으로 작성해요.
Todo	FE/BE 담당자가 Draft Todo를 토대로 상세히 이슈를 작성해요.
In Progress	작업을 진행해요.
Await Reviews	작업이 끝나고 코드 리뷰를 기다려요.
Done	작업 완료!

일반적인 Kanban 보드(Todo / In Progress / Done)에 Draft Todo, Await Reviews를 추가한 형태에요.

Draft Todo는 FE와 BE가 해야 할 일을 PM이 초안으로 작성하는 부분이에요. 사실 소규모에서는 없어도 되는 상태일 것 같기도 한데,, PM의 역할을 명확히 하자는 의미에서 만들었어요. 사소한 이슈 때문에 상태를 만든 것도 있는데, 요 부분은 아래에서 다뤄볼게요.

Await Reviews는 작업이 끝나고 나서 코드 리뷰를 기다리는 부분이에요. 코드 리뷰가 없는 곳이라면 생략할 수 있을 것 같아요.

개발 흐름

위의 상태를 기반으로 다음과 같이 진행해요.

상태에 따른 할일

Draft Todo

0. Frontend와 Backend 회의를 통해 각 팀이 해야 할 일을 정리 (PM)
1. 해야 할 일을 토대로 Draft Todo 작성 (PM)

---

Todo

2. Draft Todo를 토대로 Issue 본문 작성 (Develper)
3. Issue 메타 정보(Labels, Milestone, Development) 기입 (Develper)
4. Issue Branch 생성 (Developer)

---

In Progress

5. Issue Branch를 Local로 땡겨와서 작업 시작 (Developer)
6. Commit에 Issue Number 기입 (Developer)

---

Await Reviews

7. 작업한 내용 Push후 PR 요청 (Developer)
8. 코드 리뷰 진행 (Reviewer)

---

Done

9. 코드 리뷰 진행 후 개발 브런치에 Merge (Developer)
10. Merge Commit에 PR Number 기입 (Developer)

상태 구분하며 생긴 궁금증

1. 개발자가 Draft Todo 없이 직접 Todo를 만들면 안 되나?

- 안 되는 건 아니겠지만, 그러면 PM이 프로젝트 관리하기 어려워진다. 자기가 모르는 할일이 계속 추가되는 셈이니까.
- 만약 개발자가 Draft Todo엔 없지만 필요한 할 일이 생긴다면 PM에게 요청하는 식으로 가야 할 것.
- 관리는 PM이, 개발은 개발자가!

2. 코드 리뷰 후 수정을 하게 돼도 Await Reviews에 남아있는가?

- Review 후에 수정을 하게 된다면 다시 개발 상태로 돌아가는 형태이므로 In Progress로 옮겨야 할 것이다.
- 다시 Push 하면 해당 PR에 커밋이 업데이트 되므로, 그때 다시 Await Reviews로 옮기는 식.

3. Commit에 계속 Commit Number를 기입해야 하는가?

- Issue Branch에 딸린 Commit이니 해당 이슈겠구나 생각할 수 있지 않나? 라는 의문이 생겼는데, 나중에 머지를 하고 Revert할 경우가 생기면 해당 문제와 관련된 커밋을 찾아야 하므로 Commit Number를 추가함이 맞다.

---

Project 관련 설정

Github Project를 더 잘 쓰기 위해서 필요한 설정이 있어요. 요 부분을 정리해볼게요.

Issue Template

Project에서 생기는 모든 Ticket은 Issue로 생성이 됩니다. 해당 Issue는 Repository에서도 볼 수 있는데요, 팀 간의 소통이 더 잘 되기 위해선 Issue의 형식이 일정하면 좋겠지요?

다만 문제가,, Github Project에서 제공하는 Draft Issue에는 Issue Template을 적용할 수 없다는 점이었어요. PM이 Draft를 만들 때 해당 Template까지 제공해주고 내용만 채울 수 있게 해주려고 했는데, Template 자체를 쓸 수 없다 보니 난감했어요.

어떤 곳에서도 Issue Template을 쓸 수 없음 ㅠ

Repository에서 직접 만든 Issue를 Project에 Link할 수도 있어서, 그렇게 해야 하나 했는데, 또 그렇게 하게 되면 PM이 너무 번거롭게 되더라구요.

이것저것 찾아본 결과,, 이에 대해 의견을 제시한 이슈들이 많았습니다. 근데 왜 만들어주질 않는가

결론적으로 Draft에서는 Template을 쓸 수 없고, 결국 꼼수(?)를 이용한 방법은 Issue Body에서 Slash Command를 사용하는 것이었습니다. Issue로 전환한 뒤 수정을 통해 Template을 불러오는 방법이에요.

Slash Command를 통해 Template을 불러올 수 있다.

그렇기 때문에 PM이 아니라 개발자들이 Todo를 만드는 것이 더 깔끔한 흐름이었고, 개발자가 Issue Template을 사용해 이슈를 작성하게 되었어요. 야호

Views

Project를 처음 설정하면 Github에서 제공하는 기본 템플릿만으로도 괜찮지만, 직접 만드는 걸 선호하는 저는 다음과 같이 View를 만들었어요.

Backlog

티켓들을 관리할 수 있는 화면이에요.

Sliceby

Backlog는 Kanban 보드 형식을 따라요. Sliceby로 왼쪽엔 Repo를 기준으로 볼 수 있게 해놨는데, 저희는 한 Repo 안에서 폴더 구분을 통해 BE/FE를 나눈 것이 아니라 Repo 자체를 나눴기 때문에 이를 통해 BE에 해당하는 것, FE에 해당하는 것을 쉽게 확인할 수 있었어요.

또, Repository 기준이 아니라 다른 기준으로 볼 수 있었기에 보기 더 편했던 것 같아요. 개발자들이 본인에게 해당하는 작업을 보려면 Assignees에 들어가서 볼 수도 있었어요.

참고로 Sliceby의 기준을 바꾸면 View를 바꾸는 행위로 받아들여서 오른쪽 상단에 해당 설정을 저장하는 버튼이 활성화되므로 조심하셔야 합니다요.

Configuration/fields

티켓마다 어떤 정보를 보여줄지 선택할 수도 있어요. 저는 위와 같은 필드를 선택했는데요, 그러면 아래와 같이 티켓에 대한 정보를 한 눈에 확인할 수 있어서 좋더라구요.

라벨이 많이 달리면 뭔가 있어보이기도 하고(?)

Sprint

일정을 관리할 수 있는 화면이에요.

일정이라기보단 스프린트 주기에 관한 내용이긴 합니다. 이번 스트린트에선 어떤 걸 개발할 건지! 다음 스프린트에선 어떤 걸 할 건지! 한 눈에 확인할 수 있어서 좋아용.

Labels

해당 Issue가 어떤 내용을 담고 있는지 나타내는 부분. Github에서 제공하는 기본적인 Label들이 있는데, 요 Label들은 프로젝트를 만드는 데에 필요한 Label이 아니라 유지보수에 가까운 느김이 더 커요. 위에서 언급했듯 Issue라는 것 자체가 그런 거니까...

그래서 이 부분을 사이드 프로젝트에 맞게 바꿔줄 필요가 있는데, 보통 Commit Convention과 비슷하게 가져가는 듯 해요.

출처: Github label 커스텀 적용하기(도비의 Back-end 개발일기)

검색하면 제일 많이 나오는 Label을 가져왔습니다. 이 Lable을 기준으로 상황에 맞게 추합하면 될 것 같아요.

github-label-sync

그런데~ 해당 Label을 일일이 다 만들기엔 귀찮지 않겠어요? 그래서 github-label-sync 라는 패키지를 이용하면 손쉽게 바꿀 수 있다고 해요. 자세한 설정은 여기를 참고하시고, 여기에서는 labels.json만 공유해보겠습니다 !

Labels

[
  {
    "name": "⚙ Setting",
    "color": "e3dede",
    "description": "개발 환경 설정"
  },
  {
    "name": "✨ Feature",
    "color": "a2eeef",
    "description": "기능 개발 관련"
  },
  {
    "name": "🌏 Deploy",
    "color": "C2E0C6",
    "description": "배포 관련"
  },
  {
    "name": "🎨 Publising",
    "color": "FEF2C0",
    "description": "Markup & Styling"
  },
  {
    "name": "🐞 BugFix",
    "color": "d73a4a",
    "description": "버그 수정 관련"
  },
  {
    "name": "💻 CrossBrowsing",
    "color": "C5DEF5",
    "description": "브라우저 호환성 관련"
  },
  {
    "name": "📃 Docs",
    "color": "1D76DB",
    "description": "문서 작성 및 수정"
  },
  {
    "name": "📬 API",
    "color": "D4C5F9",
    "description": "API 관련"
  },
  {
    "name": "🔨 Refactor",
    "color": "f29a4e",
    "description": "코드 리팩토링 관련"
  },
  {
    "name": "🥰 Accessibility",
    "color": "facfcf",
    "description": "웹 접근성 관련"
  },
  {
    "name": "✅ Test",
    "color": "ccffc4",
    "description": "Test 관련"
  }
]

Milestone

Jira에서는 이런 식으로 서비스 기능 단위로 관리를 해주고 있었는데요, Github Projects에서는 이걸 어떻게 설정할 수 있나 고민하다가 생각해낸 게 Milestone입니다.

사실 Milestone은 이렇게 쓰는 게 아니지만(ㅋㅋ) No due date로 설정해놓으면 한 기능 단위에 대한 이슈를 모아볼 수 있어서 좋더라구요.

요런 식으로! 아쉬운 건 Milestone은 조직 단위가 아니라 레포 단위라, BE와 FE에 하나의 Milestone을 지정해줄 순 없는 게 아쉽더라구요. 머 그래도 만족!

---

이정도면 Github Project를 처음 쓰긴 해도 적절히 잘 구성이 된 것 같아서 만족 중 ^~^ 앞으로 더 쓰면서 수정해나가면 될 것 같다요!