오늘 이야기 할 부분
머지하는 방식 정하기
- 작업이 완료 될 때마다 dev로 하위 브렌치를 바로 merge하기
- 동운
- 하위 티켓을 적당한 크기로 잘 나누면 되지 않을까 싶습니다.
- 상위 티켓 자체가 범위가 크기 때문에 이걸로 하게 되면 커밋도 많아질 뿐더러 서로 연계된 부분이 바로 적용된 상태에서 진행 하는게 더 좋지 않을까 싶습니다. (후자로 하게 된다면 커밋 수를 제한 하는게 좋을것 같네요.)
- 작업이 완료 될 때마다 하위 이슈의 상위 이슈 브렌치에 merge 한 다음 작업(하나의 스토리?)이 완료 되면 한번에 dev로 merge하기
- 병연님
- dev 브렌치에서 springboot가 현재 실행이 안되고 있습니당..
- 이점을 해결해야 할 것 같은데 .. 후자로 해도 다른 서비스가 필요한 곳에서는 어쩔 수 없지만 최대한 조취를 빨리취하면 dev 브렌치에 있는 것들도 실행 가능할 것 같아요
- 저의 선택은 후자입니다. 하위 이슈의 상위 브렌치에 merge한 다음에 한꺼번에 dev로 머지
- 진형
- 적당한 크기의 티켓 생성이 중요한듯합니다
- 너무 많은 커밋 및 내용이 또는 너무 적은 커밋 내용이 PR에 담기지 않도록 적당한 크기로 PR 날려야 한다고 생각합니다.
- develop에 merge를 하면서 실행이 안되는 부분이 너무 많아요 다른 파트를 담당하는 사람은 영문도 모른채 기다려야될 수 도 있습니다
- PR올리기전 테스트 코드를 꼭 전체적으로 실행시켜봅시다
- 실행 가능한 상태를 목표로 develop에 merge를 합시당
- 티켓 브랜치 사이의 PR은 필요없어보입니다. 티켓 → develop으로의 Merge만 PR을 날리고, 꼭 중요한 코드리뷰가 필요한 경우, 담당자가 섞인 티켓 등은 티켓-티켓 사이의 merge도 PR을 받도록 해도 좋아보입니다.
- 단, 상위 티켓에 너무 많은 하위 티켓들이 있어 상위티켓에 너무 많은 내용들이 들어가 PR이 거대해지는 것을 주의해야할 듯합니다.
- 커밋은 5개~10개 정도 코드량은 적당한 크기 등으로 하는 노력이 필요함다
회고도 해야합니다
목표 정하기 (스프린트 플래닝)
멘토님 말씀
- 네이티브 쿼리 아직 하지 말자.
- 엔티티가 중간중간 수정이 되고 있기 때문에 안정되면 하자 !
- 성능 생각은 나중에 생각하자.
- 진형님 시큐리티 테스트
- 일반적인 컨트롤러 테스트 코드를 작성하는 중 시큐리티 관련 모든 설정이 등록이 되지 않아서 실제 환경이랑 다르게 동작해서 401 에러가 발생했다.
- 시큐리티 설정을 주입시켜서 작성했다.
- 테스트코드에 시큐리티, 유저 관련해서 ignore 처리하는 기능이 있다.