website: #320 CD 자동 롤백 로직, 4가지 시나리오로 검증하고 테스트용 마이그레이션 정리

로직 자체는 간단하다. 마이그레이션이 순수 추가형(신규 테이블, ADD COLUMN)이면 실패해도 안전하게 롤백할 수 있고, 삭제·변경형(테이블 재생성, RENAME COLUMN)이면 이미 되돌릴 수 없는 상태라 롤백을 생략해야 한다. 문제는 이걸 판정하는 정규식과 조건 분기가 실제 배포 상황에서 제대로 갈라지는지, 코드만 봐서는 확신이 안 섰다는 점이다. 그래서 stage 환경에 실제로 마이그레이션 파일을 올려서 케이스별로 태워보기로 했다.

시나리오는 4개로 나눴다. A는 순수 추가형(신규 테이블) + 성공, B는 삭제·변경형(테이블 재생성 패턴) + 실패, C는 순수 추가형(ADD COLUMN) + 성공, D는 삭제·변경형(RENAME COLUMN) + 성공. 여기서 B는 일부러 실패를 유도해서 자동 롤백이 걸리는지 보는 케이스고, 나머지는 정상 배포 흐름이 위험도 판단 스텝 때문에 막히지 않는지 확인하는 케이스다. B와 D를 같은 삭제·변경형이라도 다른 패턴(재생성 vs RENAME COLUMN)으로 만든 건, 판정 정규식이 한 가지 패턴에만 맞춰져 있지 않은지 다른 분기까지 걸어보기 위해서였다.

각 SQL 파일 맨 위에 "절대 dev/main에 merge하지 않는다"는 주석을 달아뒀는데, 실제로 검증용 더미라서 실제 코드 로직이 아니라 배포 파이프라인 자체를 테스트하기 위한 파일들이었다. cd_test_marker라는 더미 테이블 하나를 만들어놓고 A에서 생성, B에서 재생성 패턴으로 삭제/변경, C에서 컬럼 추가, D에서 컬럼 이름 변경까지 순서대로 태우면서 자동 롤백 로직이 각 경우에 맞게 반응하는지 봤다.

결과는 4가지 조합 전부 의도대로 나왔다. 추가형+실패는 자동 롤백, 삭제·변경형+실패는 롤백 생략, 성공 경로 두 개는 위험도 판단 스텝에 걸리지 않고 정상 배포됐다. 검증이 끝났으니 이번 커밋에서는 실측용으로 만들었던 4개 마이그레이션 파일만 지웠다. 조건부 롤백 로직 자체는 이미 실제 코드에 들어가 있는 거라 이 커밋에서 건드릴 게 없었고, 삭제만 25줄이다.

남은 건 stage DB에 남아있는 cd_test_marker 테이블인데, 이건 이번 커밋이 배포된 다음 Reset Stage DB로 정리하기로 했다. 마이그레이션 파일을 지워도 이미 실행된 DB 상태까지 자동으로 되돌아가는 건 아니라서, 파일 삭제와 실제 DB 정리는 순서를 나눠서 처리해야 했다.