배포 확인

1. 프로덕션 주소 열기

/release 는 성공 시 RELEASE_OK 와 prod URL(https://my-project.popupstudio.ai)을 보고한다.

dev 도메인은 my-project-dev.popupstudio.ai, prod 도메인은 -dev 없는 my-project.popupstudio.ai 다. 고객 트래픽은 prod 도메인으로 간다.

스킬이 이미 curl 헬스체크를 돌린다. 기대값은 HTTPS root 200/302, HTTP redirect 301, static CSS 200, admin login 200, local gunicorn 200/302 다. 전부 통과해야 RELEASE_OK 다.

추가로 prod URL 을 브라우저에서 열어 방금 배포한 변경이 실제 화면에 반영됐는지 확인한다. static 이 안 바뀌었으면 collectstatic 누락을 의심한다.

2. 문제가 있을 때

/release 는 실패를 BLOCKED: <이유> 상태로 멈춘다: no-user·dirty-tree·ff-fail·migrate-failed·service-failed·huey-service-failed·healthcheck-failed. 자동 복구·자동 롤백을 하지 않고 사용자 결정을 기다린다.

healthcheck-failed·service-failed 면 로그를 먼저 본다.

# 🖥️ prod 박스에서 (또는 SSH 원격)
sudo journalctl -u my-project-prod.service -n 100 --no-pager
sudo tail -n 100 /var/log/apache2/my-project-prod-error.log

대처는 forward-fix 를 우선한다. 코드 롤백이 필요하면 수동으로 직전 태그를 checkout 하고 collectstatic 후 서비스를 재시작한다. 마이그레이션 역적용은 데이터 손실 가능성이 있으므로 함부로 하지 않는다.

# 🖥️ prod 박스에서 (코드 롤백)
cd ~/my_project/src && git checkout <직전 tag>
MY_PROJECT_PRODUCTION=True python manage.py collectstatic --noinput
sudo systemctl restart my-project-prod.service

마무리

• 핵심 정리: RELEASE_OK 와 prod URL 을 확인하고 브라우저로 변경 반영을 검증했다. BLOCKED 면 로그(journalctl·apache error)를 먼저 보고 forward-fix 를 우선한다.
• 주의 사항: ① dev 도메인(-dev)과 prod 도메인을 혼동하지 않는다. ② 자동 롤백이 없으므로 BLOCKED 는 사람이 판단한다. ③ 마이그레이션 역적용은 데이터 손실 위험, forward-fix 우선.
• 다음 시간: 온보딩의 환경 준비부터 배포까지 마쳤다. 더 깊은 원리와 응용은 세션에서 다룬다.