12단계
12단계 — 서비스 변경을 다섯 관점과 배포 Smoke로 검증하기
0회 조회
목차
12단계 — 서비스 변경을 다섯 관점과 배포 Smoke로 검증하기
검증 단계는 새 기술을 추가하는 것이 아니라, 한 변경이 실제로 끝났는지 증명하는 일입니다. 콘텐츠 추가와 관리 콘솔·DB·Docker·정적 mirror·PROD 배포를 하나의 체크리스트로 연결합니다. 다음 단계에서는 이 증거가 여러 서비스의 실패·복구 상태에서도 같은 의미를 유지하는지 확인합니다.
완료 판정표
| 관점 | 완료 증거 |
|---|---|
| 기획 | 정상·빈 상태·부분 실패·복구 요구가 상태표에 있음 |
| 디자인 | 모바일·키보드·포커스·오류·재시도 상태를 확인함 |
| 개발 | 한영 콘텐츠·타입·SQL 제약·인덱스·테스트가 통과함 |
| 사용자 | 공개 SSR과 Fly가 같은 의미를 보이고 현재 상태를 설명함 |
| 운영 | SHA image·health/readiness·실제 DB smoke·로그·rollback이 있음 |
다섯 관점에서 공개 smoke까지
정상·빈 상태·부분 실패의 완료 조건을 고릅니다.
모바일·키보드·오류 상태에서 다음 행동을 보이게 합니다.
API·DB·캐시와 테스트가 같은 계약을 가리키게 합니다.
성공·진행·실패를 구분하고 다시 시도할 길을 제공합니다.
readiness·DB smoke·공개 URL과 rollback 증거를 잇습니다.
이 저장소의 배포 순서
- clean worktree와 developer 폴더 제외 상태를 확인합니다.
- 관리 콘솔·콘텐츠 검증과 build를 실행합니다.
- Docker PROD에서 SSR을 Git SHA image로 배포하고 실제 공개 읽기 smoke를 확인합니다.
- 인증된 관리 콘솔 화면에서
courses/·notes/를 콘텐츠 DB에 수동 업서트합니다. - export API가 새 한영 콘텐츠를 반환하는지 확인한 뒤
fly deploy --no-cache로 정적 미러를 배포합니다. /,/en, 강좌·노트·검색·sitemap·healthcheck를 양쪽에서 확인합니다.
결제·gRPC·WebSocket·WebRTC·미디어·음성 대화·원격 CI는 제품/운영 계약이 없거나 저장소 정책과 충돌할 수 있습니다. 범위를 억지로 늘리는 대신 도입 조건과 보류 이유를 기록하는 것이 안전한 설계입니다.
이 순서를 실행 로그와 release tag에 남겼을 때만 완료라고 판정합니다.