개발 프로세스
브랜치 전략
monorepo 기준 두 줄기로 단순화했습니다.
| 브랜치 | 환경 | 비고 |
|---|---|---|
main | 운영 (zeroone.it.kr) | 머지 시 운영 배포 |
develop | QA/테스터 (test.zeroone.it.kr) | 머지 시 테스트 서버 배포 |
- 브랜치 이름은
<Jira 이슈 번호>/<작업 내용>(예:QNRR-127/member-api-documents). 한글 사용 지양.
커밋 컨벤션
포맷: <type>(<scope>): <subject> + 빈 줄 + body + footer.
- Subject는 70자 이내, 마침표 금지. 변경을 작게 나눠 자주 커밋.
- Body는 why 중심(명령형 현재 시제), footer에
Closes #123/Related to: #123. - 타입:
feat/fix/docs/style/refactor/chore(프론트는delete,test도 사용).
PR · 리뷰
- 기능 단위로 작업하고 제목만 봐도 내용을 알 수 있게 작성. 한 PR은 1000줄을 넘기지 않기.
- 최소 1명 이상 Approve 후 머지. Approve 이후 추가 커밋이 생기면 다시 Approve를 받습니다.
- 머지는 PR Assignee가 직접 (리뷰어가 머지 금지). 머지 후 브랜치 삭제.
- 머지 전 테스트를 돌려 전부 통과하는지 확인.
- HOTFIX는 예외적으로 리뷰 없이 머지 가능.
- 의존성 있는 후속 작업은 기존 PR을 base로 한 새 PR을 만들고, 올린 역순으로 머지.
PR 템플릿: 제목 <type>: <제목>, 본문은 # 개요 / # 설명(why 중심) / # 참고사항.
OpenAPI / API 동기화
- 프론트·백엔드 소통의 기준은 Swagger API 문서. 프론트는 문서를 보고 어떤 화면 기능인지 파악하고 Figma와 매핑합니다.
- 백엔드 API가 업데이트되면 FE 레포에
feature/openapi-new브랜치가 올라오고, 이를develop에 머지해 타입을 동기화합니다.
FE ↔ BE 소통
- 동일 도메인 담당자끼리 주로 소통하되 DM 대신 공개 채널(개발-백엔드/개발-프론트/“개발했어요”)에서 진행해 진행 상황을 공유합니다.
- 비휘발성 기록(Jira 이슈·문서)을 먼저 남기고 Slack으로 알립니다.
- 버그/에러는 Jira에 이슈(업무 유형 백엔드 등)로 남기고 담당자 지정 후 Slack 통지.
- Jira 이슈 제목 앞에
[담당자이름]을 붙여 담당자를 표시합니다.
테스트 자동화
백엔드에 BDD 기반 인수·API 테스트를 도입했습니다.
- Cucumber(인수) + Karate(API 시나리오) + Testcontainers(격리 DB).
- Gradle task 분리:
cucumberAcceptanceTest,karateApiTest,verifyAuthTraceability. - 추적성 검사:
product-ssot/<domain>/requirements.yaml의 요구사항(REQ-*)이 실제.feature와 태그로 연결됐는지 strict 검사 — 대응 시나리오가 없으면 CI FAIL. “문서에만 있고 테스트 없는” 요구사항을 차단합니다.
원문: