끌어오기 요청 유효성 검사 이해
끌어오기 요청을 사용하는 경우 다른 사용자가 Azure 배포에 대한 업데이트를 검토하도록 할 수 있습니다. 하지만 코드 변경 내용에서도 자동화된 검사를 실행하는 것이 도움이 되는 경우가 많습니다. 이 단원에서는 자동화된 끌어오기 요청 유효성 검사와 검사를 사용하여 코드 변경에 대한 팀의 신뢰를 높이는 방법을 알아봅니다.
끌어오기 요청 유효성 검사
Bicep 코드에 대한 끌어오기 요청을 검토할 때 변경 사항을 평가하기 위해 수행하는 몇 가지 일반적인 단계가 있을 수 있습니다. 이러한 단계에는 다음이 포함될 수 있습니다.
- Bicep 파일에 오류 또는 Linter 경고가 있는지 확인합니다.
- Bicep 파일에 이전에 정의된 리소스가 계속 작동하는지 확인합니다.
- 새로 정의된 리소스를 테스트하여 성공적으로 배포되었고 예상대로 작동하는지 확인합니다.
끌어오기 요청 유효성 검사에는 이러한 작업 중 일부를 자동화하는 것이 포함됩니다. 끌어오기 요청 검사를 자동화하면 검토자들이 코드가 팀의 품질 표준을 충족하고 비즈니스 목표를 달성하는지 확인하는 것과 같은 다윽 중요한 검토 단계에 시간을 할애할 수 있습니다.
GitHub Actions 워크플로에서는 끌어오기 요청 프로세스 중 특정 지점(예: 끌어오기 요청이 생성, 업데이트, 병합 또는 종료되는 지점)에 끌어오기 요청 프로세스 워크플로를 호출하는 트리거를 정의할 수 있습니다.
끌어오기 요청 유효성 검사 워크플로에서 Bicep 코드 테스트하기
이전 모듈에서는 예를 들어 여러 환경에서의 Azure 인프라 변경 내용을 린팅, 유효성 검사, 배포 및 테스트하기 위한 포괄적인 GitHub Actions 워크플로를 빌드하는 방법을 알아보았습니다. 이러한 워크플로는 변경 내용을 기본 분기에 병합한 후 실행됩니다.
끌어오기 요청 유효성 검사 워크플로에서 다수의 동일한 작업을 실행할 수도 있습니다. 예:
- Bicep 코드를 린팅하면 코드가 의미상 올바르고 권장되는 몇 가지 기준 Bicep 사례를 따르는지 확인하는 데 도움이 됩니다.
- 실행 전 유효성 검사를 사용하면 실제로 파일을 배포하지 않고도 코드가 성공적으로 배포될 것이라는 확신을 가질 수 있습니다. 실행 전 유효성 검사에서는 리소스 종류에 따라 잘못된 리소스 이름, 특정 리소스에 대한 잘못된 지역, 성공적으로 배포할 수 없는 구성을 지정했는지 여부와 같은 문제를 검사할 수 있습니다.
- 가상 작업은 배포의 결과로 Azure 환경이 변경된 내용을 나열합니다.
- 배포 작업은 실제로 리소스를 배포하고 배포 오류가 없는지 확인합니다.
- 배포 후 리소스를 테스트하여 비즈니스 요구 사항에 따라 리소스가 구성되었는지 확인합니다.
끌어오기 요청 유효성 검사 워크플로는 일반적인 GitHub Actions 워크플로이므로 이러한 작업을 실행할 수 있습니다. 그러나 끌어오기 요청 내에서 실행하는 것이 적합한 검사 유형에 대해 생각해 볼 가치가 있습니다. 위에 나열된 대부분의 유효성 검사 작업에는 Azure 환경에 대한 액세스 권한이 필요합니다. 예를 들어, 가상 작업은 Bicep 파일에 정의된 리소스를 Azure 구독의 리소스와 비교합니다. 프로덕션 환경에 대해 이 비교를 실행하는 것이 적절하다고 생각될 수 있지만, 아직 완료되거나 병합되지 않은 코드용으로 설계된 워크플로에서 프로덕션 환경에 대해 작업을 실행하는 것은 몇 가지 추가적인 위험이 초래될 수 있기 때문에 꺼려질 수 있습니다.
이 모듈에서는 끌어오기 요청 유효성 검사 워크플로에 다음과 같은 두 종류의 검사를 추가합니다.
- Bicep 코드를 린팅하여 코드에 대해 초기 검사 집합을 실행합니다.
- 새 임시 환경에 코드를 배포합니다.
이러한 두 작업을 할 때는 프로덕션 Azure 환경 또는 테스트, QA, 스테이징과 같은 일반적인 비프로덕션 환경에 연결할 필요가 없습니다. 이러한 두 작업을 실행하여 코드 변경 내용을 리포지토리의 기본 분기에 병합할 수 있도록 코드 변경 내용에 대한 신뢰도를 쌓을 수 있습니다.
검사는 작업을 수동으로 실행하는 데 소요되는 시간을 절약해 주기 때문에 검토자들에게 유용합니다. 또한 변경 내용이 배포 프로세스의 후반에 어떻게 작동하는지를 보여 주는 초기 보기를 가져오는 방법으로 이러한 검사를 사용할 수 있기 때문에 끌어오기 요청 작성자에게도 유용합니다.
고유한 끌어오기 요청 유효성 검사 워크플로에서 추가 작업으로 유효성 검사를 확장하도록 선택할 수 있습니다.
끌어오기 요청 수명 주기 트리거
GitHub의 끌어오기 요청은 다양한 수명 주기 이벤트를 거칠 수 있습니다. 예를 들어 끌어오기 요청이 열려 있을 때 작성자가 끌어오기 요청의 콘텐츠에 영향을 미치는 소스 분기에 변경 내용을 푸시(동기화)할 수 있습니다. 다음으로, 끌어오기 요청을 병합하거나, 병합하지 않고 닫거나, 나중에 다시 여는 것도 가능합니다.
GitHub Actions를 사용하면 이러한 이벤트에 응답하는 워크플로 트리거를 정의할 수 있습니다. 예를 들어 추가 구성 없이 pull_request 트리거를 지정하면 끌어오기 요청이 열리거나 동기화되거나 다시 열릴 때마다 자동으로 실행되는 워크플로를 정의할 수 있습니다.
on: pull_request
워크플로를 트리거하는 특정 끌어오기 요청 이벤트를 지정할 수도 있습니다. 예를 들어 끌어오기 요청이 닫힐 때마다 다음 워크플로가 자동으로 실행됩니다.
on:
pull_request:
types: [closed]
중요
끌어오기 요청에 병합 충돌이 있는 경우 워크플로가 실행되지 않습니다. 워크플로가 실행될 수 있도록 충돌을 해결하고 해결 내용을 푸시해야 합니다.
끌어오기 요청 상태 검사
끌어오기 요청 워크플로의 결과는 끌어오기 요청의 세부 정보 페이지에 검사로 표시됩니다. 검사를 사용하면 작성자와 검토자가 다음 예에서와 같이 자동화된 작업이 성공했는지 아니면 실패했는지에 대한 피드백을 신속하게 얻을 수 있습니다.
기본적으로 검사가 실패하더라도 끌어오기 요청을 병합할 수 있습니다. 이를 허용하지 않으려면 특정 검사가 성공해야 끌어오기 요청을 병합할 수 있도록 분기 보호 규칙을 구성할 수 있습니다.
파일 업데이트
끌어오기 요청이 만들어진 후에는 일반적으로 작성자가 업데이트를 수행해야 합니다. 예:
- 검토자가 작성자에게 코드를 변경할 것을 요청할 수도 있습니다.
- 자동화된 검사가 실패하면 작성자는 코드를 변경하여 문제를 해결한 다음 변경 내용을 커밋하고 푸시할 수 있습니다.
pull_request 트리거를 사용하면 소스 분기가 업데이트될 때마다 실행되도록 유효성 검사 워크플로를 구성할 수 있습니다. 워크플로의 최신 실행 결과는 끌어오기 요청의 세부 정보 페이지에 표시됩니다.
재사용 가능한 워크플로
끌어오기 요청 유효성 검사용에 사용할 수 있는 검사 목록을 살펴보면 일반적인 배포 워크플로에서 실행하는 것과 동일한 단계임을 알 수 있습니다. 반복을 방지하려면 GitHub의 재사용 가능한 워크플로를 사용하는 것이 좋습니다.
각 작업에 대해 여러 워크플로 정의에서 사용하는 재사용 가능한 워크플로를 정의할 수 있습니다. 다음 연습에서 이 작업을 수행하는 방법을 확인할 수 있습니다.
초안 끌어오기 요청
작성자는 보통 변경 내용을 검토, 승인 및 병합할 준비가 되면 끌어오기 요청을 엽니다. 그러나 변경 내용을 병합할 준비가 되지 않았더라도 코드 작성 프로세스 전반에 걸쳐 자동화된 끌어오기 요청 유효성 검사에 액세스할 수 있다면 도움이 될 수 있습니다.
GitHub에서 끌어오기 요청을 열면 요청을 초안으로 표시할 수 있습니다. GitHub은 동일한 자동화된 검사를 모두 실행하며, 검토자는 여전히 피드백을 제공할 수 있습니다. 그러나 끌어오기 요청이 초안 상태인 경우에는 작업이 아직 완전한 검토를 거칠 준비가 되지 않았으며 병합할 수 없다는 사실을 누구나 분명하게 알 수 있습니다.
끌어오기 요청 유효성 검사 워크플로에서 임시 환경을 만들 때 초안 끌어오기 요청을 만드는 것이 특히 일반적입니다. 라이브 작업 환경에서 변경 내용을 미리 볼 수 있기 때문입니다. 계속해서 변경 내용을 푸시하면 임시 환경이 최신 변경 내용을 통합하도록 업데이트됩니다.