배포가 성공했다고 나왔는데 운영 화면이 그대로인 상황은 코드 수정만 다시 해서는 풀리지 않는다. 어느 프로젝트와 어느 환경에 올렸는지부터 맞춰야 한다. 나는 이전 인수인계에 남은 브랜치 주의사항을 읽고 이번 홈페이지의 실제 설정과 나누어 확인했다.
성공 표시가 가리키는 대상을 먼저 적는다
배포 작업의 성공은 파일을 받아 처리한 특정 배포의 상태다. 고객이 보는 대표 주소가 그 배포를 가리키는지는 다음 확인이다. 과거 작업 문서에는 운영 브랜치와 다른 이름으로 올리면 미리보기로 들어간다는 주의가 남아 있었다. 그 기록을 당시 프로젝트의 조건으로 읽고 모든 홈페이지에 같은 브랜치 이름을 사용해야 한다는 규칙으로 바꾸지 않았다.
확인할 좌표는 프로젝트, 업로드한 브랜치, 배포 환경과 배포 식별자, 대표 주소다. 제목이 같은 두 화면을 보는 것만으로 배포를 구별하기 어렵다. 이번 전용 프로젝트에서는 API로 현재 대표 배포와 기록한 배포가 같은지 읽었다. 내용이 바뀌지 않을 때도 어느 단계까지 맞는지 판단할 수 있도록 배포의 대상을 먼저 남긴다.
브랜치 이름의 뜻은 프로젝트 설정이 정한다
main이나 master라는 이름만으로 운영 여부를 판단하면 설정이 다른 프로젝트에서 틀릴 수 있다. 이번 사이트는 처음 임시 검증용 전용 프로젝트로 만들었고 운영 브랜치 이름을 preview로 두었다. 현재 API에서도 업로드 브랜치는 preview이며 배포 환경은 production이다. 이름에 미리보기라는 단어가 있어도 실제 환경은 프로젝트의 설정으로 결정되는 사례다.
따라서 과거 작업 문서의 배포 명령을 다른 프로젝트에 그대로 붙이지 않는다. 먼저 대상 프로젝트의 현재 운영 브랜치와 배포 설정을 읽고 명령의 값이 그 조건에 맞는지 확인한다. 처음에는 임시 주소였던 사이트에 대표 도메인을 연결한 뒤에도 프로젝트의 이름만 보고 공개 상태를 추정하지 않고 연결된 배포와 주소를 따로 확인했다.
미리보기와 대표 주소의 파일을 대조한다
대표 주소가 올바른 배포를 가리켜도 원하는 파일이 포함되었는지 확인해야 한다. 빌드 폴더를 잘못 골랐거나 수정 전 출력물을 올리면 배포 상태는 성공이어도 내용은 이전일 수 있다. 나는 어떤 소스에서 어떤 출력물을 만들었는지와 업로드 대상 폴더를 연결하는 편이 오류를 찾기 쉽다고 생각한다.
정적 파일은 선택한 로컬 출력의 해시와 공개 응답의 실제 바이트를 비교할 수 있다. 이번 홈페이지에서도 대표 화면과 글 목록이 참조하는 세 스타일 파일을 읽어 로컬 출력과 같은지 확인했다. 이 비교는 해당 파일의 전달을 확인하는 방법이다. 실제 브라우저 캐시나 다른 CSS가 덮는 효과까지 모두 확인했다고 말하지 않는다.
콘텐츠 저장과 정적 배포는 확인 방법이 다르다
이 홈페이지의 글은 전용 콘텐츠 저장소가 정본이다. 새 원고를 API로 발행하면 본문과 목록, RSS와 사이트맵이 공개 상태를 읽어 반영된다. 정적 출력 폴더의 예전 글 파일을 고쳤다고 이미 관리 중인 원고가 바뀌는 구조는 아니다. 사이트 외형의 배포와 원고의 저장을 혼동하지 않도록 관리 진입점도 구별했다.
이번 글 발행에서는 원고 버전과 발행 상태, 한국어와 영어의 공개 주소를 확인한다. 사이트 외형을 바꿀 때는 빌드와 배포, 정적 자산의 응답을 확인한다. 어떤 변경을 했는지에 따라 맞는 정본과 검증 경로를 골라야 한다. 작업 로그의 성공 줄 하나를 모든 변경의 완료 근거로 사용하지 않는다.
다음 작업자가 같은 주소를 다시 찾게 남긴다
인수인계에는 실제로 사용한 프로젝트와 운영 브랜치, 대표 배포의 확인 시점과 원고 관리 진입점을 남긴다. 다만 그런 내부 좌표를 공개 글에 모두 옮길 필요는 없다. 고객에게는 왜 성공 표시와 화면이 다를 수 있는지, 어떤 순서로 원인을 좁히는지가 더 유용하다. 실제 식별자는 비공개 근거로 보존한다.
이번에는 이 작업의 전용 프로젝트만 API로 읽었으며 다른 사이트 배포나 DNS는 바꾸지 않았다. 과거 프로젝트의 당시 기록과 현재 사이트의 확인을 구별했고 새 브라우저 화면은 검수하지 않았다. 배포를 다시 반복하기 전에 설정과 정본, 실제 응답을 연결하는 방법을 남기는 것이 이 장의 목적이다.