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