Skip to content

Releases: boostcampwm-2024/refactor-web39-OctoDocs

v1.1.0

17 Jan 07:07
c606baf
Compare
Choose a tag to compare

Improvements

lighthouse 수치 개선

  • Performance (90->99)
  • Accesssibility (83→100)
    • aria-label 추가
      • <button> 태그에 접근 가능한 이름을 부여하여 스크린 리더 사용자 경험 개선
    • 이미지 alt 속성 추가
      • <img> 요소에 대체 텍스트를 제공하여 이미지 설명 강화
    • 텍스트 대비율 개선
      • 포그라운드와 백그라운드 색상 대비율을 조정하여 가독성 향상
  • SEO(75→100)
    • 메타 설명 추가
      • <meta name="description"> 요소를 추가하여 검색 결과에서 페이지 요약 제공
    • 유효한 robots.txt 파일 작성
      • 검색 엔진 크롤러의 접근 제어를 위해 유효한 robots.txt 파일 구성
  개선전 개선후
Performance 90 99
Accessibility 83 100
SEO 75 100
FCP 1.1s 0.6s
LCP 1.3s 0.8s
total blocking time 160ms 30ms
speed index 1.2s 0.8s

docker image 용량 축소

  • yarn 호이스팅을 통해 중복 node 패키지 최소화
  • node 패키지만 가지고 있는 이미지를 base로 api 서버 이미지와 websocket 서버 이미지 생성하여 패키지 공유
  • 멀티 스테이지 빌드 적용하여 상용 서버에 필요한 파일만 빌드
  • docker image 용량 44% 감소 (4.5GB → 2.5GB)

docker 배포 환경 변경

  • 패키지 docker volume 제거
  • 리액트 정적 파일 bind mount 제거
  • 패키지 설치 및 정적 파일 삽입을 이미지 빌드 시점에 진행

redis 낙관적 락 적용

  • red lock 알고리즘을 제거, 단일 인스턴스 redis 분산 락 적용
    • redis에 있는 리소스를 데이터베이스인 postgres로 migrate하는 과정에서 해당 key에 접근을 막는 red lock 알고리즘을 사용하였으나, 단일 redis instance를 사용해서 오버 엔지니어링이라고 판단
    • redis의 자체 기능을 사용하여 분산 락을 구현
  • redis 분산 락 제거, watch 사용 낙관적 락 적용
    • migrate 과정에서 redis의 key에 대한 충돌이 생각보다 적어 현재의 비관적 락은 비효율적이라는 결론을 내림
    • 현재 migrate 과정에 있는 key를 redis의 watch 기능을 사용하여 감시, 해당 key에 대한 접근이 충돌이 생겼을 때만 막는 낙관적 락 사용하게 변경

자동 배포 구현

  • 로컬에서 이미지 빌드 후 docker hub에 업로드
  • 원격 서버에서 이미지 가져와서 docker-compose로 container 실행

Bug Fixes

docker container에 추가된 패키지 반영되지 않는 이슈 해결

  • 이전 패키지를 저장하고 있는 docker volume이 그대로 연결된 이슈
  • 이미지 빌드 시점에 패키지 설치하는 방식으로 해결

What's Changed

New Contributors

Full Changelog: v1.0.0...v1.1.0

v1.0.0

17 Jan 04:46
15781ae
Compare
Choose a tag to compare

Release Notes Template

Based off https://palantir.quip.com/pzRwAVr1bpzf

Pro-tip: look through the github diff between the previous release to see what's changed. The commit titles should give an outline of what's happened.

Upgrade Steps

  • List out, as concretely as possible, any steps users have to take when they upgrade beyond just dumping the dependency.
  • Write pseudocode that highlights what code should change and how.
  • Call out if users are recommended to upgrade because of known problems with older releases.
  • Preferably, there's nothing here.

Breaking Changes

  • A complete list of breaking changes (preferably there are none, unless this is a major version).

New Features

  • Describe the new feature and when/why to use it. Add some pictures! Call out any caveats/warnings? Is it a beta feature?

Bug Fixes

  • Call out any existing feature/functionality that now works as intended or expected.

Improvements

  • Improvements/enhancements to a workflow, performance, logging, error messaging, or user experience

Other Changes

  • Other miscellaneous changes that don't fit into any of the above categories. Try to leave this empty - ideally, all changes fit into the categories above

Copy and paste this template

## [0.0.2](https://github.com/andreasonny83/twilio-remote-cli/compare/v0.0.1...v0.0.2) (2019-07-21)

> Description

### Upgrade Steps
* [ACTION REQUIRED]
* 

### Breaking Changes
* 
* 

### New Features
* 
* 

### Bug Fixes
* 
* 

### Performance Improvements
* 
* 

### Other Changes
* 
* 

Example:

## [0.5.2](https://github.com/andreasonny83/twilio-remote-cli/compare/v0.5.1...v0.5.2) (2019-07-21)

### Performance Improvements

* **dependencies:** Bump dependencies  4a4ee13

### Other Changes

* **chore(conventionalChangelog):** Add Conventional Changelog  aafcdd9
* **docs(CHANGELOG):** Add changelog  e2c7435