1106

나에 대해 요새 느끼는 점

• 개발요청이나 장애대응은 빠르진 않지만 그럭저럭 잘 처리하는 것 같다
  • 좀 더 빠르게 처리하고 싶다
• 아직까지는 시키는 것만 잘하는 수준인 것 같다
• 직접 문제와 원인을 찾고 해결하는 방법을 당사자들과 모색하는 적극성은 없음
  • 이건 이미 이 역할을 하는 분들이 계시기 때문에 필요성을 느끼지 못하는게 아닐까?(합리화 아님)
  • 아직 1년도 안채웠는데 너무 급하게 생각하는게 아닐까...
  • 진취적인 모습을 원하는 욕심과 지금도 충분히 잘하고 있다는 합리화 사이에서 불편하게 표류 중인 느낌
  • 오더통합관리 프로젝트도 나에게 부여된 프로젝트 안에서는 최선을 다했지만 결국 내가 원하는건 그 프로젝트를 직접 발굴할 수 있는 능력인 것 같다
  • 비즈니스 환경의 회사가 아닌 사이드 프로젝트에서는 여포 행세를 하고 다니는거보면 비즈니스 환경에서의 적응이 더 필요한게 아닐까..

회사 리포지터리 브랜치 전략에 관한 고찰

• 서버 구분에 맞게 분리돼있음(dev-staging-main)
• 최신 main에서 브랜치를 따와 작업하고, dev, staging 그리고 main에 PR을 올려 각각 병합함
• dev와 staging 그리고 main은 서로 독립적인 브랜치로 계단처럼 연결된 브랜치가 아니게 설계돼있음
• 문제는 작업 브랜치에서 작업을 완료하고 각 서버 브랜치로 병합할 때임
  • 작업 순서와 긴급함의 차이에 따라 main으로 먼저 병합되는 브랜치도 있고 어쨌든 staging과 main의 싱크가 안맞게 됨(이유를 잘 모르겠음)
  • 싱크가 안맞는 상태에서 main 기준 브랜치를 staging에 병합하려하면 충돌이 발생하거나 staging에만 있는 커밋들이 작업 브랜치 PR에 막 끼게 됨
  • 우선은 main은 확실한 기능들만 나가야하니 staging 브랜치의 커밋들을 가져다 main에다 들이부으면 안됨
  • 그래서 일단 작업 브랜치를 base로 브랜치 하나를 더 복사해서 staging을 pull받아 충돌을 해결하고 staging용 브랜치를 만들어 staging push는 이 브랜치로 따로 진행하기로 함
    • 만약 추가 커밋이 생기게 되면 작업 브랜치와 스테이징용 작업 브랜치에 두 번 반영해줘야하는 불편함이 생김