[브이디크럭스🦾] 214일

hotbreakb·2023년 7월 2일
1

회사생활

목록 보기
30/35

한 일

  • 6월 28일에 6월 2차 배포를 했다. 우리 회사는 2주 단위 배포를 하고 있다. 예를 들어 6월 28일이 정기 배포 날짜면 1주 전인 6월 21일은 스테이징 배포다. 이번에는 배포 리스트가 많아서 21일보다 조금 빠른 날짜로 지정되었다. 기존에는 실배포까지 1주일밖에 주어지지 않아서 급하게 작업하는 경우가 많았는데, 이번에는 2일 정도 텀이 생겨서 안정적인 배포를 할 수 있었다.
  • 실배포 직후에 데이터독에 버그가 찍혀서 잠수함 패치를 한 번 했다.
    • react-query를 쓸 때 enabled: true로 default 설정이 되어 있었는데, params가 없을 때도 API가 호출되어서 데이터독에 "파라미터 없는데 왜 불러!"라고 발생하는 에러였다. enbaled: Object.keys(params).length !== 0으로 변경하였다.
    • 이것을 알아채지 못했던 이유는 2가지다.
      • 항상 발생하는 현상이 아니었다. 페이지가 로딩되었을 때 useInitParams()로 URL에 필터값을 넣어줬는데, 이게 빨리 실행되면 버그가 나타나지 않았다. 실배포로 나갔을 때도 200으로 찍혀서 데이터독 에러로 나타나는지 몰랐다.
      • 스테이징 서버에 배포했을 때 데이터독을 확인하지 않았다.
    • 결론: 배포하기 전 네트워크창으로 API가 한 번만 호출되는지 확인하고 데이터독 에러를 확인해야 한다.
  • 이번 배포 때는 포스에서 취소된 내역을 확인할 수 있는 페이지, 테이블오더(태블릿)에 들어가는 광고 영상 넣는 페이지, 키오스크에서 알림톡을 보내는 조건 변경, 웨이팅 클라이언트 화면 크기 고정 작업을 했다.

하고 싶은 일

키오스크. 결제와 직접적인 관련이 있는 거라서 배우고 싶다. 내 마음을 몸소 보여주기 위해 어제 키오스크 코드를 확인해 보았다. 내일 아침부터 일렉트론 질문으로 팀장님을 괴롭혀야겠다.

  • 버전 확인
const remote = require("@electron/remote");
const appVersion = useMemo(() => remote.app.getVersion(), [remote]);
왜 아래처럼 쓰지 않는지 궁금.
const electron = require('electron');
const appVersion = electron.remote.app.getVersion();
  • 소켓 통신을 할 때는 node의 net 모듈을 사용한다. 결제할 때 소켓 통신을 한다.
const client = new net.Socket();
  • client.on은 이벤트 리스너 역할을 하는데, 소켓이 열려있으면 항상 듣고 있는 건지 궁금
client.on("data", function () {

해야 할 일

브이디 솔루션 페이지에 체험하기 서비스가 들어갈 예정이다. 말 그대로 우리 서비스를 체험할 수 있는 페이지가 들어가는 것이다. 프론트에서는 웨이팅과 키오스크가 들어간다. 내가 맡은 건 웨이팅.

체험하기 레포를 모노레포로 만들었다. 웨이팅 클라이언트, 웨이팅 어드민, 키오스크가 들어갈 것이다. 현재 옮겨둔 것은 웨이팅 2개.

🤓 신나는 모노레포 만들기 🤓

  1. git repository를 만든다.
  2. yarn init을 하면 package.json이 생긴다.
  3. 기존 레포에서 git remove -v로 리모트 주소를 확인한다.
  4. 새로운 레포에서 git remote add <리모트 이름> <리모트 주소>를 입력한다.
  5. git subtree로 기존 레포에 있던 코드를 끌고 온다.
  6. 복붙 끝

코드를 복사하는 것과 다른 점은 git 내역을 전부 끌고온다는 것이다.

레포는 만들어두어서 이번 주에는 웨이팅 클라이언트와 어드민을 연결하는 작업을 하면 된다.

논의중인 것

태그 배포 (git tag)

현재 모노레포에서 태그 배포를 하고 있다. 이렇게 되면 모노레포 안에 있는 레포를 골라서 배포할 수 있다. 이렇게 한 지 2달 정도 되었는데 문제가 발견되었다.

  1. 아무 커밋에서나 deploy가 될 수 있다. ➡️ 브랜치 전략이 명확하지 않고, 태그가 사라지면 언제 배포되었는지 빠르게 확인하기 어렵다. 누군가 "급하니까 병합 안 하고 빨리 배포 나가버릴래!" 하면 진짜 마음대로 배포 나갈 수 있다. 안정성이 떨어진다.
  2. 태그가 너무 많아서 관리가 어렵다. 어느 정도 기한이 지나면 지워야 하는데 모두가 그렇진 않다.
    • 나는 sourceTree에서 지웠는데 다른 사람이 feature 브랜치에 푸시 하자마자 그 사람이 갖고 있던 모든 태그가 다시 생겼다. ➡️ 나의 노력은 물거품이 되었다.
    • 귀찮은 일은 없애야 한다. 태그 배포 말고 브랜치 병합되었을 때 관련된 서비스만 배포가 되도록 바꾸고 싶다.

이와 관련되어 트렁크 기반 개발도 이야기를 해보았는데, 이걸 적용하려면 서버, QA팀과 말을 맞춰야 하고 테스크 코드가 아주 잘! 명확하게! 짜여있어야 하기 때문에 당장 적용하긴 어렵다는 결론을 내렸다.

브랜치 전략

우리는 feature 브랜치를 딸 때 master에서 딴다. 왜냐하면 기획한 순서대로 배포를 나가지 않기 때문이다. 심한 경우는 개발하고 n달 뒤에 나가는 경우도 있다. 그래서 feature를 따서 작업이 끝나면 develop에 병합해서 우리 팀 내부에서 테스트를 하고, 배포가 된다고 확정되면 staging에 병합해서 QA팀에 넘기고, 실배포 하는 날에 masterstaging을 병합한다.

문제: developstaging보다 너무 앞서가고 있는데 이걸 어떻게 맞춰야 하는가?
답: 안 맞추면 된다.

develop은 우리의 놀이터니까. 슬프게도 featuredevelop에 병합할 때 conflict이 많이 발생하는 경우가 있어서 이때 시간을 많이 쓰기도 한다. 그래서 나는 최대한 작게 작업하고 최대한 빨리 병합해서 conflict를 없애려고 한다. 파이팅.

회사 생활

브랜치 전략을 생각하니 머리가 지끈지끈하다. 이제 신나는 일을 적어봐야겠다.

  • 지난 금요일에 모바일팀 깜찍이 언니가 아침에 뿌까 머리로 묶어줬다. 누군가 "아침부터 소꿉놀이하네"라고 했다. 이후로 나는 대표님께도 뿌까뿌까로 불리게 되었다. 이사님과 대표님은 사진 찍어서 남겨놔도 되냐고 계속 놀리셨다.
  • 빨간 티를 입고 가면 나보고 화난 날이냐고 묻는다. 만약 그렇다면 나는 매일 빨간 티를 입어야 할 거다.
  • 지난 수요일에는 6월 생일파티를 했다. 다이어트하는 사람들 덕분에 피자가 많이 남아서 다음 날까지 피자를 먹었다. 나는 먹을 때 열심히 먹고 입은 나중에 닦는데, 옆에 언니가 나를 계속 바라보며 "계속 쳐다봐야 해. 뭘 자꾸 묻혀"라고 했다. 괜찮다고 했더니 아니라며 계속 내 입을 닦아주었다. 이게 바로 플러팅?
  • 다이어트 하는 언니들은 방울 토마토, 계란, 바나나만 먹는다.
  • 점심 시간에 누군가 가져온 수박과 체리를 열심히 먹었다. 여름 과일은 최고.
  • 토요일에 곱창 먹으러 간다고 방방 뛰던 언니가 이번 주에 소낭시에를 만들어오기로 했다. 쏘낭시에란 휘낭시에에 소시지를 올린 것이다. 내가 "왜 휘낭시에에 소시지를 올려?"라고 했더니 "먹으면 겁나 맛있음"이라고 하길래 재능 낭비하지 말고 당장 만들어오라고 했다.
  • 우리 회사에 오는 사람들은 다들 적응력이 굉장히 빠르다. 보통 일주일 정도면 금방 그 사람의 분위기가 나타나는 거 같다.

이제 신나게 물놀이 하러 갈 거다. 싸이 흠 뻑 쇼

profile
글쟁이 프론트 개발자, 헬렌입니다.

0개의 댓글