---
# System prepended metadata

title: Potato Project

---

# Potato Project

[PPT](https://docs.google.com/presentation/d/1Y52aBVXeISbKflYIwYKvDgPf9lTGoY3ul6r39bIADrQ/edit#slide=id.g11b06151018_0_229)



## Page 1 Intro

* 발표 시작 인사
  * 안녕하세요~
* Potato 라는 이름을 채택한 이유
  * 여러가지 의견이 있었음 Espresso, Salty, home 등
  * Daisy가 Potato 의견을 내었고 swit-potato 로 가기로 함~
* 서비스에 관한 이야기
  * 이 프로젝트는 `우선` BE 를 위한 issue-tracking 에 관한 프로젝트이다
  * 아까 말씀드린 이름 짓는거부터 시작해서 인프라 등등등 전부 올림 `(Oliver 요청 사항)`



## Page 2 SmallTalk

* 기간
  * 온보딩 끝나고 바로 다음 주부터 약 한달 동안 작업 진행하였어요~
* 인원
  * 올리버가 프로젝트 총괄하였고
  * 카이사가 프론트 부분을 담당하고
  * 나머지 세명이 백엔드 부분을 담당



## Page 3 Tech

* 프론트
  * 리액트이고
* 백엔드
  * 언어는 Go,
  * DB는 Mysql, redis 사용했고
* 인프라
  * GCP 의 GKE, Pub/sub, CloudBuild 등 다양한 부분을 사용했고
* Third-party
  * swit, github, jira 와 oauth 연동을 통한 open api를 사용했다



## Page 4 [ERD](https://app.diagrams.net/#G1l1ulr8demZFOd6JRo40fUUSXvsogqb3-)

* Potato Schema (Main Schema) (User/OAuth_Token table)
  * User 테이블은 swit 한국 오피스 유저 정보를 가지는 테이블, oauth_token 테이블은 user 테이블에 연결
* Issue-tracking Schema (Issue, Branch, Commit, Pull_Request table)
  * Issue 테이블에 Branch, Commit, Pull_Request 테이블이 FK로 연결되어 있음
  * 각각 jira에서 보이는 것과 같
  * Issue 의 linkId 는 JIRA 의 IssueKey 와 동일한 형태(ex. BIS-123)이고 하나의 이슈가 하나만!



## Page ? Batch Process

* 한국시간(KST, asis northeast region 등)으로 9시에 한번 작업이 시작 됨
* UserTable 에 데이터를 넣기 위한 UserBatch 작업
    * 현재 Tech Ws 에 있는 사람을 기준으로 User 를 추가하거나 업뎃하고 있음
    * swit을 사용하는 많은 유저들 중에, swit직원들만 이용할 수 있도록 하기 위한 작업
* PR Table, Commit Table 에 unknown 으로 처리된 User 를 처리하기 위한 작업
    * Github OAuth 로그인을 하지 않은 유저를 식별할 수 없어 PR 이나 CM 에 `unknown:githubID` 형태로 저장하고 있다
    * 이를 parsing 하기 위해 배치를 



## Page 5 CI/CD

* swit-be CI/CD 구조를 많이 따랐지만, tag와 spinnaker를 사용하는 것이 아닌 branch push와 cloud build를 통한 deploy 작업까지 구성했다.
* 기본적으로 git flow를 따라서 작업을 진행했기 때문에, `develop` 브랜치에 작업을 붙이고, `develop` -> `release`로 pr & push가 일어날 경우 docker image build, push, gke deploy까지 자동으로 진행되도록 구성했음
* 설명을 덧붙이자면 `release` 브랜치에 대한 CloudBuild 트리거를 연결해 Docker Image Build & GCR push
* 이후 CloudBuild가 k8s yml 설정 파일을 통해 저장된 image를 gke로 deploy하는 방식임



## Page 6 Infra

* Pod, ReplicaSet(Deployment), Service, Ingress 전부 yml 로 설정해 놓았으며
* ingress는 static ip를 이용하여, 재 생성해도 같은 ip를 유지하도록 설정
* Client 는 Ingress 의 ip 로 접근하여 서비스를 이용
* Service 를 Node 타입으로 하여도 접근 가능하지만 ssl인증서 적용 및 http2https redirect 기능을 사용하기 위해서 ingress 가 필요함
* ssl인증서 역시, yml파일로 생성하여 사용중
* 현재 replicaSet 은 2개로 되어 있으며 하나의 Pod 에 API 서버와 RPC 서버가 함께 있는 구조


> env를 configmap을 이용해서 불편함을 해소한 경험을 넣는건 어떠신가요??

`Oliver 요청 사항 적용하여 이 부분은 최대한 자세하게 설명`



## Page 7 IssueTracking (Glimpse)

* 대충 이런 플로우라고 보여주고 Row 가 어떤 의미인지 설명
* Task Status 는 스윗 테스크의 status 와 정확히 동일
* Swit Incoming Webhook 은 현재 PR-Review 채널에 올라오는 Msg 로 생각
* Potato System DB 는 이전에 ERD 에서 보여준 테이블



## Page 8 IssueTracking (Detail)

* 클릭하나씩 해서 위에서부터 아래로 설명
  * Commit Create 는 PR Merge 이후에 나옴



## Page 9 Presentation

0. **Login**

    * Swit을 통한 로그인
    * Swit을 통한 로그인 이지만, Swit 내부 인력에 대해서만 로그인 가능하고, 자체 access token을 발급하여 세션관리 한다 

1. **Main 화면 설명 및 Issue-Tracker 확인**
    
    * nav bar > OAuth 연동 > Menu 들 설명
    * swit의 ws,proejct 및 task(issue)를 잘 가져오고 있다는걸 보여주면 좋을 것 같아요

2. **Issue Create** (발표자)

   * Issue 를 할 일(ToDo) 에서 생성한다.
   * Potato에서 생성된 이슈가 swit에도 잘 추가됐는지 확인


3. **LinkId Generate** (발표자)

   * Potato: `Potato 에서 만들기` 에서 LinkId 를 발급 받고 적용하기
   * Github: `Github 에서 가져오기` 에서 Repository > Branch 를 선택하여 LinkId 를 발급 받고 적용하기
     (LinkId 가 될 수 있는 형태의 Branch 가 하나 이상 존재한다고 가정)
   * Jira: `Jira 에서 가져오기` 에서 Issue Key 를 선택하여 LinkId 를 발급 받고 적용하기
     (나에게 할당되어있고 완료되지 않은 Jira issue 가 하나 이상 존재한다고 가정) << 이거 11번으로 빼는거 어떠세요 
     
   > 이미 link_id가 등록된 task는 link_id를 변경할 수 없다는것도 보여주면 좋을 것 같아요

4. **Branch Create**

   * Person 1: `feat/POT-XXX.v1`
   * Person 2: `feat/POT-XXX.v2`
   * presenter: 새로고침하여 Issue 에 Branch 적용된 것 확인

   

5. **Commit Create**

   * Person 1,2: 각각 하나 이상 commit 하여 push
   * presenter: 새로고침하여 Issue 에 Commit 적용된 것 확인

   

6. **PR Open**

   * Person 1: Reviewer 와 함께
   * Person 2: Reviewer 등록은 나중에
   * presenter: 
     * 새로고침하여 Issue 에 PullRequest 적용된 것 확인
     * Swit Channel 에서 Webhook 보여주고 해당 Chat 의 Thread 에 Reviewer 있는 것 보여주기

   

7. **PR Approve**

   * Person 1 이 올린 것을 Person 2 가 Approve
   * Presenter: Swit Channel 에서 Webhook 보여주고 해당 Chat 의 Thread 에 PR Owner 있는 것 보여주기

   

8. **PR Merge or PR Close**

   * Person 1: Merge
   * Presenter: 새로 고침하여 Issue 상태가 Doing 인 것을 확인
   * Person 2: Merge
   * Presenter: 새로 고침하여 Issue 상태가 Done 인 것을 확인하고 페이지의 Github 정보 확인하기

   

9. (Potato repo 를 사용한다면) Develop 에서 Release 로 PR 후 Merge

   

10. **Tag Create**

   * Person 1: Develop 또는 Release 에 Tag 를 생성함
   * Presenter: Swit Channel 에서 Webhook 보여주기


11. **Get Link ID From JIRA**
    * JIRA 를 보여주기 전에 Issue 가 중복으로 등록하는게 불가능 함을 보여주기
    * 현재 우리팀에서 어쩔수없이 jira를 쓰고있어 jira에서 BIS-111 을 갖고와서 연동하는 케이스를 추가로 보여주면 좋을 것 같아요 (올리버가 그렇게 말씀하셨습니다!)

    
---

PR Open 부터 Merge 까지 Branch 가 2개 이상일 경우 아래와 같이 두가지 경우가 있는데 모두 시연해야할지?

1. 따로따로 PR 이 처리되는 경우
   * Branch 1 PR Open > Branch 1 PR Merge > Branch 2 PR Open > Branch 2 PR Merge
   * 2번째 step 에서 Done 으로 처리 됨
   * 3번째 step 에서 Doing 처리 됨
   * 4번째 step 에서 Done 처리 됨
2. 같이 PR 이 올라오는 경우 (이 부분으로 설명하고 1번 케이스가 있다. 정도로) (다시 PR 열어 줘야 함)
   * Branch 1 PR Open > Branch 2 PR Open > Branch 1 PR Merge > Branch 2 PR Merge
   * 4번째 step 에서 Done 처리 됨

---



## Page 10 Plan

* 앞으로 여러가지 할 계획이 있지만 Cloud Build History 와 휴가 한번에 신청 가능하도록 하는 기능을 개발할 예정 `(Oliver 요청 사항)`
* 휴가 한 번에 신청이란 *전자결재 + 구글 캘린더 등록 + 휴가 채널에 업로드*를 의미 (이것까진 추가되면 좋을듯함)



## Page 11 End

* 처음에 BE 만을 위한 BackOffice 라고 소개했지만 Swit 전사적으로 사용하는게 목적이다.
  (잠시 키보드를 사용하여 1번 슬라이드로 이동 후 다시 11번 슬라이드로 이동)

  회사에서 스윗으로 커버되지 않는 비지니스가 모두 녹아 있는 그런 프로젝트가 되기를 희망한다 `(Oliver 요청 사항)`

* 긴 시간 발표 들어주셔서 감사합니다~


---

1. Issue 만들기

   * Potato 에서 ToDo 에서 새 업무를 생성한다
   * Swit 에서 Task 가 생성된 것을 보여준다
   * Potato 에서 Issue 상세 페이지로 들어간다.
   * Potato 에서 Issue 상세 페이지에서 Content, Checklist, Comment, Status, Priority 를 변경한다.
   * Swit 에서 Task 상세 페이지가 변한 것을 보여준다

2. Issue 연동하기 (Github 은 이미 연동되어 있음, Jira 는 연동 안한 상태)

   * Github 에서 가져오기에서 가져 올 수 있는걸 보여준다

   * Potato 에서 만들기에서 IssueKey 를 생성한다.

     > Issue Key 에 해당 하는 Branch 를 로컬에 만들고 Commit 하나 하고 대기

   * Integration 버튼을 누르기 전 이 번호가 어떻게 생성되는지 설명하고 Integration 하기

3. Branch 생성 및 PR 생성

   * Github 정보 상세페이지를 Branch, Commit, PullRequest 순서로 보여 줌

     > 발표자가 PullRequest 에 있을 때 미리 작업해 놓은 Commit 을 원격저장소로 Push
     >
     > 후에 PullRequest 요청 할 수 있도록 대기

   * 다시 Branch Tab 으로 돌아와 생성되어 있는 것을 보여줌, Commit 도 마찬가지

   * Swit 에서 상태가 Task 상태가 Doing 으로 가 있을 것을 보여 줌

     > Doing 으로 가 있는 것을 보여주고 이때 PullRequest 요청!
     >
     > (단테: Reviewer 초기에 추가, 데이지: PR 만 보내기, 단테부터 PR 요청 부탁드려요~)
     >
     > PR 이 끝났으면 Commit 몇개를 추가로 보냄 (msg 가 추가된 것 같은 msg 면 좋을 것 같습니다~) (7번 Commit Create 에서 보여줄 예정)

   * Swit Channel 에서 리뷰어가 처음부터 지정된 PR 부터 설명

   * Swit Channel 에서 리뷰어가 처음부터 지정되지 않은 PR 설명

     > 초기에 지정하지 않고 PR 발표자가 Thread 창을 클릭하면 리뷰어 추가해서 동적으로 보여줌

   * Potato 로 돌아와서 Github 상세 정보에 PR 이 두개 Open 되어있는거 보여주기

   * 데이지의 PR 을 선택해서 바로 접속할 수 있음을 보여주기

   * PR 에 아까 지정된 Reviewer 가 있는 것을 설명

     > 이 때 단테가 Approve 를 Submit!

4. PR Approve

   * Approve 가 된 것을 확인하고 Swit Channel 에서 데이지가 맨션되었음을 보여주기

5. PR Merge

   * Potato 로 돌아와서 

     >  데이지에게 PR Merge 요청드리면 Merge 부탁드려요~

   * Github 상세페이지에 Merge 된 것을 보여주고 Swit 에서 아직 상태가 Doing 인 것을 보여주기

   * Potato 로 돌아와서

     > 단테에게 PR Merge 요청드리면 Merge 부탁드려요~

   * Github 상세페이지에 Merge 된 것을 보여주고 Swit 에서 상태가 Done 으로 바뀐 것을 보여주기

6. Branch Delete

   * Branch 가 자동적으로 삭제되었기 때문에 Potato Github 상세 페이지에서 Branch Tab 보여주기

7. Commit Create

   * 그 동안 쌓인 Commit 들 다시 보여주기

8. Tag Create

   * 이렇게 개발이 끝나게 되고 배포할 때 Tag 를 생성한다고 말하는데

     > 이 때 미리 준비해놓은 Tag 를 단테(또는 데이지)가 생성 부탁드립니다~

   * Swit Channel 에 가서 Tag 관련 Hook 을 보여드리고 끝

9. JIRA 설명

   * issue 만들고 상세 페이지 들어가서
   * JIRA OAuth 연동하고
   * JIRA -1 만 있는 것 보여주고 


