배포 절차를 문서로 만들며

SVN 에서 받아 서버에 올리는 배포를 나만 할 수 있는 상태였고 순서를 아는 것도 나뿐이었다. 휴가를 가야 해서 문서로 옮겨야 했다.

Open Table of contents

적어 보니 빠진 게 많았다

머릿속에서는 간단했다.

1. 빌드
2. 올리기
3. 재기동

SVN 에서 받는 것부터 적으면서 보니 사이사이에 하는 것이 많았다. 각 명령이 무엇을 하는지는 SVN 공식 문서의 명령 목록에서 다시 확인했다.

빌드 전에 브랜치 확인
올리기 전에 기존 파일 백업
재기동 전에 처리 중인 작업 확인
재기동 후 로그 확인
화면 몇 개 열어 보기

손이 기억하는 것들이었다. 의식하지 않고 하니까 적을 때 빠뜨리고 ssh 로 어느 서버에 먼저 붙는지와 Apache 를 내렸다 올리는 사이에 몇 초를 기다리는지 같은 것은 적을 생각도 안 든다.

문서를 쓰고 나서 다른 사람에게 ssh 부터 그대로 해 보라고 했다. 막히는 데가 여럿 나왔다.

"어느 서버요?"          → 서버 이름을 안 적었다
"이 명령 어디서 실행해요?" → 실행 위치를 안 적었다
"이게 성공한 건가요?"     → 성공 출력이 어떤 건지 안 적었다

나는 아니까 안 적은 것들이다. 내가 혼자 다시 읽어서는 못 찾았을 부분이고 문서가 충분한지는 그 문서만 보고 해 보는 사람이 판정해 준다.

세 번째 질문이 특히 중요했다. 원래 문서는 이랬다.

3. 재기동한다
4. 확인한다

무엇을 보고 무엇이면 성공인지가 없어서 바꿨다.

3. 재기동:  ./restart.sh
   성공 출력:  "started with pid NNNN"

4. 확인:
   - 로그에 ERROR 없음 (1분간)
   - 목록 화면 응답 200
   - 상세 화면 응답 200
   하나라도 실패하면 5번 복구 절차로

무엇이면 정상이고 아니면 무엇을 하는지를 같이 적었다. curl 로 찔러 200 이 오는지와 Apache 오류 로그에 grep 을 걸어 새 줄이 없는지가 그 기준이다.

설명 문장 대신 그대로 복사할 수 있는 명령으로 적었다.

✗  api 디렉터리로 가서 스크립트를 실행한다
✓  cd /var/www/api && ./restart.sh

설명은 해석이 필요하고 cd 와 ./restart.sh 는 안 그렇다. 값이 바뀌는 부분만 표시했다.

scp api.jar 서버:/var/www/api/       ← 서버 = a, b, c 중 하나

문서로 적다 보니 이것은 그냥 Bash 스크립트로 만들면 되겠다 싶은 것이 나왔다. scp 로 올리는 데까지 여러 단계가 항상 같은 순서면 묶었다.

#!/bin/bash
set -e
backup_current
upload_new
restart
verify || restore_backup

set -e 를 건 스크립트가 곧 문서가 됐고 사람이 순서를 틀릴 일이 없다. 다만 판단이 필요한 부분은 스크립트에 안 넣었는데 로그를 보고 이상하면 멈추는 것 같은 것은 사람이 한다.

나갈 때만 적으면 문제가 생겼을 때 이전 판으로 못 간다.

[복구]
1. cp api.jar.bak api.jar
2. ./restart.sh
3. 확인 (위 4번과 동일)

복구 절차를 같은 문서의 나가는 길 바로 다음에 뒀다. 급할 때 문서를 뒤지지 않게 하려는 것이다.

휴가에서 돌아와 보니 다른 사람이 그 문서로 두 번 배포했고 문제없었다. 한 가지 질문이 왔었다고 했는데 문서에 없던 상황이었다.

돌아와서 그것을 문서에 추가했고 이런 식으로 문서가 채워진다. 한 번에 완벽한 문서를 쓸 수는 없고 남이 실행하면서 막히는 곳이 나오면 채우면 된다.