second - HJ-Rich/2022-MyRSS GitHub Wiki

release 브랜치를 생략한 Git Flow를 선택

• Git Flow, Github Flow 등의 선택지 중에 Git Flow를 선택
• 다만 release 브랜치와 이를 이용한 QA 과정은 develop 브랜치에서 수행함으로써 생략
  • Github Flow 등의 단일 브랜치만 운영하기에는 실제 운영 환경과 최대한 유사한 환경에서의 테스트 과정을 누락하기 어렵다고 판단.
  • 별도의 QA팀이 존재하지 않고, 애플리케이션이 이제 개발 시작 단계라면, Develop 브랜치에서 테스트 후 운영 배포해도 충분하다고 판단.
• 이슈 생성 -> develop 브랜치에서 feature/개발내용 브랜치 파생 -> develop으로 PR & 머지 -> main에 develop PR & 머지 프로세스로 진행.
  • MVP 1차 배포 전까지는 develop 브랜치에 직접 작업
• 🥄 Git Flow 한 스푼
• Git Flow 가 CI/CD 와 어울리지 않는 이유 by David Farley

/api 를 prefix로 갖는 Restful API 설계를 추구

• 모든 api는 /api/** 형식으로 /api를 prefix로 가지도록 설계
  • Web Server에서 프론트엔드, 백엔드를 분기하는데 location이 /api 일 경우 백엔드로 분기하도록 처리하는데 사용
  • 프론트와 백엔드가 Same-Origin에 존재할 수 있게 해주는 데 핵심적인 역할
• Restful API 를 가급적 준수하여 직관적이도록 설계
  • 조회 GET, 생성 POST, 수정 PATCH, 삭제 DELETE 메서드를 사용
    • POST 는 GET, PUT, DELETE 에 확실히 속하지 않는 요청에도 사용함
    • PUT 은 해당 자원이 없으면 생성 및 201응답, 있으면 대체 및 200응답하는 것이 규약. 따라서 수정은 PATCH 선택
• 예시 엔드포인트들
  • GET /api/feeds?page={page}&size={size} : 전체 피드 조회 및 페이징
  • POST /api/rss : JSON 형태의 body 값을 이용해 RSS 정보 등록
  • DELETE /api/rss/{rssId} : PathVariable로 전달된 RSS 식별자를 통해 RSS 정보 삭제

개발 서버와 운영 서버의 분리

• 개발, 운영 환경을 분리함
  • 개발 서버 : https://dev.myrss.ga
  • 운영 서버 : https://myrss.ga
• 개발 서버는 develop 브랜치, 운영 서버는 main 브랜치 기준으로 배포됨
• 따라서 개발 서버의 변경사항은 운영 환경에 영향을 미치지 않음
• 개발 서버는 적극적으로 배포 및 롤백을 수행하기에 부담이 없어서 선 적용 및 테스트 후 이슈가 없다면 main으로 머지하는 방식으로 사용

Github Webhook -> Jenkins Multibranch-pipeline -> 서버 배포

• Github -> Jenkins -> 서버 로 자동 배포되도록 구성
• Github에서 Jenkins로 연결은 Github의 Webhook 기능을 이용
• Jenkins에서는 리포지토리 내 변경사항을 감지해서 frontend/** backend/** 각 경로 이하 변경이 있을 경우에만 프론트, 백엔드를 각각 재배포
  • 또한 Jenkins에서는 develop, main 브랜치를 식별하여 develop일 경우 개발환경으로, main일 경우 운영환경으로 배포
• Jenkins는 빌드 결과를 서버로 전달한 뒤, 서버에 있는 쉘 스크립트를 실행하고 Slack으로 알림을 보냄으로써 본인의 Job을 종료
• 서버의 쉘 스크립트는 기존에 배포되어 있던 프로세스를 종료한 뒤, 새로운 빌드 파일로 프로세스를 백그라운드 실행함으로써 최종 배포 처리
• Jenkins, Multibranch-pipeline을 이용한 CD

필수 요구사항 전체 보기