Azure Artifacts란?
이 단원에서는 Azure Artifacts를 사용하여 앱에서 사용할 수 있는 패키지를 안전하게 만들고 관리하는 방법을 간단히 알아볼 수 있습니다.
팀이 Azure Artifacts가 .NET 패키지를 호스트하는 적절한 방법인지 여부를 결정할 때 함께 확인해 보겠습니다.
Mara: Azure Artifacts에서 새 Models 패키지를 호스트하는 것이 합리적일 것 같습니다. 우리는 모두 이미 Microsoft Azure DevOps 조직의 일부이므로 다른 패키지 관리자에서 설정하는 것보다 인증이 더 쉽습니다.
Andy: 회의 전에 살펴보았는데 간단해 보입니다. Mara에 동의합니다.
Amita: Azure Artifacts란?
Andy: Azure Artifacts는 코드베이스에 대한 종속성을 관리할 수 있는 Azure DevOps 조직의 리포지토리입니다. Azure Artifacts는 아티팩트와 이진 파일을 저장할 수 있습니다. 종속성 그룹의 ‘피드’라는 컨테이너를 제공합니다. 피드에 액세스할 수 있는 개발자는 패키지를 쉽게 이용하거나 게시할 수 있습니다.
패키지를 만들고 파이프라인에서 사용하려면 어떻게 하나요?
Tim: 제가 제대로 이해하고 있다면 앱 코드에서 이미 NuGet의 패키지를 사용하고 있습니다. 사용자 고유 패키지를 만들고 Azure Artifacts에서 호스트해 보겠습니다. 각 부분을 찾아서 서로 어떻게 작동하는지 도출할 수 있나요? 전체 프로세스를 상상하는 데 어려움을 겪고 있습니다.
Andy: 물론이죠. 패키지를 만들고 Azure DevOps 파이프라인에서 사용하는 프로세스를 살펴보겠습니다.
Andy가 화이트보드로 이동합니다.
패키지 만들기
먼저 Azure Artifacts에서 프로젝트를 만들어야 합니다. Azure DevOps에서 이 작업을 수행할 수 있습니다.
그런 다음 패키지 코드의 GitHub 리포지토리에 연결하는 파이프라인을 Azure Pipelines에 만듭니다. 그런 다음 파이프라인에서 코드를 빌드하고 패키징하고, 패키지를 Azure Artifacts로 푸시합니다.
만든 Azure Artifacts 피드를 가리키도록 이 패키지를 사용하는 앱을 업데이트해야 합니다.
그런 다음 앱을 만드는 파이프라인을 업데이트합니다. 업데이트하면 Azure Artifacts 피드를 사용하여 새 패키지 종속성을 끌어오고 정상적으로 빌드할 수 있습니다.
패키지 업데이트
Tim: 누군가 패키지를 업데이트하면 어떻게 되나요?
Andy: 새로운 기능이나 버그 수정으로 패키지를 업데이트하고 올바르게 작동하는지 테스트를 실행할 때 패키지의 버전 번호를 높입니다. 그런 다음 변경 내용을 커밋합니다. 패키지 파이프라인에서 커밋을 확인하고 새 버전 번호로 Azure Artifacts에 새 아티팩트를 만듭니다. 버전 번호가 낮은 이전 패키지는 해당 버전을 사용하는 앱을 위해 여전히 존재하기 때문에 걱정할 필요가 없습니다. 따라서 대부분의 경우에는 패키지 목록을 해제하지 않습니다.
앱에서 이 최신 버전의 패키지를 사용할 수도 있습니다. 이 경우 최신 버전을 참조하도록 앱을 업데이트하고 로컬에서 테스트를 실행하여, 이 새 버전이 앱에서 작동하는지 확인합니다. 모든 항목이 만족스럽게 작동하면 앱 변경 내용을 파이프라인에 제출합니다. 새 버전의 패키지 종속성으로 빌드됩니다.
Amita: 좋은 계획인 것 같고 다른 팀에도 도움이 될 것 같습니다. 코드를 입력할 때 드리프트되지 않게 하는 역할도 합니다. 이는 QA에도 도움이 됩니다.
빌드 파이프라인에 버전 관리 전략 포함
빌드 파이프라인을 사용하는 경우 패키지를 사용하고 테스트하려면 버전이 필요합니다. 그러나 패키지를 테스트한 후에만 품질을 확인할 수 있습니다. 패키지 버전은 변경하지 않아야 하므로 특정 버전을 미리 선택하는 것이 어렵습니다.
Azure Artifacts는 품질 수준을 피드의 각 패키지와 연결하고 시험판과 릴리스 버전을 구분합니다. Azure Artifacts는 품질 수준에 따라 패키지를 구분하는 패키지 및 버전 목록에 관한 다양한 보기를 제공합니다. 이 접근 방식은 특정 버전의 의도를 예측하는 데 유용한 유의적 버전 관리와 제대로 작동합니다. Azure Artifacts는 설명자를 사용하여 Azure Artifacts 피드의 추가 메타데이터도 포함합니다. 일반적으로 보기는 테스트, 유효성 검사 또는 배포된 패키지 버전을 공유하지만, 아직 개발 중이며 공개적으로 사용할 준비가 되지 않은 패키지를 보류하는 데도 사용합니다.
기본적으로 Azure Artifacts의 피드에는 세 가지 보기가 있습니다. 이 보기는 새 피드를 만들 때 추가됩니다. 세 가지 보기는 다음과 같습니다.
- Release: @release 뷰에는 공식 릴리스로 간주되는 모든 패키지가 포함되어 있습니다.
- Prerelease: @prerelease 뷰에는 버전 번호에 레이블이 있는 모든 패키지가 포함됩니다.
- Local: @local 보기에는 업스트림 소스에서 다운로드한 패키지뿐만 아니라 모든 릴리스 및 시험판 패키지가 포함되어 있습니다.
보기를 사용하면 패키지-피드의 소비자가 릴리스된 버전과 릴리스되지 않은 버전의 패키지를 필터링하도록 지원할 수 있습니다. 기본적으로 보기를 통해 소비자는 릴리스된 패키지 중에서 선택하거나 특정 품질 수준의 시험판을 선택할 수 있습니다.
Azure Artifacts의 패키지 보안
패키지의 보안을 보장하는 것은 나머지 코드의 보안을 보장하는 것만큼 중요합니다. 패키지 보안의 한 측면은 패키지 피드에 대한 액세스를 보호하는 것입니다. (여기서 피드는 Azure Artifacts에서 패키지를 저장하는 위치입니다.) 피드에서 권한을 설정하면 시나리오에 필요한 수만큼의 사용자와 패키지를 공유할 수 있습니다.
피드 권한
피드에는 소유자, 기여자, 협력자 및 읽기 권한자의 네 가지 액세스 권한 수준이 있습니다. 각 액세스 수준에는 특정 권한 세트가 있습니다. 예를 들어 소유자는 모든 유형의 ID, 즉 개인과 팀 및 그룹을 모든 액세스 수준에 추가할 수 있습니다. 기본적으로 프로젝트 컬렉션 빌드 서비스는 협력자이며 프로젝트 팀은 읽기 권한자입니다.
보안 및 라이선스 등급에 액세스하도록 파이프라인 구성
사용하는 소프트웨어 패키지의 보안 및 라이선스 등급을 평가하는 데 도움이 되는 타사에서 제공하는 도구가 여러 개 있습니다.
해당 도구 중 일부는 빌드 또는 CD 파이프라인에 포함된 패키지를 검사합니다. 빌드 프로세스 중에 이 도구는 패키지를 검사하고 즉각적인 피드백을 제공합니다. CD 프로세스 중에 도구는 빌드 아티팩트를 사용하고 검사를 수행합니다. 이러한 도구의 대표적인 예는 Mend Bolt와 Black Duck입니다. Azure DevOps에서 빌드 작업을 사용하여 검사를 파이프라인에 통합합니다.