배포 절차를 문서로 만들며

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

Open Table of contents

적어 보니 빠진 게 많았다

머릿속에서는 간단했다.

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

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번과 동일)

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

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

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