Clarify ci-seed ownership and injection flow for CI E2E

[keIIy-kim]

배경

현재 ci-seed는 CI E2E 전용 seed SQL과 그 주입 경로를 뜻하지만, 구현과 문서가 섞여 있어서 의미가 직관적이지 않습니다.

관련 경로:

• docs/reference/infra/e2e-testing.md
• scripts/ci-e2e
• scripts/e2e-backend
• backend/*/src/main/resources/db/migration/ci-seed/*

현재 적용 경로 한눈에 보기

flowchart TD
  Start[CI E2E / 로컬 디버그] --> Decide{seed를 어떻게 넣는가?}

  Decide -->|Flyway location 포함| Flyway[db/migration/ci-seed/*.sql]
  Decide -->|script 직접 주입| Script[docker cp + psql -f]

  Common[app 공통 seed] --> DB[(test database)]
  Flyway --> DB
  Script --> DB
  Service[서비스별 ci-seed] --> DB

  DB --> Result[app / meetpie / deskpie e2e 실행]

Loading

현재 혼란 포인트

• 일부 경로에서는 classpath:db/migration/ci-seed를 Flyway location에 포함시켜 자동 적용한다고 설명함
• 동시에 scripts/ci-e2e, scripts/e2e-backend는 docker cp + psql -f로 seed SQL을 직접 주입함
• app 공통 seed와 서비스별 ci-seed의 책임 경계가 코드/문서에서 한 번에 이해되지 않음
• 결과적으로 다음 질문에 즉답이 어렵다:
  • ci-seed의 SSOT는 Flyway인가, 스크립트 직접 주입인가?
  • 어떤 서비스가 어떤 seed 파일을 언제 적용해야 하는가?
  • PR 이미지 / dev-latest / 로컬 디버그에서 경로가 왜 다른가?

목표

• ci-seed의 개념과 적용 시점을 한 문장으로 설명 가능하게 정리한다
• seed 적용 경로의 SSOT를 하나로 정하거나, 둘 다 필요하다면 fallback 규칙을 명시한다
• app 공통 seed와 서비스별 ci-seed의 책임을 문서/스크립트/테스트에서 일관되게 표현한다

제안 작업

• scripts/ci-e2e, scripts/e2e-backend, docs/reference/infra/e2e-testing.md를 함께 검토
• 아래를 명시적으로 정리
  • 자동 적용(Flyway) 경로
  • 수동 주입(psql) 경로
  • 어떤 이미지/환경에서 어떤 경로를 타는지
  • app seed vs service seed 책임
• 가능하면 실행 경로를 단순화하거나, 최소한 fallback 이유를 문서화
• 관련 bats / migration 구조 테스트도 용어 기준으로 보강

완료 조건

• 팀원이 ci-seed가 무엇인지, 왜 필요한지, 어느 경로가 우선인지 PR 설명 없이 이해할 수 있다
• 문서와 스크립트 설명이 서로 모순되지 않는다