이 업데이트를 통해 인기 있는 다른 패키지 관리자와 함께 Azure Artifacts를 더 쉽게 인증할 수 있습니다. 아래의 실제 구현에 대한 자세한 내용을 찾습니다.
기능
Azure Boards
Azure Pipelines (애저 파이프라인스)
Azure Artifacts (Azure의 아티팩트)
Azure Boards
작업 보드 및 스프린트 백로그에 “부모 작업 항목” 필터 추가
스프린트 보드와 스프린트 백로그 모두에 새 필터를 추가했습니다. 이렇게 하면 요구 사항 수준의 백로그 항목(왼쪽의 첫 번째 열)을 부모 기준으로 필터링할 수 있습니다. 예를 들어 아래 스크린샷에서는 부모가 "My big feature"인 사용자 스토리만 표시하도록 보기를 필터 처리했습니다.
오류 처리 환경 개선 – 버그/작업에 필요한 필드
지금까지 Kanban 보드에서 작업 항목을 한 열에서 다른 열로 이동한 경우 상태 변경으로 인해 필드 규칙이 트리거된 경우 카드에 빨간색 오류 메시지가 표시되어 근본 원인을 이해하기 위해 작업 항목을 열어야 합니다. 스프린트 170에서는 이제 작업 항목 자체를 열지 않고도 빨간색 오류 메시지를 클릭하여 오류의 세부 정보를 볼 수 있도록 환경을 개선했습니다.
Azure Pipelines (애저 파이프라인스)
스케일링 설정 에이전트 미리 보기
Microsoft 호스팅 에이전트의 편리성과 탄력적 용량을 자체 호스팅 에이전트의 제어 및 유연성과 결합하는 확장 집합 에이전트라는 새로운 기능을 미리 봅니다. 이 미리 보기를 통해 이제 Azure 구독에서 완전히 자동화된 사양에 대한 에이전트를 관리할 수 있습니다. 다음과 같은 경우 Microsoft 호스팅 또는 자체 호스팅 에이전트 대신 확장 집합 에이전트를 사용하는 것이 좋습니다.
- 네이티브 Microsoft 호스팅 에이전트에서 제공하는 것보다 더 많은 메모리, 더 많은 프로세서, 더 많은 스토리지 또는 더 많은 I/O가 필요합니다.
- Microsoft 호스팅 에이전트가 서버와 통신할 수 있도록 회사 방화벽 내에서 많은 수의 IP 주소를 나열하도록 허용하지 않습니다.
- 대규모 요구 사항을 충족하기 위해 제공할 수 있는 것보다 더 많은 Microsoft 호스팅 에이전트가 필요합니다.
- 조직의 개별 프로젝트 또는 팀에 Microsoft 호스팅 병렬 작업을 분할하는 기능이 필요합니다.
- 전용 에이전트를 상시 실행하지 않고, 대신 적극적으로 사용되지 않는 에이전트 머신을 해체하려고 합니다.
확장 집합 에이전트를 사용하려면 먼저 Azure 구독에서 VM 확장 집합을 만든 다음 Azure Pipelines에서 해당 확장 집합을 가리키는 에이전트 풀을 만듭니다. Azure Pipelines는 보류 중인 작업 수와 항상 유지 관리하려는 유휴 머신 수에 따라 이 풀의 크기를 자동으로 조정합니다. 또한 Azure Pipelines는 이러한 가상 머신에 에이전트를 설치합니다. 자세한 내용은 확장 집합 에이전트를 참조하세요. 이 기능을 미리 볼 때 설명서 페이지에 피드백을 포함하세요.
Azure Pipelines 호스트된 풀에 대해 미리 보기로 제공되는 Ubuntu 20.04
Ubuntu 20.04 이미지는 이제 Azure Pipelines 호스팅 풀에 대한 미리 보기로 제공됩니다. 이 이미지를 사용하려면 vmImage: 'ubuntu-20.04'를 포함하도록 YAML 파일을 업데이트합니다. 올해 말에 ubuntu-20.04가 미리 보기에서 나올 때까지, ubuntu-latest 이미지 레이블은 계속해서 ubuntu-18.04를 지칭하므로 참고 바랍니다.
ubuntu 20.04 이미지는 미리 보기 상태이므로 현재 ubuntu-18.04에서 사용할 수 있는 모든 도구를 지원하지는 않습니다. 자세히 알아보기
YAML 파이프라인의 GitHub 패키지 지원
최근에 YaML 파이프라인의 리소스로 GitHub의 NuGet 및 npm 패키지를 사용하는 지원을 추가하는 패키지이라는 새로운 리소스 유형을 도입했습니다. 이제 이 리소스의 일부로 GitHub에서 사용할 패키지 유형(NuGet 또는 npm)을 지정할 수 있습니다. 새 패키지 버전이 릴리스될 때 자동화된 파이프라인 트리거를 사용하도록 설정할 수도 있습니다. 현재 지원은 GitHub에서 패키지를 사용하는 데만 사용할 수 있지만 앞으로는 NuGet, npm, AzureArtifacts 등과 같은 다른 패키지 리포지토리의 패키지를 사용하도록 지원을 확장할 계획입니다. 자세한 내용은 아래 예제를 참조하세요.
resources:
packages:
- package: myPackageAlias # alias for the package resource
type: Npm # type of the package NuGet/npm
connection: GitHubConn # GitHub service connection of type PAT
name: nugetTest/nodeapp # <Repository>/<Name of the package>
version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers
참고: 현재 GitHub 패키지는 PAT 기반 인증만 지원합니다. 즉, 패키지 리소스의 GitHub 서비스 연결은 PAT 형식이어야 합니다. 이 제한이 해제되면 다른 유형의 인증에 대한 지원을 제공합니다.
기본적으로 패키지는 작업에 자동으로 다운로드되지 않으므로 리소스에 정의된 패키지를 사용할 수 있는 getPackage 매크로가 도입되었습니다. 자세한 내용은 아래 예제를 참조하세요.
- job: job1
pool: default
steps:
- getPackage: myPackageAlias # Alias of the package resource
Azure Artifacts (Azure의 아티팩트)
사용할 수 없는 업스트림 소스에 대한 알림
이제 Azure Artifacts 웹 인터페이스는 하나 이상의 피드 업스트림 원본이 작동하지 않는 경우 알림을 제공합니다. 업스트림 원본을 사용하면 피드(피드 A)를 다른 피드(피드 B)로 가리키고 피드 A 소비자가 피드 B에서 직접 연결하지 않고도 피드 B의 패키지에 액세스할 수 있습니다. 업스트림 원본에 대한 자세한 내용은 Azure Artifacts 설명서를 참조하세요. 원본에서 사용하지 않도록 설정된 경우 업스트림 원본이 작동하지 않을 수 있습니다. 예를 들어 피드 B가 자동으로 삭제되는 경우 고객은 피드 A를 통해 패키지를 가져올 수 없습니다. 과거에는 이러한 상황이 경고 없이 발생할 수 있으며, 종속성 누락으로 인한 갑작스런 빌드 중단(예: 위 예제의 피드 B에서 공급된 패키지)과 같은 운영 문제를 진단하기 어려울 수 있습니다. 이제 Azure Artifacts는 피드의 업스트림 원본에 문제가 있는 경우 경고를 제공합니다. 문제가 발생하면 Azure Artifacts 피드 세부 정보 페이지에 배너(아래 빨간색 화살표)가 표시됩니다.
배너에서 링크를 클릭하면 피드의 각 업스트림 원본의 상태를 표시하는 페이지가 열립니다. 현재 피드의 각 업스트림 원본에 대한 정보 외에도 "마지막 동기화됨" 열 아래에서 현재 상태를 볼 수 있습니다. 제대로 작동하는 업스트림 소스는 원본의 상태가 마지막으로 확인되었을 때 녹색 체크 표시가 표시됩니다. 손상되는 업스트림 원본은 확인된 시간과 함께 빨간색 X를 표시합니다. 확인 보류 중인 업스트림 원본에는 파란색 정보 아이콘이 표시됩니다.
끊어진 업스트림 원본에 대한 마지막 동기화 시간을 클릭하면 문제의 근본 원인에 대한 자세한 내용을 공유하는 대화 상자가 열립니다(사용 가능한 경우). 예를 들어 아래 그림에서 대상 피드가 삭제되어 해당 업스트림 원본이 작동하지 않습니다. 대화 상자에는 감사 로그에 대한 링크도 포함되어 있습니다. 이 링크는 최근 누가 관련 변경을 했는지 이해하는 데 도움이 됩니다. 권한 설정 및 Azure Artifacts 설명서에 대한 링크를 사용하여 근본 원인을 조사할 수도 있습니다.
라이선스 식 및 포함된 라이선스
이제 Visual Studio에서 패키지를 검색하는 동안 Azure Artifacts에 저장된 NuGet 패키지에 대한 라이선스 정보의 세부 정보를 볼 수 있습니다. 이는 라이선스 식 또는 포함된 라이선스를 사용하여 표현되는 라이선스에 적용됩니다. 이제 Visual Studio 패키지 세부 정보 페이지에서 라이선스 정보에 대한 링크를 볼 수 있습니다(아래 이미지의 빨간색 화살표).
링크를 클릭하면 라이선스의 세부 정보를 볼 수 있는 웹 페이지로 이동됩니다. 이 환경은 라이선스 식과 포함된 라이선스 모두에 대해 동일하므로 Azure Artifacts에 저장된 패키지에 대한 라이선스 세부 정보를 한 곳에서 볼 수 있습니다(라이선스 정보를 지정하고 Visual Studio에서 지원하는 패키지의 경우).
간단한 인증 작업
이제 경량 인증 작업을 사용하여 Azure Pipelines에서 인기 있는 패키지 관리자로 인증할 수 있습니다. 여기에는 NuGet, npm, PIP, Twine 및 Maven이 포함됩니다. 이전에는 패키지를 게시하고 다운로드하는 기능을 포함하여 많은 기능을 제공하는 작업을 사용하여 이러한 패키지 관리자에게 인증할 수 있었습니다. 그러나 패키지 관리자와 상호 작용하는 모든 활동에 이러한 작업을 사용해야 했습니다. 패키지 게시 또는 다운로드와 같은 작업을 수행하기 위해 실행할 고유한 스크립트가 있는 경우 파이프라인에서 사용할 수 없습니다. 이제 파이프라인 YAML에서 고유한 디자인의 스크립트를 사용하고 이러한 새로운 경량 작업으로 인증을 수행할 수 있습니다. npm을 사용하는 예제:
이 그림에서 "ci" 및 "publish" 명령을 사용하는 것은 임의로, Azure Pipelines YAML에서 지원하는 모든 명령을 사용할 수 있습니다. 이렇게 하면 명령 호출을 완벽하게 제어할 수 있으며 파이프라인 구성에서 공유 스크립트를 쉽게 사용할 수 있습니다. 자세한 내용은 NuGet, npm, PIP, Twine및 Maven 인증 작업 설명서를 참조하세요.
다음 단계
비고
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백 제공 방법
여러분의 의견을 듣고 싶습니다. 이 기능들에 대해 어떻게 생각하시는지 알려주세요. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티로부터 조언을 받고 질문에 대한 답변을 얻을 수도 있습니다.
감사합니다,
아론 할버그