맡은 프로젝트가 넷이었는데 배포 방식이 전부 달라서 옮길 때마다 배포 방법을 다시 확인해야 했다. 그중 하나는 손으로 파일을 올리는 방식이라 무엇을 올렸는지 기록조차 없었다.
Table of contents
Open Table of contents
넷의 차이
무엇이 다른지를 표로 만들어 여섯 항목을 나란히 놓았다. 방식과 되돌리기 가능 여부와 기록 유무와 배포 뒤 확인과 설정 분리와 소요 시간이다.
여섯 항목이 프로젝트마다 갈렸는데 그중 되돌리기와 기록이 없는 것이 가장 위험했다. 손으로 올리는 프로젝트는 그 둘이 다 없어서 사고가 나면 무엇을 되돌려야 하는지조차 알 수 없는 상태였다.
방식이 아니라 조건
가장 나은 방식 하나를 골라 통일하는 대신 만족해야 할 조건을 정했다. 되돌릴 수 있고 무엇을 배포했는지 기록에 남으며 배포 뒤 확인이 자동으로 되고 설정이 코드와 분리돼 있는 넷이다.
방식을 통일하는 것이 아니라 조건을 통일한 것인데 프로젝트 사정이 달라서 방식까지 같게 만들기는 어려웠기 때문이다. 넷을 만족하면 방식은 달라도 상관없게 뒀다.
위험한 것부터
조건을 하나도 못 채우던 프로젝트부터 손댔다. 손으로 올리던 것을 없애고 리비전별 폴더와 링크 교체 방식으로 바꾸면서 배포 기록과 배포 뒤 확인까지 스크립트에 넣었다.
ssh "$HOST" "cd /app && tar xzf releases/release-$rev.tgz -C releases/$rev && ln -sfn releases/$rev current"
echo "$rev $(date -Is)" >> deploy.log
curl -sf "https://$HOST/health" | grep -q "$rev" || { echo "확인 실패"; exit 1; }네 조건을 다 채우면서 소요 시간도 10분에서 3분으로 줄었다. 나머지도 조건을 못 채운 개수 순으로 정리했고 전부 하는 데 3주가 걸렸는데 하나씩 했으므로 그 사이에 다른 일도 병행했다.
공통 흐름과 덮어쓰기
조건을 채우고 나니 각 스크립트가 자연히 비슷해져서 공통 흐름으로 묶을 수 있었다. 빌드와 업로드와 전환과 확인과 기록을 공통 함수로 두고 프로젝트별로는 설정만 달리했다.
방식이 정말 다른 프로젝트는 해당 함수만 설정 파일에서 덮어쓰게 했다. 컨테이너 이미지를 쓰는 쪽은 빌드 함수만 바꾸면 나머지 흐름은 그대로 탄다.
표준을 지키는지 점검하는 스크립트도 만들어 월 1회 돌렸다. 설정 파일과 확인 절차와 기록 파일의 유무를 프로젝트별로 찍어 주므로 새 프로젝트가 들어오면 여기서 걸린다. 두 달 뒤 새 프로젝트를 맡았을 때는 틀 디렉터리를 복사해 시작해서 처음부터 조건을 만족했다.
못 지키는 경우의 기록
한 프로젝트는 조건 둘을 끝내 못 채웠다. 고객사 서버라 우리가 배포 구조를 바꿀 수 없었고 상태 확인용 경로도 만들 수 없었다.
억지로 맞추려다 그만두고 못 채운 것을 적은 뒤 그에 맞는 대비를 따로 했다. 되돌리기 대신 배포 전 백업을 우리 쪽에서 받아 두고 자동 확인 대신 배포 뒤 화면을 눈으로 확인한다.
전부 같게 만드는 것이 목적이 아니라 위험을 아는 것이 목적이었으므로 못 지키는 것을 숨기지 않고 적었다. 적어 두니 그 프로젝트를 다룰 때 더 조심하게 됐다.
정리
- 방식이 제각각이면 옮길 때마다 새로 배운다
- 무엇이 다른지 표로 만든다
- 방식을 통일하는 것이 아니라 조건을 통일한다
- 위험한 것부터 하나씩 조건을 채운다
- 조건을 채우면 자연히 비슷해지고 그때 공통 흐름으로 묶는다
- 정말 다른 것은 덮어쓰게 둔다
- 표준을 지키는지 확인하는 것을 만든다
- 못 지키는 것은 숨기지 않고 적고 그에 맞는 대비를 한다