실행 패브릭과 오케스트레이션
PR, main, nightly, release, canary, agent-repair 루프를 어떤 시간 예산과 증거 정책으로 운영할지 설명합니다.
핵심 요약
- 실행 패브릭은 "많이 돌리기"가 아니라, 의사결정마다 필요한 최소 세트를 제때 돌리는 데 달려 있습니다.
- pre-merge(5분)·main(10~15분)·nightly(30분+)·release·canary·agent-repair를 각각 목적과 시간 예산으로 분리합니다.
- shard는 파일 수가 아니라 평균 실행 시간 기준으로 균등화하고 suite 단위를 먼저 나눕니다.
- retry budget은 release gate 0(또는 승인된 1)처럼 차등 적용하되 retry로 flaky를 덮지 않습니다.
- evidence 보관은 PR 7일·main 14일·release 30일처럼 triage 가치와 저장 비용 사이에서 균형을 맞춰 정합니다.
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를 쓰는가?