머지했는데 왜 안 바뀌지 — 두 저장소의 배포 감각이 정반대였다
계획서에 이렇게 적었다
앱의 진입 HTML을 고치는 작업이었다. 검색 결과와 링크 미리보기에 Flutter 기본 템플릿 값이 그대로 나가고 있어서 그걸 브랜드에 맞게 바꾸는, 크지 않은 일이었다.
계획서 마지막 단계를 이렇게 적었다.
머지되면 CI가 컨테이너 이미지를 빌드하고 그것이 서비스된다. 머지만으로 완료로 보지 않고 라이브를 직접 조회해 확인한다.
앞 문장이 틀렸다는 것을 머지한 다음에 알았다.
실제로는 아무 일도 일어나지 않았다
머지하고 워크플로 목록을 봤다. 방금 것이 없었다. 브랜치를 바꿔 다시 봐도 없었다.
설정 파일을 열었다.
on:
push:
branches: [main]
web-image: if: github.ref == 'refs/heads/main'
admin-image: if: github.ref == 'refs/heads/main'
web-deploy: if: github.ref == 'refs/heads/main'
이미지 빌드와 배포는 main에서만 실행된다. 통합 브랜치에 머지하는 것으로는 아무것도 일어나지 않는다. 실제로 그 전 단계에서 이미 증거가 있었다 — PR 화면의 체크 목록에 이 잡들이 skipping으로 찍혀 있었다. 나는 그걸 보고도 "PR이니까 당연히 건너뛰겠지"라고 넘겼다.
그런데 다른 저장소도 머지로는 배포되지 않는다
여기서 헷갈리는 지점이 생긴다.
지금 읽고 계신 이 사이트는 다른 저장소에 있고, 그쪽도 머지만으로는 배포되지 않는다. 정적 파일을 명령으로 직접 업로드하는 방식이라, 머지한 뒤에 배포 명령을 한 번 더 쳐야 한다.
즉 두 저장소 모두 "머지 = 배포"가 아니다. 그런데 이유가 정반대다.
사이트 : 머지해도 안 됨 → 내가 배포 명령을 쳐야 함 (즉시 반영)
앱 : 머지해도 안 됨 → main으로 릴리스해야 자동 배포됨
한쪽은 수동이라서 안 되고, 다른 쪽은 자동인데 조건이 달라서 안 된다. 앞의 것에 익숙해진 상태로 뒤의 것을 만나면, "배포 명령을 안 쳤나?" 하고 엉뚱한 곳을 보게 된다. 실제로 나는 반대 방향으로 틀렸다 — 자동일 거라고 가정했다.
고치려면 249개를 배포해야 했다
더 곤란한 것이 있었다. 통합 브랜치가 main보다 249 커밋 앞서 있었다.
메타 태그 몇 줄을 라이브에 반영하려면 그 249개가 한꺼번에 나가야 한다. 광고 통합, 디자인 개편, 학습 진행분이 유실되던 버그의 수정까지 전부. 작은 수정 하나를 위해 대형 릴리스를 하는 셈이다.
그래서 릴리스하지 않기로 했다. 링크 미리보기가 부정확한 것은 불편하지만 서비스가 멎는 문제는 아니고, 249커밋 릴리스는 그 자체로 계획과 검증이 필요한 별도 작업이다. 메타 수정은 다음 릴리스 때 함께 나간다.
고친 것은 문서였다
코드는 이미 맞게 들어갔다. 잘못된 것은 계획서의 서술이었다.
그래서 스펙과 계획 두 문서를 고쳐, 배포 트리거가 main 전용이라는 사실을 근거(설정 파일의 조건문)와 함께 적었다. 「이미지가 재빌드되지 않아 라이브 미반영」이라고 적었던 위험 항목은 위험이 아니라 사실로 바꿨다. 통합 브랜치에 머지한 시점에 라이브가 그대로인 것은 정상이다.
이걸 남기는 이유는 하나다. 다음에 이 저장소를 만지는 사람이 「머지했는데 왜 안 바뀌지」로 시간을 쓰지 않게 하려는 것이다.
배운 것
배포 파이프라인은 저장소마다 다르고, 다르다는 사실 자체를 확인하지 않으면 앞서 쓴 저장소의 감각을 그대로 가져온다. 나는 사이트 쪽 작업을 하루 종일 하고 앱으로 넘어왔고, 그 감각을 그대로 들고 갔다.
작업 계획을 쓸 때 "머지하면 배포된다"처럼 확인하지 않은 문장이 계획서에 들어가는 것이 문제다. 계획서는 나중에 그대로 실행되고, 틀린 문장은 실행 시점에야 드러난다. 그것도 이번처럼 마지막 단계에서.
지금은 계획서에 배포 단계를 쓸 때 설정 파일을 먼저 열어 본다. 30초면 된다.