검토를 위한 임시 환경 배포
Bicep 코드를 린팅하면 Azure 배포가 성공할지 여부를 알 수 있습니다. Bicep 코드를 실제로 어딘가에 배포해 보면 끌어오기 요청의 병합 및 배포가 완료된 후에 환경이 어떻게 되는지 확인해 볼 수 있습니다.
이 단원에서는 끌어오기 요청 내에서 임시 환경에 코드를 배포하는 방법을 알아봅니다.
끌어오기 요청 내에서 코드를 배포하는 이유는 무엇인가요?
Bicep 코드가 포함된 끌어오기 요청을 검토할 때는 실제 Azure 환경에 Bicep 코드를 배포하는 것이 좋습니다. 이렇게 하면 변경 내용이 프로덕션 환경에 도달했을 때 문제없이 작동할 것임을 확인할 수 있습니다. 문제가 있는 경우 빠르게 알아볼 수 있어야 합니다. 끌어오기 요청을 사용하면 검토자로부터 즉각적인 피드백을 받게 되기 때문에 문제를 발견하고 강조 표시할 수 있습니다.
이제 여러분은 변경 내용을 프로덕션 환경에 배포하기 전에 테스트, QA, 스테이징과 같은 하나 이상의 비프로덕션 환경에 배포한다는 개념에 익숙해졌습니다. 많은 조직에서 이러한 환경은 긴 수명을 갖습니다. 즉, 변경 내용이 롤아웃되면 환경이 업데이트되고 일반적으로 환경이 삭제되지 않습니다.
반면에 임시 환경은 사용자가 동적으로 만드는 환경으로, 더 이상 유용하지 않을 때는 삭제해도 문제가 없습니다. 임시 환경은 짧은 시간 동안만 존재하는 용도입니다(예: 변경 내용을 검토하는 동안만 존재).
다양한 유형의 변경 내용을 나타내는 별도의 끌어오기 요청이 한 번에 많이 열려 있을 수 있기 때문에 끌어오기 요청에 대한 환경을 배포할 때 임시 환경은 좋은 선택입니다. 끌어오기 요청이 여러 개 열려 있는 경우 장기간 지속되는 개발 및 테스팅 환경을 공유한다는 것은 한 번에 하나의 변경 내용만 미리 볼 수 있음을 의미합니다.
임시 환경 만들기
Azure 코드 제공 인프라를 빌드하는 데 익숙하고 리소스를 배포하기 위해 Bicep 파일을 빌드하는 데 투자했기 때문에 동일한 자산을 다시 사용하여 임시 환경을 배포할 수 있습니다. 필요한 경우 한 번에 여러 임시 환경을 배포할 수도 있습니다. 독립 환경을 쉽게 만들 수 있도록 배포가 충분히 매개 변수화되고 일반화되었는지 확인해야 합니다. 예를 들어 일부 Azure 리소스에 전역적으로 고유한 이름이 지정되었는지(다른 임시 환경이나 수명이 긴 환경에서 리소스 이름과 동일할 수 없음) 확인해야 합니다.
임시 환경은 다음과 같은 많은 이점을 제공합니다.
- 다른 프로덕션 워크로드나 비프로덕션 워크로드에 영향을 주지 않는 격리된 환경에서 새로운 기능을 안전하게 테스트할 수 있습니다.
- 자신의 분기에 변경 내용을 표시하여 동료에게 작업을 보여 주거나 검토자에게 액세스 권한을 제공할 수 있습니다.
- 변경 내용이 서로 호환되지 않더라도 여러 팀 구성원이 여러 가지 변경 내용을 동시에 테스트할 수 있습니다.
- 임시 환경은 Bicep 파일을 정기적으로 실행하므로 Bicep 코드 및 기타 스크립트의 정확도와 완성도를 지속적으로 테스트하는 데 도움이 됩니다. 따라서 코드가 프로덕션 환경에서 완벽하게 실행될 것이라는 확신을 가질 수 있습니다.
이 모듈에서는 끌어오기 요청 내의 변경 내용에 대한 신뢰를 구축할 수 있도록 임시 환경을 만듭니다. 끌어오기 요청을 검토하는 모든 사용자는 끌어오기 요청을 승인하고 병합하기 전에 임시 환경과 새로운 추가 내용 및 업데이트에 액세스할 수 있습니다.
배포
임시 환경에서 작업할 때는 팀에서 만드는 각 끌어오기 요청에 대해 별도의 Azure 리소스 그룹을 만드는 것이 가장 좋습니다. 한 작성자가 두 개의 개별 끌어오기 요청을 여는 경우 각 끌어오기 요청에는 고유한 임시 환경이 있습니다. 따라서 각 변경 내용이 다른 변경 내용과 분리된 상태로 유지되며, 실수로 리소스를 덮어쓰는 일과 혼동을 방지할 수 있습니다.
이 접근 방식이 작동하려면 끌어오기 요청 유효성 검사 워크플로에서 동적으로 리소스 그룹을 만들어야 합니다. 리소스 그룹의 이름은 고유해야 하며, 리소스를 테스트하고 끌어오기 요청이 닫히면 삭제할 수 있도록 리소스 그룹을 쉽게 찾을 수 있어야 합니다. 리소스 그룹 이름을 효과적으로 처리하려면 리소스 그룹 이름 내에 끌어오기 요청 번호를 사용할 수 있습니다. 다음 연습에서 이 작업을 수행하는 방법을 확인할 수 있습니다.
임시 환경을 삭제해야 하는 경우 워크플로에서 쉽게 찾아서 전체 리소스 그룹을 삭제할 수 있습니다. 임시 환경에서 사용되는 모든 리소스가 동시에 삭제됩니다.
사용 권한
리소스 그룹을 만들려면 구독 수준 권한이 필요하며, 일반적으로 워크플로의 워크로드 ID에 Contributor 역할을 할당해야 합니다.
임시 환경에 전용 Azure 구독을 사용하는 것이 좋습니다. 이 접근 방식을 따르면 워크플로의 워크로드 ID에 대한 액세스를 부여할 수 있고 실수로 다른 환경에 대한 액세스를 제공하지 않으면서도 팀 구성원에게 액세스를 부여할 수 있습니다.
중요
구독 범위 기여자는 강력하므로 워크플로의 작업 ID 및 배포할 수 있는 변경 사항에 대한 적절한 거버넌스가 있는지 확인해야 합니다. 임시 환경에 전용 구독을 사용하면 다른 환경에 대한 위험이 줄어듭니다.
워크플로의 ID
배포 워크플로는 작업 ID 및 페더레이션 자격 증명을 사용하여 Azure에 인증합니다. 끌어오기 요청 유효성 검사 워크플로를 사용하는 경우 끌어오기 요청에 대해 작동하도록 페더레이션 자격 증명을 구성해야 합니다.
이 모듈의 이전 연습에서는 명령을 실행하여 페더레이션 자격 증명을 만듭니다. 정책 문자열은 다음과 유사합니다.
repo:my-github-user/my-repo:pull_request
문자열의 끝 부분에 있는 pull_request는 페더레이션 자격 증명이 끌어오기 요청 유효성 검사 워크플로와 함께 작동 하도록 지정합니다.
비용 관리
임시 환경을 동적으로 만들면 Azure 비용이 증가할 가능성이 있습니다. 팀에게 다수의 끌어오기 요청이 열려 있는 경우 많은 비용이 드는 다수의 리소스를 Azure에 배포할 수 있습니다.
팁
팀에서 끌어오기 요청을 빠르게 닫는 경우, 끌어오기 요청이 닫히면 해당 임시 환경이 삭제되기 때문에 비용 증가 가능성이 비교적 문제가 되지 않습니다.
전용 Azure 구독을 사용하면 임시 환경의 비용을 쉽게 모니터링할 수도 있습니다. 또한 임시 리소스의 SKU를 제한하는 구독 전체 정책을 적용하여 과도한 비용 발생을 방지할 수 있습니다.
Azure는 임시 환경의 비용을 제어하는 데 도움이 되는 다음과 같은 여러 가지 방법을 제공합니다.
- Microsoft Cost Management를 사용하면 구독의 예산을 설정할 수 있습니다. 예산을 설정하면 비용이 지정한 임계값에 근접하고 있음을 팀이 인지할 수 있도록 알림이 트리거됩니다.
- 다양한 Azure 리소스 종류는 비프로덕션 워크로드에 대해 더 저렴한 계층이나 무료 계층을 제공합니다. 이러한 가격 책정 계층 및 SKU를 사용할 수 있는지 여부를 고려하세요.
- Azure 개발/테스트 가격은 일부 고객이 비프로덕션 구독에 사용할 수 있습니다.
- 리소스 태그는 각 임시 환경에 연결된 리소스를 식별하고 각 임시 환경의 비용을 계산하는 데 도움이 될 수 있습니다.
- 정의된 기간 후에(예: 매일 업무 시간이 끝난 후에) 임시 리소스를 삭제하는 자동화 스크립트를 만들 수 있습니다.
임시 환경 간에 특정 리소스를 공유하는 것도 고려할 수 있습니다. 예를 들어 Bicep 코드는 많은 리소스를 정의할 수 있으며, 그중 일부는 비용이 많이 들거나 프로비저닝하는 데 시간이 오래 걸립니다. 모든 끌어오기 요청에 대해 수명이 긴 단일 공유 리소스 그룹을 만들어 비용이 많이 드는 리소스를 공유하고, 그 밖의 리소스용으로는 별도의 임시 리소스 그룹을 만들 수 있습니다. 그러나 이 방법을 사용하면 임시 환경을 관리하고 검토 프로세스에 도움이 될 만큼 분리된 상태로 유지하는 것이 까다로우며 오류가 발생하기 쉽습니다. 임시 환경의 비용이 너무 높아지지 않는다면 이 접근 방식을 피하는 것이 가장 좋습니다.