pull request에서 생성된 Coroid는 사용자에게 표시되기 전에 검증 절차를 거칩니다. 이 섹션에서는 해당 검증의 의미와 설정 방법을 설명합니다.
검증 계층
검증은 단일 프로세스가 아닙니다. 각기 다른 질문에 답하는 네 개의 계층이 존재합니다.
귀사의 테스트 스위트가장 신뢰할 수 있는 신호로, 팀에서 중요하다고 판단한 기준을 이미 반영하고 있습니다. Coroid는 모든 작업마다 깨끗한 작업 공간에서 이를 실행합니다.
품질 게이트정책으로 정의된 검사 — 코드 커버리지, 린팅, 보안 스캔, 브라우저 테스트 및글로벌화 검사다국어 프로젝트용입니다. 차단형 게이트는 작업 진행을 중단시키고, 권고형 게이트는 결과를 기록한 뒤 작업을 계속 진행할 수 있게 합니다. 자세한 내용은품질 정책 및 게이트.
리뷰리뷰어 에이전트가 완성된 변경 사항을 분석하여 결과를 도출합니다. 수정 가능한 결과는 개발자에게 재작업 요청으로 전달되고, 나머지는 pull request에 첨부됩니다.
증거 자료미리보기 배포본, 스캔 결과 및 코드 커버리지 변화량이 pull request 자체에 첨부되어, 검증 정보가 코드와 함께 제공됩니다. 자세한 내용은리뷰 증거 자료.
- 테스트 스위트이 변경 사항이 기존 기능을 손상시키지 않나요?
- 품질 게이트정책에 명시된 표준을 준수하나요?
- 리뷰 과정신중한 검토자가 이 코드를 수용할까요?
- 증거 자료코드 옆에 증거가 첨부되어 있나요?
- 사용자 리뷰이것이 올바른 변경 사항인가요?
pull request가 생성되기 전에 모든 자동화된 단계가 먼저 실행되므로, 오류 발생 시 해당 작업이 재작업으로 반환됩니다.
검증이 증명하는 것과 증명하지 못하는 것
검증을 통해 해당 변경 사항이 의도한 대로 동작하고 기존 기능을 손상시키지 않으며, 설정한 표준을 준수함을 확인할 수 있습니다.
검증은해당 변경 사항이 반드시 구축해야 할 올바른 대상임을확인해주지는 않습니다. 이는명세서에 명시된 수락 기준과 리뷰 과정의 역할입니다.
모든 검증 단계를 통과했더라도 잘못된 변경 사항일 수 있습니다. 이러한 구분을 명확히 하는 것이 전체 시스템의 신뢰성을 유지하는 핵심이며, 검증 결과를 판단 근거로 오인하면 사람들은 더 이상 리뷰를 하지 않게 됩니다.
사전에 검증을 실행하는 이유
pull request가 생성되기 전에 모든 계층의 검증이 먼저 진행되므로, 오류는 최종적으로 거부될 pull request가 아니라 해당 실행 과정 내에서 재작업으로 반환됩니다.
작업 공간에서 오류가 발생하는 것이 화면에서 오류가 나타나는 것보다 비용이 적게 듭니다. 리뷰는 최초의인간검토가 되어야지, 최초의 확인이 아니어야 합니다.
시작 방법
처음으로 이 기능을 설정하는 경우:
- 테스트 스위트가 정상적으로 실행되는지 확인하세요 — 자세한 내용은 빌드 및 테스트 설정. 이 설정이 제대로 되지 않으면 다른 모든 항목은 의미가 없습니다.
- 조직 수준의 기본 정책을표준레벨에 설정하되, 가장 엄격한 수준은 피하세요.
- 이미 사용 중인 증거 제공 도구를 연동하세요.
- 게이트는 하나씩 추가하며, 우선 권고형 게이트부터 설정하세요.