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