세부 안건 논의CI Process(Bob)Git Branch 전략: Git-Flow✅LoggingMySQLDDL 문제테스트 데이터 입력Profile모니터링을 위한 핀포인트 구축(Pray 보고)Notion 문서 정리ERD 설계 / 논의
세부 안건 논의
CI Process(Bob)
Git Branch 전략: Git-Flow✅
- Main이 업데이트될 때마다 EC2로 새로 배포
- GithubFlow 사용할 경우
- feature 하나가 개발될 때마다 main에 반영되기 때문에
- 프론트가 빠르게 서버의 변경사항을 확인할 수 있음
- CI / CD의 의미에는 가장 맞기는 함
- 하지만, 너무 자주 CD 과정이 발생하는데, 이것이 의미있을지?
- 오히려 자잘한 문제들을 자주 해결하느라 생산성이 저하함
- 대안: Git-Flow ✅
- feature 완성되면 develop branch로 merge
- 사실 우리가 이전 하던 방식에서, merge 타겟이 main에서 develop으로 바뀌는 정도임
- 배포까지는 발생하지 않음
- 실제 운영 환경에서 제대로 동작하느냐는 문제가 있음
- 프론트의 느린 피드백이 아쉬움
- develop을 main으로 옮기는 것은 한 명의 책임으로 삼는 것이 좋아보임
- Bob이 담당하기로 ✅
- develop PR 전략을 세분화할 것인지?
- 너저분한 Merge 문제
- rebase
- 기록 중간에 끼어들어감
- squash
- 한 단위로 가장 앞에 넣어버림
- 이전 커밋들의 내용이 사라짐
- main에는 PR 이름만 들어가는 식
- develop에는 rebase하고, main에는 squash ✅
- 코드 리뷰
- 기본적으로는 개발자 3인(Partey, Didi, Kant)가 의무 진행
- 필요시 Bob, Pray가 참여
Logging
- 기록되는 로그는
ERROR레벨
logback설정
- AWS 내 Docker,
- 모니터링 툴?
- 일단은 애플리케이션 레벨에서 로깅(AOP)
- 어디까지 로그를 남길 것인가?
- 요청은 모두 로그 저장(Partey) ✅
- 어느 데이터를 저장할 것인지는 추후
- 어디에 로그를 남길 것인가?
- 파일 레벨이 나을 것 같음 ✅
- Docker안에서 Jar가 돌아가지만,
- EC2의 다른 Volume에 연결시켜 저장이 가능 ✅
- Docker에 의존하지 말자
- Profile에 따라 ✅
- test의 경우 터미널로만 확인
- prod의 경우
logback설정을 이용하여 파일로 저장함
- 로그 담당자(Didi) ✅
MySQL
- 설치하기
- 3306 포트 설정
- 로컬 Mysql 설정 참고
DDL 문제
- 일단은
create-drop을 사용
- 언제 직접 만들 것인가?
- 8월 4일에 전환 목표 ✅
validate
테스트 데이터 입력
@SQL애노테이션 이용하기: 특수 케이스용 ✅
- 공통 애노테이션도 사용 ✅
- 멘토님에게 조언도 구해보기
- 일단은 둘 다 try!
- RDB 스냅샷
- 테스트를 할 때마다 스냅샷을 되돌리면서 진행
Profile
- local과 test을 나누는 이유가 있을까? (Bob)
- 외부 의존성 구별의 문제(Pray)
- 하지만 현재는 DB를 동일하게 사용할 것이기에 굳이 분리가 필요할까?
- 현업의 경우 로컬과 테스트의 차이가 존재하지만, 우리는 굳이?
- 일단은 분리 없이 진행하다가 필요성이 느껴지면 적용하자(Pray) ✅
모니터링을 위한 핀포인트 구축(Pray 보고)
- 컨트롤러 서버 에이전트 서버 구축
- 현재는 컨트롤러 서버는 만들었음
- (요청을 보내는)에이전트 서버의 경우 신청이 필요해서, 아마존에 신청은 넣어둠(AWS 크레딧 심사중)
- 추가 신청을 해보자(Partey)
Notion 문서 정리
- 일단 백엔드 워크스페이스에 몰아 넣되, 중요 문서는 외부에도 공유