24.03.17~24.03.24

업무

신규 기능 배포

지난주 개발했던 신규 기능을 production에 배포했다.

 

수요일에 B사를 방문해 해당 버전을 시연하기로 했어서

월-화 동안 staging 환경에서 테스트 + 버그 수정을 반복해야만 했다.

 

개발 당시 다른 사내 서비스에서 테스트할 때는 별 문제가 없었는데

막상 staging 환경에서 고객사인 B사의 서비스로 테스트를 해보니

정상적으로 서비스 진행이 되지 않는, 버그성 동작들이 발견되었다.

 

타들어가는 속을 삼키며 황급히 원인을 파악했고

페이지 이동이 아닌, nav tab 간 이동이 발생하면서 

1) 각 target 요소들을 정확히 조회하지 못하거나 2) 제어 중인 요소가 사라졌다 다시 생성되는 경우 가 있음을 발견했다.

 

trigger 관련 알고리즘을 수정하고, event binding 판단 여부 로직을 개선해 해결할 수 있었고

결론적으로 기간 안에 마무리를 해, 미팅도 성공적으로 종료될 수 있었다.

 

개발 프로세스 대응 기능 개발

역시 B사의 요구 사항 중 하나였던, 개발 프로세스 대응 기능을 개발했다.

 

B사 테스트를 통해 나온 요소 조회 알고리즘 개선 사항을 다른 FE 팀원이 맡게 되어서,

해당 기능은 admin부터 script, extension까지 모두 내가 담당하게 되었다.

실제 개발은 이틀 정도..?

사실 이전부터 설계해둔 기능이기도 했고

더도 말고 덜도 말고 B사의 요구 사항을 충족시킬 정도로만 개발해 보자!라는 내부 합의도 있었다.

그래서 그리 오래 걸리지 않을 것이라 예상했는데, 실제로도 그래서 뿌듯했달까.

(물론 월요일에 staging 테스트를 마쳐야 진짜 개발 종료. 하하!)

 

사내 package 배포 자동화

개발 프로세스 대응 기능이 금요일 쯤 마무리가 되어 반나절 정도 시간이 남았었는데,

그때 (피치 못해 미뤄뒀던) 사내 package 배포 자동화 작업을 진행했다.

늘 짜릿한 자동화

이전에는 개발 사항 병합이 이뤄지면

개발자가 직접 local에서 build와 publish를 진행해 각 package들을 업데이트했었다.

 

하지만 이로 인해

1. PR병합과 별개로 build가 이뤄지다 보니 해당 개발자 local 환경에 따라 build 결과물이 달라지는 문제
2. 직접 publish 명령어를 실행하는 문제
3. 배포 후 slack 등을 통해 직접 알림 하는 문제
4. staging, main 환경에 따른 버전 별도 공지가 필요한 문제 가 발생했다.

 

따라서 git action을 통해 해당 과정을 자동화하고자 했고

1. 배포 branch (main, staging 등)에 pull request 머지 시 workflow 동작
2. pull request의 title, body 조회
3. version이 명시되어 있을 경우, 버전 변경 후 빌드 및 package 업데이트
4. 자동 release
5. slack 알림을 통한 package 업데이트 알림 (필요 서비스 설치 유도)

과 같은 흐름으로 PR -> build -> publish -> release -> slack notice 까지 자동으로 완료되게 만들었다.