Bicep 변경 내용 검토 및 병합
기능 분기를 사용하는 방법과 변경 내용이 병합되기 전에 검토되도록 분기 보호를 적용하는 방법을 알아보았습니다. 이제 변경 내용이 병합되기 전에 일관된 프로세스를 따라 변경 내용을 제안하고 검토해야 합니다.
이 단원에서는 끌어오기 요청을 만들고 사용하는 방법을 포함하여 끌어오기 요청에 대해 자세히 알아봅니다. 끌어오기 요청을 사용하여 Bicep 코드를 검토하는 방법도 알아봅니다.
끌어오기 요청
끌어오기 요청은 기능 개발자가 기본 분기의 유지 관리자에게 하는 요청입니다. 유지 관리자에게 변경 내용을 리포지토리의 기본 분기로 풀하도록 요청합니다.
끌어오기 요청 및 분기 보호
분기 보호를 구성할 때 코드 소유자에게 끌어오기 요청을 검토하도록 요구할 수 있습니다. 예를 들어, 프로젝트 리더를 모든 끌어오기 요청의 검토자로 포함하거나 특정 수의 사람들이 모든 끌어오기 요청을 검토하도록 지정할 수 있습니다.
끌어오기 요청 및 분기 정책
분기 정책을 구성할 때 특정 사용자 또는 사용자 그룹이 끌어오기 요청을 검토하도록 요구할 수 있습니다. 예를 들어, 프로젝트 리더를 모든 끌어오기 요청의 검토자로 포함하거나 특정 수의 사람들이 모든 끌어오기 요청을 검토하도록 지정할 수 있습니다.
각 끌어오기 요청이 작업 항목에 연결되도록 요구할 수도 있습니다. 이 구성을 사용하면 기능 요청이 포함된 작업 항목에서 변경 내용을 구현하는 코드, 프로덕션 환경에 대한 배포까지 전부 추적할 수 있습니다.
끌어오기 요청 만들기
GitHub 웹 인터페이스를 사용하여 끌어오기 요청을 만들 수 있습니다. 변경을 수행한 소스 분기와 일반적으로 리포지토리의 기본 분기인 대상 분기를 선택합니다.
Azure DevOps 웹 인터페이스를 사용하여 끌어오기 요청을 만들 수 있습니다. 변경을 수행한 소스 분기와 일반적으로 리포지토리의 기본 분기인 대상 분기를 선택합니다.
끌어오기 요청을 만들 때 이름을 지정해야 합니다. 끌어오기 요청 이름을 명확하고 이해하기 쉽게 만드는 것이 좋습니다. 그러면 팀 구성원이 검토 요청의 컨텍스트를 이해하는 데 도움이 됩니다. 팀 구성원마다 전문 분야가 다른 경우 좋은 이름은 팀 구성원이 의미 있는 피드백을 제공할 수 있는 끌어오기 요청을 파악하고 관련이 없는 끌어오기 요청을 건너뛰는 데 도움이 됩니다.
또한 끌어오기 요청 이름은 종종 Git 리포지토리 기록의 일부가 되므로 누군가가 기록을 되돌아볼 때 이해할 수 있도록 만드는 것이 좋습니다.
끌어오기 요청에 설명을 제공할 수도 있습니다. 설명에서 특정 사용자를 언급하거나 문제를 참조할 수 있습니다. 많은 팀에서 각 변경 내용이 명확히 기술되도록 끌어오기 요청 설명을 위한 표준화된 템플릿을 만듭니다.
끌어오기 요청에 설명을 제공할 수도 있습니다. 설명에서 특정 사용자를 언급하거나 작업 항목을 참조할 수 있습니다. 많은 팀에서 각 변경 내용이 명확히 기술되도록 끌어오기 요청 설명을 위한 표준화된 템플릿을 만듭니다.
끌어오기 요청을 만들 때 변경 내용을 검토할 사용자를 초대할 수 있습니다.
동료로부터 피드백을 받기 위해 끌어오기 요청을 만드는 경우도 있습니다. 이러한 경우 끌어오기 요청이 초안임을 지정할 수 있습니다. 검토자는 변경 내용이 아직 작업 중임을 알 수 있습니다. 검토자는 여전히 피드백을 제공할 수 있지만 변경 내용이 아직 병합될 준비가 되지 않은 것은 분명합니다. 변경 내용에 만족하면 초안 상태를 제거할 수 있습니다.
끌어오기 요청을 만든 후에도 기능 분기의 코드를 계속 변경할 수 있습니다. 이러한 변경 내용은 끌어오기 요청의 일부가 됩니다.
끌어오기 요청 검토
끌어오기 요청을 검토할 때 모든 변경 내용을 볼 수 있습니다. 전체 끌어오기 요청 또는 파일에서 변경된 특정 부분에 대해 주석을 달 수 있습니다. 끌어오기 요청 작성자는 주석에 응답할 수 있으며 다른 검토자는 토론에 참여할 수 있습니다. 이러한 주석 달기 기능은 끌어오기 요청에 대한 공동 작업을 대화형 환경으로 만듭니다.
Bicep 코드를 검토할 때 다음과 같은 주요 요소를 찾습니다.
- 파일이 배포 가능한가요? Bicep 코드를 병합 전에 배포하고 테스트합니다. Linter 경고가 없고 Azure 배포가 성공하는지 확인합니다. 향후의 Microsoft Learn 모듈에서는 변경 내용을 자동으로 배포하고 확인하는 방법에 대해 알아봅니다.
- Bicep 코드가 명확하고 이해할 수 있나요? 팀의 모든 구성원이 Bicep 코드를 이해하는 것이 중요합니다. 끌어오기 요청에서 Bicep 파일을 검토할 때 모든 변경 내용의 의도를 정확히 이해해야 합니다. 변수 및 매개 변수가 잘 명명되었나요? 코드의 복잡한 섹션을 설명하는 데 주석이 사용되었나요?
- 변경 내용이 완성된 상태인가요? 이 끌어오기 요청이 더 광범위한 작업의 일부인 경우 이 변경 내용이 병합 및 배포될 때 사용자 환경이 작동하는지 확인합니다. 예를 들어 끌어오기 요청이 이후 변경에 대비하여 Azure 리소스를 다시 구성하는 경우 리소스가 전체 프로세스에서 계속 올바로 작동하는지 확인합니다. 끌어오기 요청이 아직 필요하지 않은 새 Azure 리소스를 추가하는 경우 리소스가 필요할 때까지는 배포되지 않도록 조건을 일시적으로 추가해야 하는지 여부를 고려합니다.
- 변경 내용이 Bicep 모범 사례를 따르나요? 다른 Microsoft Learn 모듈에서 좋은 Bicep 코드의 요소에 대해 알아보았습니다. 검토하는 코드가 동일한 모범 사례를 따르는지 확인합니다.
- 변경 내용이 설명과 일치하나요? 끌어오기 요청에 설명하는 제목을 포함하는 것이 좋습니다. 또한 많은 팀에서 끌어오기 요청에 변경 내용 및 그 용도에 대한 설명을 포함하도록 요구합니다. Bicep 코드의 변경 내용이 끌어오기 요청 세부 정보와 일치하는지 확인합니다. 끌어오기 요청 작성자가 작업 항목 또는 문제에 연결된 경우 끌어오기 요청의 변경 내용이 작업 항목에 정의된 성공 조건을 충족하는지 확인합니다.
끌어오기 요청 완료
끌어오기 요청이 승인되면 완료할 수 있습니다. 즉, 끌어오기 요청의 내용이 기본 분기에 병합됩니다.
일부 팀에서는 끌어오기 요청 작성자도 이를 완료해야 합니다. 이 프로세스를 통해 작성자가 병합 시기를 제어하고 자동화된 배포를 모니터링할 수 있습니다. 다른 팀에서는 승인자가 끌어오기 요청을 완료합니다. 팀에서 끌어오기 요청을 병합하는 담당자와 시기를 결정해야 합니다.
일부 팀에서는 끌어오기 요청 작성자도 이를 완료해야 합니다. 이 프로세스를 통해 작성자가 병합 시기를 제어하고 자동화된 배포를 모니터링할 수 있습니다. 다른 팀에서는 승인자가 끌어오기 요청을 완료합니다. Azure DevOps를 사용하여 승인 조건을 충족하는 끌어오기 요청을 자동으로 완료할 수도 있습니다. 팀에서 끌어오기 요청을 병합하는 담당자와 시기를 결정해야 합니다.
팀의 프로세스
기능 분기 및 끌어오기 요청을 사용하기 시작하면 팀의 프로세스가 다음과 같이 변경될 수 있습니다.
팀 구성원이 공유 리포지토리를 복제합니다.
리포지토리의 자체 로컬 복사본에 있는 분기에서 로컬 변경을 수행합니다.
변경 내용이 완성되면 공유 리포지토리에 로컬 분기를 푸시합니다.
공유 리포지토리 내에서 분기를 main에 병합하는 끌어오기 요청을 만듭니다.
다른 팀 구성원이 변경 내용을 검토합니다. 변경 내용이 만족스러우면 끌어오기 요청을 승인합니다. 그러면 공유 리포지토리의 기본 분기에 병합됩니다.
공유 리포지토리 및 리포지토리의 로컬 복사본에서 분기를 삭제합니다.
일부 시나리오에서는 원격 리포지토리의 푸시가 자동화된 파이프라인을 트리거하여 코드를 확인, 테스트, 배포합니다. 다른 Microsoft Learn 모듈의 파이프라인에 대해 자세히 알아봅니다.
다음 다이어그램은 이 수정된 프로세스를 보여 줍니다.
