실행 패브릭과 오케스트레이션
PR, main, nightly, release, canary, agent-repair 루프를 어떤 시간 예산과 증거 정책으로 운영할지 설명합니다.
좋은 probe도 실행 패브릭이 나쁘면 조직 전체의 병목이 됩니다. 핵심은 "최대한 많이 돌리기"가 아니라, 의사결정마다 필요한 최소 세트를 적시에 돌리는 것입니다.
기본 파이프라인 구분
| 파이프라인 | 목적 | 실행 probe | 기준 |
|---|---|---|---|
pre-merge | PR 병합 보호 | smoke subset | 5분 이내 |
main | trunk 안정성 확인 | smoke + critical 일부 | 10~15분 |
nightly | 넓은 회귀 탐지 | full + cross-browser + workflow | 30분 이상 허용 |
release | 배포 승인 | smoke + critical 전체 + release probes | blocker 엄격 |
canary | 실제 환경 확인 | production-safe probes | rollback 판단 연결 |
agent-repair | 실패 관련 subset 재실행 | 영향 범위 기반 targeted probe | 사람 승인 전 증거 수집 |
shard 전략
- shard는 suite 단위로 먼저 나누고, 브라우저/locale/device 축은 두 번째로 나눕니다.
- 파일 수가 아니라 평균 실행 시간 기준으로 shard를 균등화합니다.
- 오래 걸리는 spec이나 workflow probe는 별도 bucket으로 분리합니다.
- agent-repair는 전체 rerun 대신 실패 분류와 변경 파일 기준 subset 실행을 우선합니다.
브라우저 러너 예시
Playwright를 브라우저 runner로 쓴다면 오케스트레이션은 이런 식으로 구현할 수 있습니다.
name: e2e-critical
on:
workflow_dispatch:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shard: [1/4, 2/4, 3/4, 4/4]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test --grep @critical --shard=${{ matrix.shard }}retry budget
| 실행 맥락 | retry | 이유 |
|---|---|---|
| local sandbox | 0 | 근본 원인 즉시 확인 |
| PR gate | 0~1 | gate 신뢰 유지 |
| main | 1 | 일시적 인프라 noise 흡수 |
| nightly | 1~2 | 넓은 coverage 확보 |
| release gate | 0 또는 승인된 1 | false pass 방지 |
| agent-repair | 0 | 수정 효과를 명확히 보기 위함 |
retry는 품질 대체제가 아닙니다
retry는 flaky를 가리는 도구가 아니라 transient failure를 분리하는 최소 안전장치여야 합니다.
worker와 시간 예산
- worker는 CPU 수보다 환경 안정성과 계정 경쟁 한도를 먼저 봅니다.
- rate limit, sandbox quota, shared integration 충돌이 큰 시스템은 worker를 낮춰야 합니다.
smoke는 5분,critical은 15분,full은 60분 안팎을 운영 목표로 둡니다.- agent-repair는 10분 안에 원인 축소 증거를 내는 것이 목표입니다.
evidence retention 정책
| 상황 | evidence | 보관 기간 |
|---|---|---|
| PR 실패 | trace, screenshot | 7일 |
| main 실패 | trace, screenshot, logs | 14일 |
| release 실패 | full evidence bundle | 30일 또는 release 종료 시 |
| canary 실패 | prod-safe probe 증거 + metric snapshot | incident 종료 시까지 |
비용 제어 팁
- cross-browser는 nightly 중심으로 이동
- video는 failure retain only
- prod-like 환경은 release gate와 rehearsal에 집중
- agent-repair는 full rerun 대신 impact analysis와 분류 결과를 활용
오케스트레이션 리뷰 질문
- 지금 각 pipeline이 어떤 의사결정을 돕는지 한 줄로 설명 가능한가?
- targeted rerun 없이 실패 때마다 full suite를 다시 돌리고 있지 않은가?
- evidence retention이 triage 가치와 저장 비용 사이에서 균형을 갖는가?
- canary probe와 release gate probe가 같은 blocker vocabulary를 쓰는가?