기업 전반에서 지원이 이루어지는 방식
Code Quality 는 세 가지 수준에서 제어되므로 조직 및 리포지토리에 제공할 자율성을 결정할 수 있습니다.
- 엔터프라이즈: 엔터프라이즈 소유자는 먼저 Code Quality을 엔터프라이즈에 대해 허용해야 합니다. 이렇게 하기 전까지는 조직 소유자가 사용하도록 설정할 수 없습니다.
- 조직: 조직 소유자는 모든 리포지토리, 선택한 목록 또는 필터와 일치하는 리포지토리에 대한 액세스 권한을 부여하여 Code Quality를 활성화하거나 비활성화할 리포지토리를 제어합니다. 리포지토리 관리자가 변경할 수 없도록 이러한 설정을 적용할 수도 있습니다.
- 리포지토리: 리포지토리 관리자는 조직 수준 적용이 적용되지 않는 한 개별 리포지토리에 대해 사용하거나 사용하지 않도록 설정할 Code Quality 수 있습니다.
리포지토리에서 Code Quality가 활성화되면 CodeQL 분석이 GitHub Actions를 통해 실행되며, 풀 리퀘스트와 기본 브랜치에 결과가 표시됩니다. 개발자는 끌어오기 요청에 대한 품질 검사 및 주석을 봅니다.
조직 수준 리포지토리 액세스
조직 수준에서 단일 Code Quality 설정을 사용하여 제어 **** 합니다. 이 설정은 어떤 리포지토리에서 Code Quality를 활성화하고 어떤 리포지토리에서 비활성화할지를 결정합니다. 즉, 선택한 리포지토리 내의 리포지토리에서는 활성화되고, 선택한 리포지토리 밖의 리포지토리에서는 비활성화됩니다.
중요
리포지토리 액세스 설정을 변경하면 여러 리포지토리에서 한 번에 사용하거나 사용하지 않도록 설정할 Code Quality 수 있습니다. 예를 들어 필터와 일치하는 리포지토리를 사용하도록 설정 Code Quality 하면 필터와 일치하지 않는 리포지토리가 비활성화됩니다. 변경 내용을 적용하기 전에 대화 상자에는 총 사용 및 사용 안 함 리포지토리 수와 청구 영향이 표시됩니다.
리포지토리 액세스 옵션
한 번에 다음 옵션 중 하나를 적용할 수 있습니다.
| Option | 작동 방식 |
|---|---|
| 리포지토리 없음 | |
| Code Quality 조직의 모든 현재 및 향후 리포지토리에 대해 사용하지 않도록 설정합니다. | |
| 리포지토리가 결정하도록 허용 | 조직은 Code Quality를 사용 또는 사용 안 함으로 설정하지 않습니다. 리포지토리 관리자는 자체 리포지토리에 사용하도록 설정할지 여부를 선택합니다. 이 옵션은 적용할 수 없습니다. |
| 모든 리포지토리 | |
| Code Quality 모든 현재 및 미래의 리포지토리에 사용할 수 있습니다. | |
| 선택한 리포지토리 | |
| Code Quality 선택한 리포지토리의 특정 목록을 사용하도록 설정합니다. 선택하지 않은 리포지토리는 사용하지 않도록 설정되고 새 리포지토리는 자동으로 사용하도록 설정되지 않습니다. 파일럿 또는 예외 사례에 가장 적합합니다. | |
| 필터 일치 | |
| Code Quality 현재 및 나중에 정의한 필터와 일치하는 리포지토리를 사용하도록 설정합니다. 일치하지 않는 리포지토리는 사용할 수 없습니다. | |
| 리포지토리 필터링을 참조하세요. |
리포지토리 필터링
필터 일치를 선택하면 조건과 일치하는 기존 및 이후 리포지토리를 자동으로 사용하도록 설정하는 Code Quality 동적 필터를 만듭니다. 이는 대규모로 진행 중인 거버넌스에 유용합니다.
다음 조건의 조합을 필터링할 수 있습니다.
- 가시성: 리포지토리가 퍼블릭, 프라이빗 또는 내부인지 여부입니다. 모든 프라이빗 리포지토리에 대해 사용하도록 설정하는 Code Quality 등 광범위한 정책에 유용합니다.
- 포크 상태: 리포지토리가 포크인지 여부입니다. 포크가 분석 리소스를 소모하지 않아야 하는 경우에 유용합니다.
- 사용자 지정 속성: 리포지토리에 특정 사용자 지정 속성 값이 있는지 여부입니다. 예를 들어 속성을 사용하여 리포지토리를 대상으로 지정할 수 있습니다
team:platform.
필터의 모든 조건은 AND로 결합되므로, 리포지토리가 사용 설정되려면 모든 조건과 일치해야 합니다. 특정 조건과 일치하는 리포지토리를 제외할 수도 있습니다.
액세스 강제 적용
기본적으로 리포지토리 관리자는 자체 리포지토리에 대한 설정을 변경할 Code Quality 수 있습니다. 이를 방지하려면 액세스 적용을 사용하도록 설정합니다.
리포지토리 액세스 옵션에서 설정한 사용 상태와 비활성화 상태 모두에서 적용 잠금을 적용하므로 리포지토리 관리자는 이를 재정의할 수 없습니다. 이렇게 하면 조직 전체의 일관성이 향상되지만 개별 리포지토리 관리자의 유연성이 줄어듭니다.
- 적용은 리포지토리 액세스에 대해 선택하는 대부분의 옵션에 적용되며, 여기에는 **** 를 사용 안 함으로 강제하는 Code Quality도 포함됩니다.
- 리포지토리에서 결정에서는 강제 적용을 사용할 수 없습니다. 이 옵션은 의도적으로 선택 권한을 리포지토리 관리자에게 맡깁니다.
출시 계획 수립
단일 리포지토리 액세스 설정 변경으로 여러 리포지토리에서 Code Quality를 한 번에 활성화할 수 있고, 각 분석에 GitHub Actions분이 소요되므로 한꺼번에 적용하기보다 단계적으로 적용하는 것이 좋습니다. 계획할 때 몇 가지 사항을 계량합니다.
- 비용 및 용량. GitHub Actions를 광범위하게 활성화하기 전에 러너가 추가 Code Quality 부하를 흡수할 수 있는지 확인하세요.
- 얼마나 적용할지. 적용은 일관된 범위를 제공하고 리포지토리 관리자의 옵트아웃을 중지하지만 유연성을 제거합니다. 이를 해제하면 팀이 자신의 타임라인에 옵트인할 수 있습니다.
- 확장할 시기입니다. 소규모의 대표적인 파일럿 그룹으로 시작하여 분석이 원활하게 실행되고 개발자가 결과를 신뢰하는지 확인한 다음 선택 영역 또는 필터를 확장하여 더 많은 리포지토리를 다룹니다.
품질 임계값을 적용하기 전에 평가 모드에서 파일럿하는 등 단계별 롤아웃 절차는 GitHub Code Quality 대규모 배포하기을 참조하세요.