급할 때의 경로 | isdnetworks

급한 문제가 나서 서버에 올라간 파일을 직접 고쳤고 그것으로 상황은 넘어갔다. 그런데 다음 배포가 나가면서 그 수정이 통째로 사라졌고 같은 문제가 다시 났다.

Open Table of contents

서버에서 직접 고친 것

deploy.sh 는 git 저장소의 내용을 서버에 덮어쓰므로 서버에서만 고친 것은 남을 자리가 없다. git 에 안 들어간 수정은 다음 배포까지만 사는 셈이었다.

일단 같은 수정을 hotfix 브랜치로 git 에 넣어 정상 경로로 다시 내보냈다. 그러고 나서 왜 그때 서버에서 고쳤는지를 따져 봤다.

정해진 경로는 이랬다.

브랜치 만들기 → 고치기 → 검토 요청 → 승인 → 병합 → 배포

평소에는 30분이면 됐는데 새벽에는 검토할 사람이 없어 몇 시간이 걸린다.

경로를 안 지킨 것이 개인의 판단 문제가 아니라 경로가 그 상황을 다루지 못한 것이었다. 그러면 사람을 탓해도 다음에 또 같은 일이 난다.

그래서 급할 때용 경로를 따로 만들었다.

1. hotfix 브랜치를 만든다
2. 고친다
3. 검토 없이 배포한다 (승인 불필요)
4. 배포 뒤 24시간 안에 검토를 받는다
5. 검토에서 문제가 나오면 추가로 고친다

검토를 없애지 않고 뒤로 미룬 것이다.

$ git checkout -b hotfix/order-null-check master
$ git commit -am "주문 조회 시 null 처리"
$ ./deploy.sh hotfix/order-null-check

30분이 5분이 됐다.

hotfix 브랜치를 거치면 git 에는 항상 들어가므로 다음 deploy.sh 에서 사라지지 않는다. 검토가 아예 빠지는 것이 아니라 시점만 옮겨 가는 구조였다.

경로가 생긴 뒤에는 서버에서 직접 고치는 것을 실제로 막았다. 배포할 때 서버 파일과 git 저장소 사이에 diff 가 나면 배포를 멈추고 알리게 했다.

막지 않으면 급할 때 다시 서버로 손이 간다. 대안을 만드는 것과 옛 길을 막는 것이 같이 가야 경로가 바뀐다.

급하다는 것의 조건을 문서에 적었는데 서비스가 멈췄거나 자료가 잘못 쌓이고 있는 두 가지였다. 적어 두지 않으면 시간이 지나면서 전부 급한 것이 된다.

미룬 검토는 목록으로 관리해서 실제로 받았고 급한 배포가 몇 번 나갔는지도 셌다. 그 수가 늘면 평소에 못 잡는 것이 늘고 있다는 신호이므로 그 자체가 볼 값이었다.