피어 검토 CI/CD 도구 체인 체크인 관리

이 문서에서는 CI (Continuous Integration) 및 CD ( Continuous Delivery ) 도구 체인에서 선택적으로 피어 검토 검사를 사용 및 사용 안함으로 설정하는 방법에 대한 지시사항을 제공합니다.

중요한 사항

자원 명세가 업데이트되는 보호된 (기본) 분기에서만 피어 검토를 수행해야 합니다. 기능 분기에서 CI 파이프라인을 실행 중인 경우, 해당 특정 트리거에 대해 환경 변수 peer-review-compliance 를 0 로 설정하여 기능 분기에서 피어 검토 검사를 방지하십시오.

피어 검토 준수에 대한 준수는 성공적인 CI (Continuous Integration) 파이프라인 실행 및 재고에 대한 후속 항목의 완료에 달려 있습니다. 결과적으로 CI 파이프라인의 초기 실행은 피어 검토 준수 확인을 건너뜁니다.

피어 검토 표준을 준수하도록 하기 위해 ci-finish 단계에서 자원 명세 업데이트가 master 분기에서 발생한다고 가정합니다. 그러나 자원 명세 업데이트가 마스터가 아닌 다른 분기에서 수행되는 경우, 자원 명세 업데이트가 발생하는 분기를 표시하도록 환경 변수 inventory-repo-branch 를 설정할 수 있습니다.

지속적 배포(CD) 파이프라인에서는 인벤토리 저장소에 대한 모든 인벤토리 업데이트가 배포 중인 대상 브랜치로 승격되어 커밋이 누락되지 않도록 할 것으로 예상됩니다. 기본적으로 배포하는 동안 인벤토리 리포지토리는 대상 브랜치에 체크 아웃됩니다. 그러나 인벤토리 승격 대상 브랜치가 베이스 브랜치와 대상 브랜치 사이에 일부 커밋이 누락된 경우 inventory-repo-branch 환경 변수를 설정하여 모든 인벤토리 커밋이 있는 베이스 브랜치를 지정할 수 있습니다.

기본적으로 CI (Continuous Integration) 파이프라인은 애플리케이션 이름을 재고 항목으로 사용하여 실행 종료 시 재고 저장소에 대한 커미트를 자동으로 수행합니다. 그러나 릴리스 단계 중에 자원 명세 항목을 수정하려는 경우 inventory-entry-name 라는 환경 특성을 도구 체인에 통합하는 것이 좋습니다. 이 특성에는 피어 검토 프로세스에 대해 작업하기 위해 수정된 재고 이름이 포함되어야 합니다.

커밋을 보호된 브랜치에 직접 푸시하는 자동화가 있고 동료 검토 규정 준수 확인 문제를 피하려면 커밋 메시지에 ##AUTOMATED_COMMIT## 이 포함되어 있는지 확인하세요.

참조 구현은 동료 검토를 거치지 않은 코드의 인스턴스를 발견하고 증거를 수집하며 이러한 항목을 추적하기 위해 인시던트 이슈를 생성합니다.

마스터(보호된) 브랜치에서 코드를 병합하려면 먼저 수정된 코드를 업로드하지 않은 사람이 코드를 검토해야 합니다.

코드 저장소(리포지토리)에는 관리자 권한이 있는 멤버 한 명과 쓰기 권한이 있는 멤버 한 명 등 최소 두 명 이상의 멤버가 있어야 합니다. 코드를 검토 없이 저장소에 병합하면 코드 저장소 감사 추적에 조치가 표시되어야 합니다. 감사 추적을 주기적으로 스캔하여 이러한 예외 상황을 식별하고 분석하십시오.

파이프라인은 빌드 및 배포 중에 피어 리뷰 규정 준수 데이터를 수집하여 코드 풀/병합 요청부터 변경 요청에 이르기까지 감사 추적을 생성합니다.

이 다이어그램에서 PR1, PR2 는 병합 전에 승인되는 가져오기/병합 요청입니다. 마찬가지로 PR4, PR5및 PR7의 경우에도 마찬가지입니다. 그러나 빨간색으로 강조표시된 PR3 및 PR6은 피어 검토 준수 위반인 승인 없이 병합됩니다. 이는 증거로 캡처됩니다.

기본적으로 CI 도구 체인의 샘플 애플리케이션은 최소 검토자 수를 1로 설정하려고 시도합니다. 검토자 수를 변경하려면 필요에 따라 peer_review_approvers 환경 특성을 설정하십시오. 가져오기/병합 요청에 필요한 최소 검토자 수 설정에 대한 자세한 정보는 다음 GitHub 및 GitLab 자원을 참조하십시오.

• GitHub: 풀 리퀘스트에 여러 명의 검토자 필요
• GitLab: 병합 요청 승인 규칙

지속적 통합 빌드 실행에서 수집된 데이터

이 데이터 컬렉션에는 마지막 빌드 이후 앱 리포지토리에서 병합된 풀/병합 요청에 대한 모든 커밋 목록이 포함되어 있습니다.

가져오기 요청 데이터는 앱 저장소에서 직접 수집됩니다. 이전 빌드를 트리거한 리포지토리 커밋과 현재 사용 가능한 커밋 사이의 커밋과 관련된 각 풀/머지 요청에 대한 데이터가 수집됩니다.

풀/병합 요청을 포함하지 않는 커밋은 다음 파이프라인 릴리스에서 규정 준수 인시던트 이슈를 생성합니다. 마스터 브랜치에 직접 커밋할 수 없습니다.

준수 인시던트는 일반적으로 다음 정보를 보유합니다.

• 연관된 커미트 ID에 대한 가져오기/병합 요청 URL 목록입니다.
• 애플리케이션 저장소.
• 커미트 ID.
• 필수 승인 수입니다.

수집된 데이터는 증거 아티팩트로 저장되어 증거 보관함에 업로드된 후 증거물 자체에서 참조됩니다. 최종 증거 결과는 승인된 풀/병합 요청에 따라 결정됩니다. 승인되지 않았지만 병합된 풀/병합 요청은 이러한 유형의 증거에 실패합니다.

연속 배포 실행에서 수집되는 데이터

이 데이터 컬렉션에는 마지막 배포 이후 앱 리포지토리에서 병합된 모든 풀/병합 요청의 목록이 포함되어 있습니다.

풀 리퀘스트 데이터는 증거 보관함과 인시던트 이슈 리포지토리에서 수집됩니다.

• 인벤토리는 마지막 배치 이후 관련 아티팩트의 모든 빌드에서 데이터를 수집합니다.
• 증거 라커는 빌드에서 저장된 피어 검토 데이터를 수집합니다.
• 인시던트 이슈 리포지토리는 미결 풀/병합 요청 인시던트에 대한 정보를 수집합니다.

이 데이터 수집 중에는 앱 저장소에 액세스하지 않습니다. 연속 배포 파이프라인은 격리된 환경에 있다고 가정하므로 이러한 경계를 넘을 수 없습니다.

변경 요청 컨텐츠

다음 데이터는 자동으로 생성된 변경 요청에 포함됩니다.

• 해결되지 않은 풀/병합 요청 인시던트 목록입니다. 이 데이터에는 자산 세부 정보와 사건 발생 시점( URL )이 포함됩니다.

해결되지 않은 풀/병합 요청 인시던트는 변경 요청의 배포 준비 상태에 영향을 미칩니다. 가져오기/병합 요청 인시던트가 발견되면 취약성으로 간주되며 변경 요청 을 수동으로 검토하고 승인해야 합니다.

가져오기 요청 인시던트 수정

가져오기 요청 인시던트는 확인되지 않은 코드가 릴리스된 아티팩트에 포함되어 있음을 나타내므로 취약성으로 간주됩니다. 이러한 인시던트를 수정하려면 다음 단계를 완료하십시오.

1. 병합된 변경사항을 소급하여 검토하십시오.
2. 코드의 기존 문제점을 수정하는 방법에 대한 문제를 작성하십시오.
3. exempt 레이블을 추가하거나 가져오기/병합 요청 인시던트 문제를 닫으십시오.

끌어오기/병합 요청의 작성자와 끌어오기/병합 요청 이슈를 닫는 사람은 같은 사람이 될 수 없습니다.

문제점 해결

case 1:

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

알려진 문제

• 피어 검토 준수는 CI (Continuous Integration) 파이프라인의 각 반복 후에 릴리스 단계에서 재고 항목의 포함에 의존합니다. 실패한 CI 파이프라인 실행에 대한 재고 항목을 포함하기 위해 건너뛰면 Continuous Delivery 파이프라인에서 해당 특정 CI 파이프라인 실행에 대한 피어 검토 증거가 무시될 수 있습니다.