GitHub 환경을 사용하여 배포 제어
팁 (조언)
자세한 내용은 텍스트 및 이미지 탭을 참조하세요.
Proseware는 모델 배포를 자동화하지만 팀은 모든 성공적인 워크플로 실행이 프로덕션 트래픽을 즉시 변경하는 것을 원하지 않습니다. 자동화된 테스트는 먼저 배포를 확인해야 합니다. 그런 다음 검토자는 증거가 승격을 지원하는지 여부를 결정해야 합니다.
배포 단계 표시
GitHub 환경은 리포지토리의 명명된 배포 대상(예: staging 또는 production)입니다. 워크플로 작업은 대상으로 하는 환경을 참조합니다. GitHub 작업이 실행되거나 환경 비밀에 액세스하기 전에 해당 환경의 보호 규칙을 평가합니다.
환경 이름은 Azure 리소스를 만들지 않습니다. 각 GitHub 환경이 Azure Machine Learning 리소스에 매핑되는 방법을 결정합니다. 예를 들어 스테이징 및 프로덕션은 더 강력한 격리를 위해 별도의 작업 영역을 사용하거나 관리 오버헤드를 낮추기 위해 하나의 작업 영역에서 별도의 엔드포인트를 사용할 수 있습니다.
메모
GitHub 환경은 배포 작업을 제어합니다. Azure Machine Learning 환경은 기계 학습 코드를 실행하는 데 사용되는 운영 체제, 패키지 및 기타 종속성을 정의합니다. 두 개념은 독립적입니다.
프로덕션으로의 승격 보호
GitHub 환경 보호 규칙에는 검토자가 필요하거나, 선택한 분기 또는 태그로 배포를 제한하거나, 대기 타이머를 추가할 수 있습니다. Proseware의 경우 main의 실행만 프로덕션을 대상으로 지정할 수 있습니다. 필수 검토자는 프로덕션 승격 작업의 계속 진행을 허용하기 전에 스테이징 테스트 결과를 검토합니다.
이 게이트는 두 가지 결정을 구분합니다. 자동화된 검사는 배포가 정의된 요구 사항을 충족하는지 여부를 결정합니다. 검토자는 증거 및 운영 컨텍스트를 고려하여 릴리스를 지금 진행할지 여부를 결정합니다.
범위 구성 및 액세스
환경 변수는 Azure Machine Learning 작업 영역 및 엔드포인트 이름과 같은 중요하지 않은 대상 설정을 포함할 수 있습니다. 환경 비밀은 해당 환경을 참조하는 작업과 보호 규칙이 통과된 후에만 사용할 수 있습니다.
OIDC를 사용하면 클라이언트 비밀을 저장하지 않습니다. 스테이징 및 프로덕션에 다른 페더레이션 ID를 계속 사용한 다음 각 ID에 작업에 필요한 Azure 권한만 부여할 수 있습니다. 이 방법을 사용하면 두 작업 모두 동일한 리포지토리를 사용하기 때문에 스테이징 작업이 프로덕션 액세스 권한을 얻을 수 없습니다.
실제 워크플로는 배포와 승격을 구분합니다. 한 작업은 프로덕션 트래픽 없이 새 모델을 배포하고 테스트합니다. 이후 작업은 보호된 production 환경을 참조하고 승인 후에만 트래픽을 변경합니다.
팁 (조언)
승인을 추가하기 전에 검토자에게 필요한 증거를 식별합니다. 명확한 수용 기준이 없는 게이트는 결정을 개선하지 않고 배포를 지연합니다.
배포를 위한 GitHub 환경 관리에 대해 자세히 알아봅니다.