Summary#
CI의 flaky test 격리는 실패를 무시하는 영구 설정이 아니라, 만료일과 복귀 판정이 있는 임시 예외로 운영해야 한다. 격리 중에도 테스트 결과를 수집해야 복귀 가능성과 실제 회귀 가능성을 판단할 수 있다. 다만 구현 방식은 다르다. CloudBees Smart Tests는 격리 테스트를 계속 실행하되 게이트 판정에서 제외하고, GitLab의 격리 방식은 해당 테스트를 CI에서 건너뛴다. 따라서 아래 절차는 특정 도구의 표준이 아닌 회귀 신호 보존을 우선하는 운영 초안이다. (docs.cloudbees.com)
Key Points#
- 격리 등록 게이트: 테스트 식별자, 실패 이슈와 로그, 담당자, 격리 사유, 시작일·만료일, 영향을 받는 기능을 한곳에 기록한다. GitLab은 격리 전 관련 이슈와 실패 파이프라인·패턴을 요구하고, 담당 팀의 진행 상황을 추적한다. (handbook.gitlab.com)
- 판정과 관측을 분리: 정상 테스트의 실패는 계속 CI를 막는다. 격리 테스트는 가능하면 별도 비차단 실행에서 매번 돌리고, 최초 실패·재시도 결과·실패율·연속 실패를 보고한다. CloudBees와 Selective는 격리 중에도 실행·보고하면서 빌드 판정에서만 제외하는 방식을 문서화한다. (docs.cloudbees.com)
- 만료 시 명시적 결정: 만료일에 자동 연장하지 말고 담당자가 수정 후 복귀, 근거와 새 기한을 명시한 연장, 또는 동등한 커버리지 확보 후 제거 중 하나를 검토한다. GitLab의 빠른 격리 최대 3일·장기 격리 최대 3개월은 해당 조직의 정책 사례이지 범용 권장 기한은 아니다. (handbook.gitlab.com)
- 복귀 게이트: 원인과 수정 근거, 반복 실행 결과, 격리 이슈를 연결한 변경 검토를 요구한다. 복귀 뒤에도 일정 기간 실패를 감시하고 재발 시 재격리·재조사한다. GitLab은 복귀 조건으로 원인 수정과 100회를 넘는 로컬 통과, 복귀 후 1주 감시를 명시한다. 이 횟수 역시 각 팀의 위험도에 맞춰 정할 사례값이다. (handbook.gitlab.com)
- 회귀 신호의 예외 처리: 격리 테스트가 계속 실패하거나 실패 양상이 바뀌면 단순한 ‘기존 flake’로 묶지 말고 제품 결함 가능성을 다시 판정한다. 재시도에서 통과한 사건과 재시도에서도 실패한 사건을 구분해 기록하는 방식이 이 검토에 유용하다. (docs.cloudbees.com)
Cautions#
- 격리 테스트가 실행되지 않는 방식에서는 결과 추세를 근거로 복귀를 판정할 수 없다. 이 경우 별도 실행 경로를 마련하거나, 관측 공백을 명시해야 한다. GitLab의 기본 CI 격리와 CloudBees의 실행 유지 방식은 동일하지 않다. (docs.gitlab.com)
- 반복 통과만으로 원인 수정이나 회귀 부재가 증명되지는 않는다. 실패율 임계값·필요 실행 횟수·기한은 공개 자료에서 공통 표준으로 확인되지 않았으므로 이 초안에서는 고정하지 않는다. (handbook.gitlab.com)
- 이 초안은 공개 문서에 근거한 운영 제안이며, 특정 조직의 CI 구성이나 격리 목록에 실제로 적용·검증된 정책은 아니다.
Sources#
- GitLab Handbook — Test Quarantine Process
- GitLab Docs — Quarantining tests
- CloudBees Docs — High failure rate tests and quarantine
- Selective Docs — Flakes and retries
Sagwan Revalidation 2026-10-16T03:52:56Z#
- verdict:
ok - note: 도구별 격리 방식과 정책 사례를 구분했고, 운영 권고도 여전히 재사용 가능하다.
Sagwan Revalidation 2026-10-18T23:26:26Z#
- verdict:
ok - note: 도구별 격리 방식과 조직별 정책을 구분했으며, 운영 권고도 재사용 가능하다.