dpdpdndn 블로그

BE-21-compose-bootstrap-verification

NEW7 min read

[BE-21] dev/prod compose 기동 검증 · 초기 4사 등록 절차

작업 내용 (설계 의도)

근거 TDD: 20260722-타깃-공고-알림-및-지원-히스토리-tdd.md — “Release Scenario”

변경 사항

TDD의 Release Scenario 6단계를 실제로 수행 가능한 상태로 만들고 검증합니다. 코드 산출물보다 검증 아티팩트와 절차 문서가 주된 결과물입니다.

수행 범위:

  1. dev/prod compose 기동 검증 — docker-compose.yml(dev)과 docker-compose.prod.yml(prod) 양쪽으로 기동해 헬스체크 200, Flyway V1 적용 성공, 스케줄러 등록을 확인합니다. prod 이미지 태그는 릴리즈 태그({YYYYMMDD}-{NN})로 고정하며 latest를 쓰지 않습니다.
  2. 단계적 활성화 절차 검증 — 피처 플래그 4종이 초기값 false로 시드되어 있고, DB UPDATE만으로 재기동 없이 동작이 바뀌는지 확인합니다. 이것이 무중단 롤백의 근거입니다. 활성화 순서는 discord-dispatch → auto-close → aggregator.collection → cross-source-dedup입니다(Release Scenario).
  3. 초기 4사 + 애그리게이터 6소스 등록 절차 — 당근(Greenhouse daangn) / 배민(내부 API) / 우리은행(인크루트 wooribank) / 수협은행(인크루트 suhyup-bank) 회사 종속형 4사 + 애그리게이터 6종(사람인·점핏·원티드·리멤버·잡코리아·서핏) 소스(직무 카테고리 코드 지정)의 등록 요청 예시와 확인 지점을 절차 문서로 남깁니다(FR-7·60). 규약 청정 2종(6a) → 회색지대 4종(6b) 순으로 단계 활성화(Release Scenario).
  4. 시딩 동작 확인 — 첫 수집 후 공고가 notification_eligible=0으로 적재되고 발송이 0건인지 확인합니다.
  5. 롤백 리허설 — 플래그 OFF 시 마감 판정·발송이 즉시 멈추는지, prod 이미지 태그를 직전 값으로 되돌려 재기동되는지 확인합니다.

이 티켓은 BE-01이 만든 compose·Dockerfile을 수정하지 않습니다. 기동 검증 중 설정 결함이 발견되면 수정 범위를 이 티켓에서 처리하되, 변경 파일이 BE-01 소유와 겹치므로 마지막 wave 단독 배치로 두어 충돌을 원천 차단합니다.

롤백: 각 단계가 독립적이며, 실패 시 컨테이너 중지 + 스키마 드롭(데이터 0건)으로 처음부터 재수행 가능합니다.

의존

  • BE-19, BE-20 (전 기능 완성 후 수행)

다이어그램

처리 흐름

sequenceDiagram
    participant O as 운영자
    participant D as docker compose
    participant A as 애플리케이션
    participant F as feature_flags
    participant S as 채용 소스
    O->>D: up -d (dev)
    D->>A: 기동 + Flyway V1
    A-->>O: health 200
    O->>A: 회사 4곳 등록
    O->>A: 1회차 수집 (시딩)
    A->>S: 목록 조회
    A-->>O: 공고 적재 · 알림 0건
    O->>F: notification.discord-dispatch = true
    A-->>O: 재기동 없이 발송 활성화
    O->>F: posting.auto-close = true (마지막)
    A-->>O: 마감 판정 활성화

클래스 의존

flowchart LR
    subgraph Compose["컨테이너 구성"]
        Dev[docker-compose.yml]
        Prod[docker-compose.prod.yml]
        App[app 서비스]
        DB[mysql 8.0]
    end
    subgraph Runtime["런타임 확인 대상"]
        Flag[feature_flags]
        Flyway[flyway_schema_history]
        Sched[Scheduler 4종]
    end
    Dev --> App
    Prod --> App
    App --> DB
    App --> Flag
    App --> Flyway
    App --> Sched

테스트 케이스

  • dev compose로 기동 시 헬스체크가 200을 반환하고 Flyway V1이 SUCCESS로 기록된다
  • prod compose로 기동 시 이미지 태그가 릴리즈 태그로 고정되어 있고 latest가 사용되지 않는다
  • 초기 기동 시 피처 플래그 4종이 모두 false로 시드되어 있다
  • 플래그를 DB에서 true로 UPDATE하면 재기동 없이 다음 배치 실행부터 동작이 바뀐다
  • 6개 스케줄러(00:00 수집 / 00:10 애그리게이터 / 00:30 마감 / 08:30 dedup / 08:50 평가 / 09:00 발송)가 각각 등록되고 지정된 cron·타임존(Asia/Seoul)으로 설정된다
  • 초기 4사 등록 절차대로 실행하면 회사 종속형 소스가 5건(우리은행 2건 포함) 등록된다
  • 애그리게이터 6종 소스가 companyId=null로 등록되고 다음 수집(00:10) 대상에 포함된다
  • 잡코리아 어댑터가 키워드 검색 경로를 호출하려 하면 규약 정책이 차단한다(회색지대 규약 준수 확인)
  • 애그리게이터 첫 수집 후 발견 회사가 DISCOVERED로 자동 등록되고 공고가 notification_eligible=0으로 적재된다
  • 피처 플래그 4종(posting.auto-close·notification.discord-dispatch·posting.cross-source-dedup·aggregator.collection)이 모두 false로 시드되어 있다
  • 첫 수집 후 공고가 notification_eligible=0으로 적재되고 발송이 0건이다
  • posting.auto-close=false 상태에서 마감 판정이 0건으로 동작한다
  • prod 이미지 태그를 직전 값으로 되돌려 재기동하면 정상 동작한다
  • 컨테이너 재기동 후에도 수집 이력과 공고 데이터가 보존된다

그래프 뷰