Development Guide

Development Guide

기본 작업 흐름

1. GitHub Issue를 생성하고 DU-{번호}를 확인합니다.
2. dev에서 작업 브랜치를 생성합니다.
3. 필요한 코드와 테스트만 수정합니다.
4. 로컬 검증 후 원격 브랜치에 Push합니다.
5. dev를 대상으로 Pull Request를 생성합니다.

브랜치 규칙

{type}/DU-{number}

사용 가능한 type은 다음과 같습니다.

feat, fix, refactor, chore, docs, test, hotfix, release

예시:

feat/DU-24
fix/DU-87
docs/DU-204

• 일반 작업 PR의 대상 브랜치는 dev입니다.
• main으로 보내는 PR은 dev 브랜치에서만 생성합니다.

커밋 규칙

{type}: 변경 내용

예시:

feat: 전시 검색 API 추가
fix: 라운지 게시글 조회 오류 수정
docs: README 디자인 개편
test: 전시 상세 조회 테스트 추가

커밋에는 하나의 목적만 담고, 관련 없는 파일을 함께 포함하지 않습니다.

필수 검증

./gradlew spotlessCheck
./gradlew test

전체 빌드까지 확인하려면 다음 명령을 사용합니다.

./gradlew clean build

CI는 dev, main에 대한 Push와 Pull Request에서 Java 21 기반으로 Spotless, Build, Test와 Flyway 파일 포함 여부를 확인합니다.

Profile

Profile	용도	Database
local	로컬 개발	MySQL 8.4
dev	배포 서버	MySQL
test	자동화 테스트	H2

• 공통 설정: src/main/resources/application.yaml
• 환경별 설정: application-local.yaml, application-dev.yaml
• 테스트 설정: src/test/resources/application-test.yaml

코드 작성 기준

• Controller는 HTTP 요청과 응답 조립을 담당합니다.
• Application Service는 유스케이스 흐름과 트랜잭션을 담당합니다.
• Domain은 비즈니스 규칙과 상태 변경을 담당합니다.
• Infrastructure는 JPA, 외부 API, 저장소 구현을 담당합니다.
• Entity 상태는 setter보다 의미가 드러나는 행위 메서드로 변경합니다.
• 신규 API 문서는 가능하면 presentation/docs 인터페이스에 작성합니다.

상세 규칙은 Code Convention을 따릅니다.

보안 주의사항

• .env, 인증 키, 운영 DB 정보는 커밋하지 않습니다.
• 운영 Secret은 GitHub Actions Secrets 또는 서버의 안전한 환경변수로 관리합니다.
• 로그와 Issue에도 Token, Password, Presigned URL 전체 값을 남기지 않습니다.