☃️❄️개발일지, 트러블슈팅❄️☃️

[개발일지] TAVE 공식 홈페이지 개발 1. (개발, 백엔드, 브랜칭 전략, 커밋 컨벤션, 로깅 규칙, PR 템플릿)

대기업 가고 싶은 공돌이 2024. 10. 7. 00:34

TAVE 동아리 운영진을 하던 중 운영진끼리 공식 홈페이지 개발을 하기로 했다.

 

메인 페이지와 관리자 페이지 서류 모집, 채점 등등 모든 것을 홈페이지에서 처리하기로 해서 
살짝 규모가 큰 프로젝트가 될 거 같다.

 

여러 프로젝트를 해봤지만 앞으로 계속 운영할 사이트를 만드는 것은 처음이기 때문에
실제 운영 환경을 생각하며 꼼꼼히 프로젝트를 진행해야겠다.

 

백엔드 파트장 역할을 맡아 살짝 부담이 되긴 하지만 열심히 해봐야지 ,,

 

각종 컨벤션 및 브랜칭 전략

우선 본격적으로 개발에 들어가기 전에 각종 컨벤션과 브랜칭 전략을 먼저 정하기로 했다.

 

  1. 커밋 컨벤션
  2. PR 컨벤션 (템플릿)
  3. 로깅 규칙
  4. 브랜칭 전략

이렇게 네 가지를 먼저 정했다.

 

커밋 컨벤션

제목

  • 문장 보다는 구문
    • ex 기능 구현했습니다 → 기능 구현
  • 마지막 온점 사용 X → 제목에는 온점 안찍으니까
  • 첫글자는 대문자 (영어니까)

본문

  • 어떻게 보다는 변경한 내용(무엇을)과 이유(왜)를 자세하게 설명
    • 애초에 내 코드는 직관적이지 X → 실력 미숙
    • 리뷰를 잘 받기 위해 내가 작성한 코드 목적성을 확실히 설명해주기 위함

꼬리말

  • 여러 이슈 작성 시 쉼표로 구분
### 제목
# 커밋 타입: 작업내용 (제목과 본문은 한 줄 띄우기)


### 본문 (선택) - 한 줄에 최대 72 글자까지만 입력하기  
# 왜, 무엇을 했는 지?

### 꼬리말 (선택)
# 이슈 ID를 명시 (쉼표로 구분)

#   [커밋 타입]
#   feat      : 기능 추가
#   fix       : 버그, 오류 수정
#   refactor  : 코드 리팩토링 (코드 구조 변경)
#   comment   : 주석 추가 및 수정
#   
#   design    : CSS 등 사용자 UI 디자인 변경
#   style     : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
#   test      : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
#   docs      : 문서 (문서 추가, 수정, 삭제)
#   chore     : 기타 변경사항 (빌드 스크립트 수정 등)
#   rename    : 파일, 폴더명 -> 수정 및 이동
#   remove    : 파일 삭제
#   
#   [꼬리말 타입]
#   fixes: 이슈 수정 중 (아직 해결 X)
#   ref: 참고할 이슈
#   resolves: 이슈를 해결했 을 때 사용
# ------------------
# 예시
# Feat: 로그인 기능 추가
#
# 로그인 API 개발
# 
# resolves: #3, #5

 

다음과 같이 커밋 컨벤션을 정의했고

 

PR 컨벤션 (템플릿)

📌 PR 규칙

  • PR 올렸을 시 팀원들에게 바로 전달하기
  • 전원 PR 확인 후 리뷰나 댓글 남긴 후 merge 하기
  • 가능한 한 작은 변경 사항을 포함하는 PR을 만들어 팀원들이 빠르게 리뷰할 수 있도록 하기
    • ex) 게시물 CRUD 통째로 한번에 PR 올리는 것 지양
  • PR의 목적과 변경 사항을 명확히 설명하는 제목과 본문을 작성
    • "무엇을", "왜", "어떻게" 변경했는지 포함
  • 코드 스타일 일관성
  • 이슈 먼저 생성 후 해당 이슈에 맞게 PR 올리기
- 제목 : [#issue 번호] feat : 기능명
  ex) [#17] feat : pull request template 작성

### ➕ 연관된 이슈
> #이슈번호
> Close #이슈번호

### 📑 작업 내용
> 이번 PR에서 작업한 내용 간략히 설명해주세요(이미지 첨부 가능)

### ✂️ 스크린샷 (선택)
>

### 💭 리뷰 요구사항 (선택)
> 리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요

 

PR 규칙과 템플릿은 위와 같이 정하였다.

로깅 규칙

  • Error (심각한 문제 발생):
    • 예: 데이터베이스 연결이 끊겼을 때.
    logger.error("Database connection failed", exception);
  • Warn (예상 가능한 문제):
    • 예: 사용자가 만료된 쿠폰을 사용하려고 할 때.
    logger.warn("Attempt to use expired coupon, userId: {}", userId);
  • Info (운영 참고 사항):
    • 예: 새로운 사용자가 회원가입할 때.
    logger.info("New user registered: {}", username);
  • Debug (개발 단계):
    • 예: SQL 쿼리가 어떻게 생성되고 실행되는지 로그에 남길 때.
    logger.debug("Executing SQL query: {}", sqlQuery);
  • Trace (세부 추적):
    • 예: 함수 호출 스택을 모두 기록하고 싶을 때.
    logger.trace("Entering method: myMethod with params: {}", params);

우리는 개발 단계에서 debug 단계의 로그까지만 사용하고

운영 단계에서는 Info까지만 사용하기로 했다.

 

브랜칭 전략

브랜칭 전략은 깃허브 플로우 전략을 사용하기로 했다.

 

깃허브 플로우 전략이란 dev 브랜치를 따로 파지 않고 master 브랜치에 모든 하위 브랜치를 만드는 전략이다.

 

꾸준한 배포가 및 테스트가 필요한 프로젝트에 적합하다.

 

 

마스터 브랜치 - CI/CD 구축

feature 브랜치 - 기능 추가 브랜치

hotfix 브랜치 - 버그 수정 브랜치

 

브랜치는 위와 같이 3 종류만 사용하기로 했다.

 

이제 파일 구조와 테스트 단위만 정한 후에
본격적으로 작업에 들어가야겠다.