Emdash CMS 배포 검증과 첫 로그인 FAQ
배포 후 실무 수용 검사, 첫 관리자 설정, 부분 성공 상태 진단.
배포 후 가장 먼저 무엇을 확인해야 하나요?
세 단계 수용 순서:
- 프론트엔드 도달: 홈이 예상 콘텐츠를 반환.
- 관리자 도달:
/_emdash/admin로드. - 데이터 쓰기: 콘텐츠 한 항목 생성·읽기.
라우트 도달만으로는 배포가 끝난 것이 아닙니다.
프론트는 되는데 관리 초기화가 실패하는 이유는?
흔한 원인:
- 바인딩 불일치(
DB,MEDIA등) - 환경 변수나 시크릿 누락
- Free 플랜에 맞지 않는 설정 유지
권장 순서: 바인딩 → 환경 변수 → 기능 티어 제약.
첫 관리자 로그인 시 무엇이 일어나나요?
보통:
- 관리자 신원 생성
- 자격 증명 등록(Passkey 등)
- 초기 시스템 상태 기록
브라우저와 계정 상태에 의존합니다. 안정적인 네트워크와 지원 브라우저에서 완료하세요.
Passkey 설정이 실패하면 무엇을 먼저 보나요?
이 순서로:
- 브라우저 지원과 Passkey 사용 가능 여부
- 시스템 시각 정확성
- 교차 출처 또는 리버스 프록시 헤더 문제
먼저 데이터베이스를 의심하지 마세요. 대부분의 인증 실패는 클라이언트나 에지 프록시 관련입니다.
최소 프로덕션 수용 스크립트란?
반복 가능한 흐름:
- 프론트 홈을 열고 응답을 기록.
- 관리자에 로그인하고 초기 설정 완료.
- 테스트 콘텐츠 생성·게시.
- 미디어 파일 하나 업로드하고 조회 확인.
- 게시된 콘텐츠가 프론트에 보이는지 확인.
라우트·인증·쓰기·스토리지·읽기를 검증합니다.
배포는 성공했는데 콘텐츠가 없습니다. 어디서 시작?
가장 짧은 진단:
- 항목이 게시됨(초안 아님).
- 프론트가 예상 컬렉션을 조회함.
- 런타임 로그에서 쿼리·권한 오류 확인.
대부분 누락은 상태나 쿼리 경로 문제이지 플랫폼 전체 장애가 아닙니다.
팀은 수용 품질을 어떻게 제도화하나요?
릴리스 워크플로에 포함:
- 머지 전: 로컬 또는 스테이징에서 세 단계 수용
- 릴리스 후: 당번 엔지니어가 10분 안에 최소 스크립트 실행
- 사고 후: 재발 방지를 위한 결정적 검사 한 가지 추가
신뢰할 수 있는 출시는 구전 기억이 아니라 프로세스 통제에서 나옵니다.
검증 명령 조각
# 런타임 검사 예
curl -I https://your-site.workers.dev
curl -I https://your-site.workers.dev/_emdash/admin
npx wrangler tail your-worker-name