서론
레벨 4가 끝났습니다! 거짓말..
누가 타임머신 개발했나요? 시간이 너무 빨리가네요 🥺
피움 🌱
우당탕탕 최종 데모데이를 마무리한 피움팀... 정말 고생 많았습니다
Connection Pool 설정
개발서버에 약 10만개의 식물 데이터를 넣고 검색 쿼리를 기준으로 jmeter 테스트 결과를 확인헀습니다.
공식에 따르면 약 4~5개정도의 Connection Pool의 개수가 최적이라고 했지만 실제로 눈으로 보기 전까지는 모르는법이기에 다양한 값으로 테스트를 진행했습니다.
여러 테스트 결과 피움팀은 Connection Pool 개수를 4개로 결정했습니다!
자세한 내용은 팀 블로그 - HikariCp Connection Pool 값 설정을 확인해주세요~
무중단 배포
무중단 배포도 무사히 적용된 것을 확인하고 팀 블로그에 과정을 정리했습니다~
자세한 내용은 팀 블로그 - 무중단 배포 환경 구성하기를 확인해주세요~!
최종 데모데이
데모데이의 법칙
간혹 다른 팀들의 이야기를 들어보면 데모데이 전날에는 항상 오류가 터진다는 말을 들었습니다.
설마 우리팀도 그러겠어~ 싶었는데 아니나다를까 최종데모데이 전날에 이슈가 팡팡팡~
최종 데모데이 전날에 세션클러스터링 (정확히는 세션을 DB에 저장)이 잘 적용되지 않아서 11시까지 트러블슈팅을 했답니다!
세션 조회, 쿠키 값 설정, 쿠키 조회(파싱), 로그인 서비스 등등.. 여기저기서 예측못한 예외가 팡팡 터져서 팀원들 다같이 고생좀 했습니다 😅
다행히 11시 땡 하고 해결했습니다~
문제를 해결하면서 팀원들 다같이 저녁에 먹은 피자~ 맛있었습니다 🤤
아직 한발 남았다...
집에 가면서 개발서버 QA를 해보려고 핸드폰으로 피움 개발서버를 딱 켰는데...
하얀 화면만 나오고 브라우저 랜더링이 안되지뭡니까~ 하핫..
모바일에서 API 호출을 하기도 전에 오류가 나더라구요.. 아마 프론트엔드의 ios 호환문제이지 않을까 의심하면서 집에 도착하자마자 디버깅을 와르르르르~ 해봤습니다.
아닌 밤중에 프론트엔드 오류 공유 죄송합니다.. 😅
그치만 내일이 최종데모인걸요..ㅠㅠ
잘은 모르겠지만 아무래도 브라우저 랜더링 이전에 파이어베이스 설정값을 불러오지 못해 맛이 가버린 그런 상황으로 유추되었습니다!
해결해주신 클린 감사합니다 👍
😆 진짜 최종 데모데이
와~ 레벨 4를 마무리하는 최종 데모데이날입니다!
🌱 피움 부스운영
짜잔~ 백엔드 어드민 페이지 감성으로 피움 안내 표지를 만들었습니다~ㅋㅋㅋㅋㅋ
부스 체험하러 오셨던 많은 사람들~ 감사합니다~!
main 브랜치 라이브 머지쇼도 진행했습니다 ㅋㅋㅋㅋㅋㅋ 😆
무중단배포 잘 되는거 보니 뿌듯하네요 👍
점심에 맛있는 고기도 먹었습니다~ 🥩
⚡️ 라이트닝 토크
예전에 라이트닝 토크 연사 모집하길래 1등으로 바로 신청해버렸습니다~!
OpenAPI Spec으로 CodeGenerator를 활용하는 방법을 공유하고싶어서 신청했습니다 😆
그레이가 찍어준 사진 찰칵~
5분 발표였는데 너무 열정적으로 말하다보니 8분 넘게 발표해버렸네요 😅
그래도 무사히 발표 완료했습니다~
발표 내용이 궁금하다면 아래 글을 봐주세요~
블로그 - OpenAPI CodeGenerator 활용하기
🚀 미션
레거시 코드 리팩터링 미션... 무수히 많은 Setter를 제거하고 모조리 Builder 형태로 바꿔줬습니다.
그리고 Application Layer를 들락날락하는 Domain들을 DTO로 바꿔줬습니다.
어려워서 힘든게 아니라 대단히 많은 노가다로 머리가 아픈 그런 미션이였습니다 ㅠㅜ
무수히 많은 File changes.. 히이로 리뷰 감사합니다...🙇♂️
리뷰이 망고도 이거 갈아엎느라 고생하셨습니ㄷr.. 🥹
이 과정에서 무수히 많은 Mock Test들을 다 수정해줘야하니 관리요소가 오히려 많아졌습니다.. 3단계에서는 통합테스트로 바꿔야겠어요
💻 근로
회고
1차 스프린트를 마치고 캠퍼스플랫폼 팀의 회고를 진행했습니다!
미션, 프로젝트, 기타(테코톡 등) 예상외의 일정으로 인해 목표했던 일을 모두 완수하지 못했습니다 😅
이번 스프린트는 구현에 대한 시작을 하지 못하고 기획에 대한 협의만 이뤄졌습니다. 무엇이 문제였고 무엇을 지속해야할지 회고를 통해 돌아보는 시간을 가졌습니다
일정 추산을 명확히 한다는게 참 어렵네요 🥺
열심히 고기를 썰고있는 캠퍼스 플랫폼 팀의 모습입니다 🥩
회고를 마치고 제이슨이 사주신 맛있는 점심을 사주셨습니다~! 🤤
사진보니까 또 배고파지네요
찜꽁 마이그레이션
찜꽁 프로젝트를 어떻게 마이그레이션 할 것인가? 에 대한 이야기를 진행했습니다.
현재 찜꽁은 요구사항이 변경됨에 따라 새로운 DB 스키마를 생성해야하는 상황입니다.
여기 세가지 선택사항이 있습니다.
- Lagacy DB, New DB 양측을 모두 바라보면서 마이그레이션을 진행한다.
- Lagacy DB를 기준으로 엔티티를 설계하면서 마이그레이션을 진행한다.
- New DB를 기준으로 엔티티를 설계하면서 새롭게 개발한다.
만약 2개의 DB를 모두 바라보게한다면 다음과 같은 방식을 사용할 수도 있습니다.
- 새 DB를 만든다.
- transactionManager를 레거시용 transactionManager와 신규 transactionManager를 만든다.
- 마이그레이션할 엔티티를 선정한다. (e.g. Map)
- 신규 transactionManager를 사용하는 서비스를 만든다. (e.g. MapService)
- 신규 transactionManager를 사용하는 서비스에서 레거시 transactionManager를 사용하는 서비스를 호출한다.
하지만 새로운 요구사항은 로그인이 없는 상황이고 양방향 insert를 수행하기에는 여러 문제상황이 있었습니다.
- DB 스키마의 구조가 너무 달라 양방향 insert시 기존 DB의 데이터 정합성을 보장할 수가 없다. (FK 제약조건을 모두 제거해야한다.)
- 추후 공지&출결에서 사용하는 로그인 구조를 신규 찜꽁에도 같이 붙인다는 확장성 측면에서 로그인을 섣불리 도입하기 어렵습니다.
- 6기 인원에게 인수인계를 원활히 진행해야합니다.
- 제한된 시간 내로 개발을 진행해야합니다.
위와 같은 내용들을 생각해 봤을 때 New DB를 기준으로 엔티티를 설계하면서 새롭게 개발한다.라는 방식이 적합하다고 판단했습니다.
정리
레벨 4 최종 데모데이를 무사히 마쳤습니다. 👍
많은 일들이 우당탕탕 지나간 만큼 기록도 소중하게 해놔야겠습니다...
다들 프로젝트 고생하셨습니다~!! 👏👏👏
