21 10 회고 - ChoDragon9/posts GitHub Wiki

스프린트

• 스프린트 플래닝 전에 User Story, Feature List를 나눠서 작업하는 것이 효율적임.
• 일정 산정 할 때 플래닝 포커를 활용
  • 이해 관계자가 합의한 일정임으로 정확도를 높일 수 있음.
• 스프린트 플래닝할 때 개발 일정 이외 일정 및 방법 논의 필요
  • QA 진행 일정 및 방법. 버그 해결 전 합의 과정을 어떻게 진행할지.
  • 스프린트 데모 진행 방법.
  • 스프린트 회고 진행 방법.
• 스프린트 회고는 대부분 조직이 KPT를 사용하고, 효율적이라고 생각함.
  • T 뒤에 항상 다음 액션 아이템 논의 필요.

lighthouse + k8s

• lighthouse는 성능 측정 리포트가 일정하게 나오지 않을 수 있음.
• lighthouse 오피셜 문서에서 리포트 오차를 줄이는 방안이 있음.
  • https://github.com/GoogleChrome/lighthouse/blob/master/docs/variability.md#strategies-for-dealing-with-variance
• k8s에서 구축할 때는 권장 사양을 지키는 것이 오차 범위를 줄일 수 있음
  • CPU 1.5, Memory: 1.5GB => CPU: 4, Memory: 6GB로 개선 시 가시적인 결과가 보였음.

Verdaccio + MySQL

• 패키지 메타데이터를 MySQL에 저장하는 케이스에서 외부 NPM 저장소는 MySQL에 저장하지 않는 것이 좋음
  • MySQL v5.7는 JSON에 최적화 되어 있지 않아 Disk 임계 초과 할 때 장애 발생 가능성 높기 때문.
• 외부 NPM 저장소의 패키지 메타데이터는 MB 단위임으로 MySQL의 로그가 분당 100~300MB로 찍힐 수 있음.
• lighthouse로 측정할 페이지 수가 100건 이상이면 argo cron으로 병렬 실행으로 전체 실행 시간을 낮출수 있음.