Skip to content

(~ing) Yarn Berry 기반 모노레포 프로젝트. 사용자/판매자/관리자용 웹 통합 주문 관리 시스템

Notifications You must be signed in to change notification settings

ServicePlayground/sweet-order

Repository files navigation

Sweet Order

Yarn Berry + Workspace 기반 모노레포 프로젝트로 구성된 디저트 주문 플랫폼입니다.

🚀 시작하기

필수 요구사항

  • Node.js (v20 이상)
  • Yarn (v4.9.4 이상)

로컬 개발 환경변수 설정

  • backend/.env.development 삽입
  • web-seller/.env.development 삽입
  • web-user/.env.development 삽입

로컬 개발 환경 데이터베이스 설정

로컬 개발 환경 설치 및 실행

# 프로젝트 클론
git clone <repository-url>
cd sweet-order

# 의존성 설치(자동으로 postinstall 스크립트 실행, 이름 변경시 자동실행 안됨)
# 파일 경로에 한글이 존재하면 오류가 발생할 수 있습니다.
yarn install

# 개발 서버 시작(.env.development 환경변수 필요)
yarn backend:dev          # 백엔드 개발 서버 (포트: 3000)
yarn web-user:dev         # 사용자 웹 개발 서버 (포트: 3001)
yarn web-seller:dev       # 판매자 웹 개발 서버 (포트: 3002)

# 데이터베이스 관리
yarn db:migrate:dev         # 백엔드 개발 데이터베이스 마이그레이션
yarn db:studio:dev         # 백엔드 개발 데이터베이스 스튜디오
yarn db:seed:dev         # 백엔드 개발 데이터베이스 시드
yarn db:reset:dev         # 백엔드 개발 데이터베이스 리셋

# 빌드 및 배포
yarn backend:build:staging     # 백엔드 스테이징 빌드
yarn backend:build:production  # 백엔드 프로덕션 빌드
yarn web-user:build            # 사용자 웹 빌드
yarn web-seller:build            # 판매자 웹 빌드

# 코드 품질 검사
yarn common:lint              # ESLint 검사
yarn common:lint:fix          # ESLint 자동 수정
yarn common:format            # Prettier 포맷팅
yarn common:format:check       # Prettier 포맷팅 검사

🚀 배포 방법

태그 기반 CI/CD 구성

프로젝트는 GitHub Actions를 통한 태그 기반 자동 배포 시스템을 사용합니다.

태그 형식

각 프로젝트별 태그 형식은 다음과 같습니다:

프로젝트 태그 형식 배포 플랫폼 예시
backend backend/staging-* AWS App Runner backend/staging-v1.0.0
web-user web-user/staging-* Vercel web-user/staging-v1.0.0
web-seller web-seller/staging-* Vercel web-seller/staging-v1.0.0

태그 구조: {프로젝트명}/{환경}-{버전}

  • 프로젝트명: backend, web-user, web-seller
  • 환경: staging (현재 지원)
  • 버전: 자유 형식 (예: v1.0.0, v1.0.1, 2024.01.01)

배포 프로세스

  1. 태그 생성 및 푸시
  2. GitHub Actions 워크플로우 자동 실행
  3. 프로젝트별 배포 플랫폼으로 자동 배포

자세한 배포 설정 및 가이드는 다음 문서를 참고하세요:

👥 협업 규칙

이 문서는 Sweet Order 프로젝트의 협업 규칙을 정의합니다. 모든 팀원은 이 규칙을 준수해야 합니다.

🌿 브랜치 전략

기본 원칙

  1. main 브랜치 보호

    • main 브랜치로 직접 push는 금지됩니다.
    • GitHub의 브랜치 보호 규칙이 설정되어 있습니다.
    • main 브랜치로의 변경은 반드시 staging 브랜치를 거쳐야 합니다.
  2. staging 브랜치

    • 개발 및 테스트를 위한 통합 브랜치입니다.
    • 모든 기능 개발은 staging 브랜치로 병합됩니다.
  3. hotfix 처리

    • 긴급한 버그 수정이 필요한 경우, hotfix 브랜치에서 작업 후 staging 브랜치로 직접 push 가능합니다.
    • 프로덕션 환경에 즉시 반영이 필요한 경우에만 사용합니다.
  4. 일반 기능 개발

    • 모든 기능 개발은 기능별 브랜치를 생성하여 진행합니다.
    • 작업 완료 후 staging 브랜치로 **Pull Request(PR)**를 생성합니다.
    • PR 승인 후 병합됩니다.

브랜치 워크플로우

main (보호됨)
  ↑
staging (통합 브랜치)
  ↑
feature/xxx (기능 브랜치)
hotfix/xxx (긴급 수정 브랜치)

📝 브랜치 네이밍 규칙

브랜치 이름은 기능의 목적을 명확히 표현해야 합니다.

브랜치 네이밍 형식

{타입}/{기능-설명}

브랜치 타입

  • feature/: 새로운 기능 개발
  • hotfix/: 긴급 버그 수정
  • fix/: 일반 버그 수정
  • refactor/: 코드 리팩토링
  • docs/: 문서 수정
  • chore/: 빌드, 설정 등 기타 작업

🔄 Pull Request 규칙

PR 생성 전 체크리스트

  • 브랜치가 최신 staging 브랜치를 기반으로 생성되었는지 확인
  • 코드가 정상적으로 작동하는지 확인
  • yarn run common:lint 명령어를 통과했는지 확인
  • yarn run common:format:check 명령어를 통과했는지 확인

💬 커밋 메시지 규칙

프로젝트 타입

  • [COMMON] - Common
  • [WEB-SELLER] - Web Seller
  • [WEB-USER] - Web User
  • [BE] - Backend

커밋 타입

  • [TASK] - 일반 작업
  • [BUG] - 버그 수정
  • [FEATURE] - 새로운 기능 추가
  • [CHORE] - 빌드, 설정 등 기타 작업
  • [DOCS] - 문서 작성/수정
  • [FIX] - 버그 수정
  • [REFACTOR] - 코드 리팩토링
  • [REMOVE] - 코드 삭제
  • [UI] - UI 변경
  • [QUESTION] - 질문/의견

커밋 메시지 예시

[COMMON][CHORE]: 의존성 패키지 업데이트
[WEB-SELLER][UI]: 상품 등록 폼 UI 개선
[WEB-USER][FEATURE]: 로그인 페이지 구현
[BE][FIX]: 인증 토큰 만료 처리 수정

📚 상세 문서

공통 문서

구조 관련

기능 관련

플로우 차트 관련

취약점 관련

백엔드 문서

프론트엔드 문서

인프라 문서

About

(~ing) Yarn Berry 기반 모노레포 프로젝트. 사용자/판매자/관리자용 웹 통합 주문 관리 시스템

Resources

Stars

Watchers

Forks

Packages

No packages published

Contributors 3

  •  
  •  
  •  

Languages