콘텐츠로 이동

테스트/CI 전략

문서 역할

  • 역할: 규범
  • 문서 종류: policy
  • 충돌 시 우선 문서: 이 문서
  • 기준 성격: as-is

목적

  • 레포별 테스트 위치와 docs 포함 공통 검증 게이트를 고정한다.

공통 품질 게이트 (단일 SoT)

  • 코드 레포의 표준 품질 게이트는 계약 검사, lint, typecheck, format, test를 묶은 verify다.
  • docs의 표준 품질 게이트는 docs 구조 검증, 문서 lifecycle 검증, 에이전트 작업흐름 검증, 논리 데이터 모델 검증, 기술부채 인벤토리 검증, 릴리스 기록 검증, API 에러 문서 검증, 릴리스 preflight 스크립트 검증, markdownlint, mkdocs build --strict다.
  • 레포에서 미제공인 항목은 N/A로 표기하고, 미적용 근거를 PR/작업 보고에 남긴다.
  • 표준 검증 명령은 아래를 단일 기준으로 사용한다.
    • coupler-api: pnpm verify
    • coupler-mobile-app: yarn verify
    • coupler-admin-web: yarn verify
    • docs: yarn verify
  • API의 verify는 계약 freshness/build/pack 검사를 항상 포함한다.
  • Admin/Mobile 계약 소비 검증은 API 클라이언트 계약 패키지 정책의 published latest stable version을 목표로 삼고, GitHub Packages registry/auth 설정, package.json, lockfile의 @coupler-developer/coupler-api-contracts exact version, 각 소비자 레포 표준 품질 게이트를 기준으로 한다.
  • Admin/Mobile이 계약 패키지 버전을 갱신하는 PR은 해당 소비자 레포의 표준 품질 게이트를 통과해야 한다. 이때 GitHub Packages registry/auth 설정과 package.json/lockfile의 @coupler-developer/coupler-api-contracts version이 일치하는지 확인한다.

검증 진입점 분화 방지

  • 개발자용 전체 검증 진입점은 verify 하나만 사용한다. test는 CI 테스트 job과 같은 테스트 진입점이며 verify 전체 완료를 뜻하지 않는다.
  • test:ci, verify:ci, ci:test, ci:verify처럼 로컬과 CI의 표준 Gate를 나누는 별칭을 금지한다.
  • CI는 병렬화를 위해 verify의 leaf 명령을 job으로 나눌 수 있지만, package script와 workflow 계약 테스트가 verify의 정확한 구성, 전체 leaf coverage, 금지 별칭 부재를 함께 고정해야 한다.
  • docs의 verify와 validate:docs-static은 단일 docs-validation-runner가 폐쇄형 leaf 목록과 최대 2개 병렬 실행을 소유한다. 개별 package script도 같은 runner의 task ID를 사용하며, runner 계약 테스트가 full/static 집합의 exact coverage, 중복 task 0건, 동시 실행 상한과 실패 후 신규 task 중단을 고정한다. 병렬화는 실행 순서만 바꾸며 Gate의 입력, 실패 조건과 증빙 범위를 줄이지 않는다.
  • 테스트 파일 확장자와 계약 의존성 형식처럼 로컬에서 판정 가능한 규칙은 test 또는 verify에 포함하고, workflow inline 전용 검사로 중복 소유하지 않는다.
  • DB migration 실제 재생, PR base/current-tree 비교, release native visual처럼 외부 서비스나 event 문맥이 필요한 검사는 CI-context 예외다. 예외는 로컬 통과만으로 확인했다고 보고하지 않는다.

검증 중복 판정

  • 검증 실행 경로를 리뷰할 때는 event, 대상 ref, 비교 baseline, 검증 명령, 생성 산출물과 실패 책임을 먼저 펼친다. 이 항목이 같고 새 증빙을 만들지 않는 동일 Gate 재실행은 중복으로 판정해 공통 runner 한 번으로 합친다.
  • baseline 전환 검증이 공통 runner의 validator와 같은 현재 상태 검증을 포함하면 별도 선행 실행을 추가하지 않고 baseline을 공통 runner에 주입한다. 경량 경로처럼 공통 runner를 실행하지 않는 경우에만 전환 검증을 실행한다.
  • 현재 산출물의 계약 검증과 validator 자체의 반대 조건·변이 회귀 테스트는 판정 대상이 다르므로 중복이 아니다.
  • PR admission, main 배포 artifact, release tag artifact처럼 event·ref·산출물 또는 신뢰 경계가 달라진 뒤의 재검증은 단계별 Gate다. 유지 사유가 신뢰 경계나 산출물로 설명되지 않으면 중복으로 판정한다.
  • 중복 제거는 검증 범위·실패 차단력을 약화해서는 안 된다. 유지하는 겹침과 제거한 중복의 근거를 PR/작업 보고에 남긴다.

차단형 validator 안전성

  • 로컬 또는 CI 품질 게이트를 실패시키는 validator는 구조화된 입력이나 문법·어휘만으로 결정 가능한 불변식만 차단한다. 자유 문장의 의미를 추론해야 위반과 정상 입력을 구분할 수 있으면 탐지 범위를 좁히거나 schema·descriptor 같은 구조화된 SoT로 전환하고, 그 전까지는 리뷰 기준으로 판정한다.
  • 차단 규칙을 추가하거나 탐지 범위를 바꿀 때는 실제 위반 입력이 실패하는 fixture와 핵심 표현을 공유하는 가장 가까운 정상 입력이 통과하는 반대 조건 fixture를 함께 추가하거나 갱신한다. 줄바꿈·구분자·인접한 다른 식별자나 version처럼 판정 경계를 바꿀 수 있는 입력은 적용 가능할 때 이 fixture에 포함한다.
  • 알려진 오탐은 validator 결함이자 차단 Finding으로 취급한다. 수정 시 해당 입력의 통과 회귀 fixture와 같은 경계의 실제 위반 입력이 계속 실패하는 fixture를 함께 고정하고, 두 조건이 모두 통과하기 전에는 완료로 판정하지 않는다.
  • 탐지 규칙의 모호함을 숨기기 위한 상시 path·문구 allowlist나 inline ignore를 추가하지 않는다. 의도적인 비적용 범위는 소유 정책 또는 descriptor에 정의하고, 비적용 입력이 통과하는 fixture로 고정한다.

로컬 최종 후보 검증

  • 최종 후보는 비교 baseline, 리뷰 범위의 파일 집합과 내용이 마지막 파일 변경 이후 동일한 상태다. 다중 레포 변경은 영향받은 각 레포의 후보를 같은 변경 묶음으로 고정한다.
  • 코드 리뷰 정책의 독립 최종 리뷰에서 열린 Finding이 0건이고 열린 Finding 0건·검증 대기 체크포인트가 기록된 뒤에만 해당 레포의 표준 통합 품질 게이트를 실행한다.
  • 동일한 최종 후보에서는 영향받은 각 레포의 표준 통합 품질 게이트를 1회만 시작한다. 통합 명령에 포함된 lint, typecheck, format, test를 관행적으로 먼저 각각 실행한 뒤 같은 통합 명령으로 반복하지 않는다.
  • 아래 표적 검증은 표준 통합 품질 게이트와 판정 대상이 다를 때만 별도로 허용한다.
    • 최초 실패 재현
    • 새로 추가·갱신한 테스트의 red/green 확인
    • 통합 품질 게이트 실패 원인 격리
    • 표준 통합 명령에 포함되지 않은 도메인 정책의 필수 검사
  • 표적 검증은 입력, 파일 내용 또는 확인할 실패 책임이 달라지지 않으면 같은 명령을 반복하지 않는다. 표적 검증 결과로 표준 통합 품질 게이트를 대체하지 않는다.
  • 통합 품질 게이트가 코드·문서·설정 문제로 실패해 파일을 수정하면 기존 후보와 리뷰 체크포인트는 만료된다. 새 최종 후보의 독립 리뷰에서 열린 Finding이 0건이 된 뒤 표준 통합 품질 게이트를 새로 1회 실행한다.
  • 후보가 바뀌지 않은 비코드 환경 실패는 실패 원인과 앞서 통과한 하위 Gate를 기록하고 실패하거나 실행되지 않은 하위 Gate만 재시도한다. 같은 통합 명령 전체를 근거 없이 처음부터 다시 실행하지 않는다.
  • 검증 명령이 리뷰 범위의 파일을 변경하면 성공 여부와 관계없이 후보가 바뀐 것으로 판정하고 독립 리뷰부터 다시 수행한다.

모바일 Storybook·native visual 게이트

  • coupler-mobile-app에 Storybook 게이트가 도입된 뒤에는 PR 검증에 yarn storybook:check를 포함한다.
  • yarn storybook:check는 Storybook story 수집, .storybook/storybook.requires.ts 최신성, Storybook 전용 TypeScript 체크, story 렌더/snapshot 테스트를 함께 검증해야 한다.
  • UI 표시 변경, Storybook 인프라 변경, 또는 이미 story가 있는 컴포넌트 변경은 관련 story와 snapshot을 함께 추가/갱신하고 PR에 변경 이유를 남긴다.
  • iOS/Android native visual job은 일반 PR과 Mobile Store 제출 준비용 release/* → main PR에서 자동 실행하지 않는다. 모든 PR은 별도 Storybook workflow의 yarn storybook:check를 유지한다.
  • native visual 검증이 필요하면 GitHub Actions의 workflow_dispatch에서 검증할 ref를 선택해 두 native visual job을 수동 실행한다. 각 플랫폼의 fresh capture를 해당 플랫폼의 기준 이미지와 비교해 두 job이 모두 통과해야 하며, 실행 URL과 결과를 PR/릴리스 증빙에 남긴다.
  • 릴리스 태그 정책의 vX.Y.Z 릴리스 태그는 운영 반영·검증 뒤 생성하는 기준점이므로 native visual의 사전 릴리스 트리거로 사용하지 않는다.
  • Storybook snapshot은 컴포넌트 표시 회귀 증빙이며, native 설정/앱 시작/실기기 동작/화면 전환 E2E 검증을 대체하지 않는다.
  • PR에서 native visual job이 예약되지 않은 상태는 적용 대상이 아니므로 N/A로 기록한다. 수동 실행을 검증 근거로 선택한 뒤 CI 결제/runner 장애처럼 테스트가 실행 전 차단된 상태는 통과로 간주하지 않는다. PR에서는 로컬 yarn storybook:check 결과를 임시 증빙으로 기록할 수 있지만 선택한 수동 native visual의 원격 CI 상태는 미검증으로 남긴다.

회귀 안전성 검증

  • 회귀 판정 기준은 엔지니어링 가드레일의 회귀 안전성 게이트를 단일 기준으로 사용한다.
  • 모든 코드 변경은 아래 위험도 중 하나로 분류하고, PR/작업 보고에 검증 근거를 남긴다.
위험도 적용 조건 최소 검증
Low 동작/정책 기준 변경 없는 문서, 주석, 포맷, 내부 정리 회귀 영향 N/A 사유와 변경 경로 근거
Medium UI 표시, API 호출부, 순수 로직, 상태 표시처럼 사용자/운영 동작에 영향 가능 보호 동작 1개 이상에 대한 테스트, 로그, 또는 수동 시나리오 결과
High API 계약, 상태 머신(FSM)/상태 전이, 권한, 결제, 푸시, DB, 배포, 네이티브/모바일 릴리스, 보안/개인정보, 다중 레포 변경 자동 테스트, 검증 스크립트, postcheck, 운영 로그, 실기기 검증 중 해당 영역의 차단 가능한 증빙
  • High 변경에서 자동 테스트가 없으면 수동 검증만으로 끝내지 않고, 왜 자동화할 수 없는지와 대체 검증 스크립트/로그를 남긴다.
  • High 변경은 아래 최소 검증을 따른다.
  • 도메인 정책이 더 상세한 검증 기준을 정하면 해당 정책을 우선한다.
변경 유형 최소 검증
API 계약 요청/응답 계약 테스트 또는 controller/route 통합 테스트. API/DB 변경이면 직전 운영 Mobile/Admin 계약과 새 API+migrated DB 조합 포함
API 조회·동작 구조 페이지 조회의 필수 데이터·권한 계약, bounded 최대치의 payload·query 수, 소비자 요청 그래프 또는 화면 테스트
상태 머신(FSM)/상태 전이 허용/거부 전이 테스트 또는 상태 차이 로그
권한/보안 권한별 허용/거부 검증
결제 중복 결제, 환불, 키 지급/회수 검증
푸시 발송, 스킵, 중복 방지, 저장 결과 검증
DB DB Migration 정책의 append-only source 검사, Docker MySQL 8.4·MariaDB 10.6 실제 replay, 재실행 skip 검증
배포 배포 후 핵심 응답, 로그, 롤백 기준 검증
네이티브/모바일 릴리스 실기기 또는 배포 리허설 검증
다중 레포 변경 각 레포 품질 게이트와 교차 계약 검증
  • 기존 정책 불일치는 이번 변경이 새로 만들거나 확산한 경우에만 신규 회귀로 본다.
  • 기존 정책 불일치 경로를 이번 변경이 직접 건드리면 최소 Medium으로 분류한다.
  • 스펙 공백이 있으면 테스트 기대값을 추측하지 않고 정책/계약/FSM을 먼저 확정한다.
  • 테스트 미실행은 not run 또는 N/A 사유만으로 충분하지 않으며, 영향 범위가 없다는 근거 경로/라인/로그를 함께 남겨야 한다.

테스트 변경 판정

  • 코드 변경이 동작, 계약, 상태, 권한, 데이터, UI/운영 흐름에 영향을 줄 수 있으면 관련 테스트를 추가하거나 갱신한다.
  • PR/작업 보고에는 테스트 변경 여부를 추가, 갱신, 미변경 중 하나로 기록하고 근거를 남긴다.
  • 미변경은 회귀 영향 없음 또는 확인 가능한 기존/대체 검증 근거가 있을 때만 인정한다.
  • 자동화 불가 또는 대체 검증은 실행 명령, 로그, 수동 시나리오 중 확인 가능한 근거로 남긴다.
  • 리뷰마다 테스트 변경 판정이 기존보다 회귀 안전성을 높이거나 최소한 약화하지 않는지 확인한다.
  • Finding 처리는 코드 리뷰 정책의 1회 수정·재리뷰 및 자동 실행 BLOCKED 기준을 따른다.
  • 테스트를 추가/갱신할 때는 skip/only, assertion 완화, 무검토 snapshot 갱신처럼 테스트를 약화하는 변경을 금지한다.

테스트 코드 전략 (레포별)

  • 공통 규칙: 코드베이스는 .js/.jsx/.ts/.tsx 혼용 가능. 테스트 파일에만 .test.ts/.test.tsx를 적용한다.

작성시 주의사항

  • 테스트 함수명이 내용과 일치하는지
  • 테스트 함수간 중복이 없는지
  • 누락된 시나리오 없는지
  • verbose한 문법 있는지
  • 테스트가 결정적인지

coupler-admin-web (CRA)

  • 러너: react-scripts test 사용.
  • 위치/규칙: src/__tests__/**/*.test.(ts|tsx)만 허용.

  • 우선순위:

    1. src/helper 등 순수 로직 단위 테스트
    2. src/pages 스모크 렌더링 테스트
    3. MobX 스토어 상태 변경 테스트

  • 외부 통신: axios mock 또는 MSW 도입 고려(현재 의존성 없음).

  • Chart.js는 “렌더링 성공 + 주요 props 처리” 수준의 얕은 테스트부터 시작한다.
  • React 목록은 공통 client의 요청/응답 계약, 페이지 이동, 검색, 정렬, 최신 요청 우선 반영과 row parser 실패 차단을 우선 검증한다.
  • TO-BE: 기존 Playwright smoke를 route·filter 검증까지 확장하고 표준 gate에 포함한다. 잔여 범위는 기술 부채 정리의 테스트용 개발 데이터 운영 검증·고도화 미완료에서 추적한다.

coupler-api (Express)

  • 러너: jest 사용.
  • 위치/규칙: __tests__/**/*.test.(ts|tsx)만 허용 (현재 jest.testMatch 기준).
  • 리팩토링 기준: 컨트롤러는 오케스트레이션, 핵심 규칙은 usecase/lib 계층으로 분리된 구조를 기준으로 테스트한다.

  • 우선순위:

    1. lib/usecase 순수 로직 단위 테스트
    2. controller/routes 통합 테스트(요청/응답 검증)

  • 외부 통신 테스트 필요 시 supertest 도입 고려(현재 의존성 없음).

  • 외부 연동(Firebase/SMS/메일): mock 처리로 실서비스 호출 차단.
  • DB 전략: 테스트용 데이터셋/트랜잭션 롤백/테이블 정리 중 하나를 고정하여 일관성 유지.
  • 공유 개발계 관리자 화면과 Mobile QA를 위한 합성 데이터는 단위·통합 테스트 fixture와 분리하며 테스트용 개발 데이터 정책을 따른다.
  • tools/dev-data는 API 표준 lint·typecheck·format·Jest에 포함하고, exact namespace marker·connection-local DB identity·embedded manifest·전역 DB lock·원자 DB transaction·symlink-safe asset inventory와 전체 media reference· member 파생 ownership reset·개발 cron data guard와 deferred response 안전 모듈은 test:dev-data-safety와 test:dev-cron-safety의 branch 100% gate로 검증한다.
  • MySQL scalar fault test는 null·빈/공백 문자열·boolean·array·object·fraction·safe integer overflow를 lock 획득/root count/lock 해제/DB identity에 주입한다. Asset fault test는 ancestor symlink, unknown inventory, same-key exclusive-create, 검증 전 삭제 0건을 확인한다.

coupler-mobile-app (React Native)

  • 러너: jest + preset: react-native 사용.
  • 위치/규칙: src/__tests__/**/*.test.(ts|tsx)만 허용.

  • 우선순위:

    1. src/screens/**의 핵심 화면 스모크 렌더링과 same-level *Step* 파일 테스트
    2. 조건부 UI/상태 변화 테스트

  • 화면과 Step의 구조 판정은 엔지니어링 가드레일의 Mobile 파일 구조와 네이밍을 따르며 이 문서는 테스트 우선순위만 소유한다.

  • 상호작용 테스트는 @testing-library/react-native 사용을 기본으로 한다.
  • 네이티브 모듈(AsyncStorage, Reanimated 등)은 Jest mock/셋업 파일로 분리 구성.

docs (MkDocs)

  • 러너: 로컬과 GitHub Actions full validation은 validate:docs-static의 공통 정적 검증 목록을 사용한다.
  • 문서 공통 정적 검증(로컬·full CI): yarn validate:docs-static
  • 문서 구조 검증(로컬): yarn validate:docs-structure
  • 문서 민감 인프라 식별자 검증(로컬·경량 CI): yarn validate:docs-sensitive
  • 문서 구조 검증 테스트(로컬): yarn test:docs-structure
  • 문서 lifecycle current registry·retirement ledger 검증(로컬, 사용 가능한 origin/main baseline 포함): yarn validate:document-lifecycle
  • 문서 lifecycle 검증 테스트(로컬): yarn test:document-lifecycle
  • 에이전트 작업흐름 검증(로컬): yarn validate:agent-workflow
  • 에이전트 작업흐름 검증 테스트(로컬): yarn test:agent-workflow
  • docs 검증 runner 계약 테스트(로컬): yarn test:docs-validation-runner
  • 논리 데이터 모델 검증(로컬): yarn validate:logical-data-model
  • 논리 데이터 모델 검증 테스트(로컬): yarn test:logical-data-model
  • 기술부채 인벤토리 검증(로컬): yarn validate:technical-debt
  • 기술부채 인벤토리 검증 테스트(로컬): yarn test:technical-debt
  • 릴리스 기록 검증(로컬): yarn validate:release-records
  • API 에러 문서 검증(로컬): yarn validate:api-error-docs
  • 릴리스 preflight·기록 불변성·CI mode 스크립트 검증(로컬): yarn test:release-preflight 과거에 게시된 DB migration evidence bytes의 최종 트리 불변성 테스트를 유지하되 새 migration 실행은 별도 plan/execution artifact를 만들지 않는다.
  • 문서 빌드(로컬): yarn build:docs (현재 문서와 임시 초기화한 미래 릴리스 기록을 각각 python3 -m mkdocs build --strict로 검증)
  • 문서 lint(로컬): yarn lint:md
  • 문서 통합 검증 leaf(로컬): yarn validate:docs
  • 문서 표준 통합 검증(로컬): yarn verify
  • 문서 공통 정적 검증(full CI): yarn validate:docs-static
  • 경량 릴리스 검증(CI): yarn validate:docs-sensitive, node scripts/validate-release-records.mjs
  • DB migration source 검증(CI): API workflow가 보호된 base와 PR source를 비교해 기존 migration 및 baseline 변경·삭제와 과거 ID 삽입을 거부하고, Docker 양 엔진에서 전체 source를 실제 replay한다.
  • 문서 lint(CI): 로컬과 같은 yarn lint:md
  • 문서 build(CI): Python 의존성 설치 후 로컬과 같은 yarn build:docs. initializer가 만든 릴리스 기록을 생성 위치에서 strict build해 템플릿 위치에만 유효한 상대 링크와 nav drift를 차단한다.

CI 전략

  • 서비스 레포(coupler-*): 기본적으로 pull_request 이벤트에서만 CI를 트리거한다.
  • docs 레포: Docs Validation 검증 워크플로는 pull_request(main)에서만 동작하며 merge gate로 사용한다.
  • docs 레포: full mode는 로컬과 같은 yarn validate:docs-static을 실행한다. 개별 validator 목록을 workflow에 다시 열거하지 않는다. PR base SHA는 DOCUMENT_LIFECYCLE_BASE_REF로 공통 runner에 주입해 current registry와 retirement ledger의 현재 상태·전환을 한 번에 검증한다. 경량 mode만 공통 runner가 없으므로 lifecycle 전환을 실행한다.
  • docs 레포: PR 병합 뒤 push(main)에서는 push 이전 SHA를 DOCUMENT_LIFECYCLE_BASE_REF로 주입한 yarn verify 한 번이 새 main의 Pages artifact를 검증한다. PR admission과 main 배포는 ref·산출물· 신뢰 경계가 다르므로 단계별 검증이며, 같은 deploy job 안에서 lifecycle을 별도 선행 실행하지 않는다.
  • docs 레포: release tag workflow의 yarn verify는 tag ref에서 패키징할 site artifact를 다시 생성·검증하는 release Gate이며 PR·main 배포 검증과 산출물이 다르다.
  • docs 레포: 변경 파일이 신규 nonterminal 릴리스 기록과 initializer가 결정적으로 만든 lifecycle registry, content/AGENTS.md, mkdocs.yml의 정확한 네 파일 집합이면 docs-structure에서 민감 인프라 식별자, 신규 metadata와 lifecycle 전환을 경량 검증한다. companion 파일이 initializer 결과와 다르거나 released/terminal 기록, 일반 문서, policy, script, workflow가 함께 바뀌면 기존 전체 검증을 실행한다.
  • docs 레포: nonterminal 릴리스 기록을 포함한 PR은 Draft일 때만 검증을 통과한다. ready_for_review와 converted_to_draft에서도 검증을 다시 실행해 terminal 전 Ready/병합을 차단한다.
  • docs 레포: 게시된 pending 기록 복구는 다른 scope metadata/evidence와 비허용 본문 변경을 거부하는 fail-closed fixture, 정상 단일 terminalization fixture, terminal 재수정 거부 fixture를 유지한다. docs tag readiness는 전체 상태·docs scope·version mapping tag의 terminal/exact fixture로 별도 검증한다.
  • docs 레포: markdown-lint와 build-docs는 validation mode와 무관하게 docs-structure와 동시에 시작한다. full mode의 공통 정적 검증 목록은 계속 yarn validate:docs-static 한 곳에서만 소유한다.
  • docs 레포: 같은 PR의 새 push가 이전 검증과 겹치면 concurrency로 이전 실행을 취소한다. 자동 검증은 PR 내부 커밋의 상태 전이 이력을 검사하지 않고 base와 현재 최종 트리만 비교한다.

DB 마이그레이션 검증 (공통)

  • 운영 반영 전 최소 검증 순서는 DB Migration 정책의 표준 절차를 따른다.
  • 상세 판정 기준은 DB Migration 정책을 단일 기준으로 사용한다.
  • API No는 release-scoped Store/OTA/Admin consumer-interface가 현재 API+최종 DB에서 성공하는 자동 계약·통합 테스트 또는 재현 가능한 smoke로 검증한다.
  • API CI는 baseline과 정렬된 전체 migration을 MariaDB 10.6과 MySQL 8.4에서 실제 실행하고, 최종 schema lock, 재실행 시 SQL 0건, append-only·checksum·leading-prefix 계약을 검증한다.
  • API 배포·health/smoke·traffic 재개와 API rollback 검증은 DB migration runner가 아니라 API·릴리스 테스트가 별도로 소유한다.
  • Store 강제 업데이트, NextPush mandatory와 버전을 구분할 수 없는 traffic 0건은 위 case나 runtime 조합 테스트를 대체하지 않는다.
  • CI는 API source admission·Docker 양 엔진 replay와 과거 docs 기록 불변성만 검증한다. 실제 운영 DB 상태, credential, topology를 정적 CI가 확인했다고 표현하지 않는다.

관련 문서