Azure DevOps의 Sprint 150 업데이트 에서 포털 내에서 조직에 대한 청구를 관리하는 기능을 추가했습니다.
새 청구 탭에서 청구에 사용하는 Azure 구독을 선택하고 추가 사용자에 대한 요금을 지불할 수 있습니다. 더 이상 Visual Studio Marketplace 또는 Azure Portal로 이동하여 청구를 관리할 필요가 없습니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
일반:
Azure Boards:
- Azure Active Directory 그룹을 기반으로 쿼리 작업
- 배지를 사용하여 팀 보드 공유
- 하루, 주, 월, 또는 연도의 시작을 기준으로 한 작업 쿼리
- 쿼리 결과를 CSV 파일로 내보내기
Azure Repos:
- 끌어오기 요청 완료하기 위한 새 병합 형식
Azure Pipelines:
- Kubernetes 매니페스트 작업
- Docker 작업으로 업그레이드
- Kubectl 도구 설치 관리자
- Docker 레지스트리 서비스 연결의 Azure Container Registry
- 호스트된 Ubuntu 풀에 대한 cgroup 지원
- 에이전트 한 번 실행
- Visual Studio 테스트 작업의 VISUAL Studio 2019(VS2019) 지원
- 에이전트 풀 사용자 인터페이스 업데이트
- YAML 파일 편집하기 위한 작업 도우미
- 호스트된 파이프라인 이미지 업데이트
- ServiceNow 통합 개선 사항
- Azure PowerShell Az 모듈 지원
- 리소스 권한 부여 개선
- 빌드 파이프라인에 대한 간소화된 보존 정책
- 릴리스에서 자동으로 가져오는 파이프라인 아티팩트
- Cobertura 코드 검사 보고서 업데이트
리포트:
위키
관리:
일반
어두운 테마 일반 공급
지난 10월, 새로운 탐색의 일환으로 어두운 테마의 공개 미리 보기를 발표했습니다. 몇 달 동안 미리 보기에서 피드백을 듣고 환경을 조정한 후 어두운 테마의 일반 공급에 대해 발표하게 되어 기쁩니다.
Azure DevOps에서 조직의 청구 관리
이제 Azure DevOps 포털에서 조직의 청구를 관리할 수 있음을 알려드리겠습니다. 관리자는 더 이상 Azure Portal을 통해 청구를 설정할 필요가 없습니다. 청구 설정을 관리하려면 조직 설정 으로 이동하여 청구를 선택합니다.
다음은 청구 탭에서 관리할 수 있는 설정 목록입니다.
청구에 사용할 Azure 구독을 선택할 수 있습니다.
다른 구독을 선택하여 조직에서 청구에 사용하는 Azure 구독을 변경할 수 있습니다. 이전에는 청구를 제거한 다음 각 유료 리소스(기본 사용자, 패키지 관리 사용자, MS 호스트된 파이프라인 등)에 대해 동일한 수준을 신중하게 재구매해야 했습니다. 이 프로세스는 지루하고 오류가 발생하기 쉽습니다. 이제 다른 구독을 선택하고 저장을 클릭하여 조직에서 청구에 사용하는 Azure 구독을 변경할 수 있습니다.
더 이상 Visual Studio Marketplace로 이동하여 청구 설정을 관리할 필요가 없습니다. 추가 기본, 테스트 관리자 및 패키지 관리(Azure Artifacts) 사용자에 대한 요금을 지불하는 기능을 추가했습니다. 새 청구 탭에서 조직에서 지불하는 사용자 수를 늘리거나 줄일 수 있습니다 .
Azure Boards
Azure Active Directory 그룹을 기반으로 한 쿼리 작업
Azure Active Directory의 채택이 증가하고 그룹을 사용하여 보안을 관리하는 보급으로 팀은 점점 더 Azure Boards에서 이러한 그룹을 활용할 방법을 찾고 있습니다. 이제 In Group 또는 Not In Group 연산자를 사용하여 특정 사용자가 할당하거나 변경한 작업 항목을 쿼리하는 것 외에도 Azure Active Directory 그룹을 직접 사용할 수 있습니다.
자세한 내용은 쿼리 연산자 설명서를 참조하세요.
배지를 사용하여 팀 보드 공유
리포지토리의 README 파일은 종종 프로젝트 팀이 솔루션에 기여하고 팀이 이를 사용하는 방법에 대한 정보를 찾는 주요 출처입니다. 이제 Azure Pipelines에서 빌드 또는 배포 상태 배지를 추가하는 것처럼, README 파일에 Azure Boards의 팀 보드 배지를 추가할 수 있습니다. 진행 중인 열 또는 모든 열만 표시하도록 배지를 구성하고 프로젝트가 오픈 소스인 경우에도 배지를 공개적으로 표시하도록 구성할 수 있습니다.
README가 Markdown을 기반으로 하는 경우 상태 배지 설정 페이지에서 샘플 Markdown을 복사하여 파일에 붙여넣을 수 있습니다.
일, 주, 월 또는 연도의 시작을 기준으로 작업 쿼리
팀은 다음에 나올 내용의 컨텍스트 내에서 또는 스프린트 반복을 기반으로 하는 작업에 집중하는 경우가 많지만, 달력의 렌즈를 통해 작업을 되돌아보면서 지난 달 또는 올해 1분기에 일어난 모든 작업을 보고하는 것이 흥미로울 수 있습니다. 이제 날짜 기반 필드와 함께 다음과 같은 새 @StartOf 매크로 집합을 사용하여 날짜, 주, 월 또는 연도의 시작을 기준으로 쿼리할 수 있습니다.
- @StartOfYear
- @StartOfMonth
- @StartOfWeek
- @StartOfDay
이러한 각 매크로는 다른 날짜 단위로 데이터를 이동할 수 있는 새 한정자 문자열도 허용합니다. 올해 1분기에 완료된 모든 작업 항목을 찾기 위해 '상태 변경 날짜 >= @StartOfYear ' 및 '상태 변경 날짜 <= @StartOfYear(“+3M”)'를 이용한 쿼리를 작성할 수 있습니다. 자세한 내용은 쿼리 매크로 설명서를 참조하세요.
쿼리 결과를 CSV 파일로 내보내기
이제 쿼리 결과를 웹에서 CSV 형식 파일로 직접 내보낼 수 있습니다.
Azure Repos
끌어오기 요청을 완료하기 위한 새 병합 형식
이제 끌어오기 요청에서 대상 분기로 변경 내용을 병합할 때 더 많은 옵션이 있습니다. 개발자 커뮤니티에서 가장 많이 요청된 두 가지 기능인 Fast-Forward 병합 및 Semi-Linear 병합 ("재베이스 및 병합"이라고도 함)에 대한 지원을 추가했습니다.
이제 풀 리퀘스트 완료 대화 상자에서 사용할 수 있는 새 옵션이 표시됩니다.
업데이트된 정책 관리 페이지에서 관리자는 분기 또는 분기 폴더에서 허용되는 병합 전략을 제어할 수 있습니다.
비고
기존 정책은 여전히 적용됩니다. 예를 들어 분기에 현재 "스쿼시 병합만" 정책이 있는 경우 새 병합 전략을 사용하려면 해당 정책을 편집해야 합니다.
끌어오기 요청 완료 과정에서 재베이스할 수 없는 몇 가지 상황이 있습니다.
- 대상 브랜치의 정책에서 리베이스 전략 사용을 금지하는 경우 "브랜치 정책 재정의" 권한이 필요합니다.
- 끌어오기 요청의 원본 분기에 정책이 있는 경우 리베이스할 수 없습니다. 리베이스는 정책 승인 프로세스를 거치지 않고 소스 브랜치를 수정하게 될 것입니다.
- 병합 충돌 확장을 사용하여 병합 충돌을 해결한 경우 끌어오기 요청의 모든 커밋을 한 번에 하나씩 다시 적용할 때 3방향 병합에 적용되는 충돌 해결은 거의 성공하지 못하거나 유효하지도 않습니다.
이러한 모든 경우에 브랜치를 로컬에서 리베이스하여 서버로 푸시하거나, 또는 풀 리퀘스트를 완료할 때 변경 내용을 하나의 커밋으로 병합할 수 있습니다.
Azure Pipelines (애저 파이프라인스)
Kubernetes 매니페스트 작업
매니페스트 파일을 사용하여 Kubernetes 클러스터에 배포하는 프로세스를 간소화하기 위해 릴리스 파이프라인에 새 작업을 추가했습니다. 이 작업은 스크립트에서 kubectl 이진을 사용하는 경우와 비교할 때 다음과 같은 이점을 제공합니다.
아티팩트 대체 - 배포 작업은 태그 또는 다이제스트와 함께 지정할 수 있는 컨테이너 이미지 목록을 입력으로 사용합니다. 이는 클러스터에 적용하기 전에 매니페스트 파일의 템플릿이 아닌 버전으로 대체되어 클러스터 노드에서 올바른 버전의 이미지를 끌어올 수 있도록 합니다.
매니페스트 안정성 - 작업 상태를 성공/실패로 계산하는 동안 안정성 검사를 통합하기 위해 배포된 Kubernetes 개체에 대해 롤아웃 상태가 확인됩니다.
추적 가능성 주석 - 원본 조직, 프로젝트, 파이프라인 및 실행에 대한 추적 가능성 정보를 중첩하기 위해 배포된 Kubernetes 개체에 주석이 추가됩니다.
매니페스트 굽기 - 이 작업의 굽기 기능을 활용하여 Helm 차트를 Kubernetes 매니페스트 파일로 변환함으로써 클러스터에 적용할 수 있습니다.
배포 전략 - 배포 작업을 통해 카나리아 전략을 선택하면 원하는 비율의 워크로드가 생성됩니다. 이 워크로드는 -baseline 및 -canary 접미사가 추가되어
ManualIntervention작업 중 비교할 수 있도록 설계되며, 이후 작업의 승격 또는 거부 작업을 활용하여 최종적으로 보존할 버전을 결정합니다.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
helmChart: charts/sample
overrides: 'image.repository:nginx'
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
containers: |
nginx: 1.7.9
Docker 작업으로 업그레이드
파이프라인 제작 환경을 간소화하기 위해 Docker 작업을 업그레이드했습니다. 이제 buildAndPush 명령을 사용하여 특정 컨테이너 리포지토리에 대한 여러 태그를 빌드하고 한 단계로 여러 컨테이너 레지스트리에 푸시할 수 있습니다. 이 작업은 Docker 레지스트리 서비스 연결을 사용하여 컨테이너 레지스트리에 로그인할 수 있습니다. 원본 리포지토리, 커밋 및 빌드 출처에 대한 추적 가능성 메타데이터는 이 작업을 사용하여 빌드된 이미지에 레이블로 추가됩니다.
steps:
- task: Docker@2
displayName: Container registry login - ACR1 service connection
inputs:
command: login
containerRegistry: acr1
- task: Docker@2
displayName: Container registry login - ACR2 service connection
inputs:
command: login
containerRegistry: acr2
- task: Docker@2
displayName: Build and push images
inputs:
repository: test
tags: |
d1
d2
Kubectl 도구 설치 프로그램
에이전트에 특정 버전의 Kubectl 이진 파일을 설치할 수 있는 새 작업을 추가했습니다. 최신 및 셈버 버전 문자열(예: 'v1.14.0')은 Kubectl 버전 사양 입력에 유효한 값으로 허용됩니다.
Docker 레지스트리 서비스 연결의 Azure 컨테이너 레지스트리
이제 프로젝트의 설정 페이지에서 Docker 레지스트리 서비스 연결을 만들 수 있습니다. 연결을 만들려면 Azure AD(Azure Active Directory) ID와 연결된 구독 중 하나에서 Azure 컨테이너 레지스트리를 선택합니다. Docker@2 및 KubernetesManifest@0 같은 컨테이너 레지스트리에 대한 서비스 연결이 필요한 모든 작업은 연결을 지정하는 단일 방법을 지원합니다.
호스트된 Ubuntu 풀에 대한 cgroup 지원
Linux에서 메모리 사용량이 너무 높으면 커널은 나머지를 보호하기 위해 일부 프로세스를 종료합니다. Azure Pipelines 에이전트 프로세스가 종료되도록 선택된 경우 에이전트와의 통신 손실에 대한 오류 메시지와 함께 파이프라인 실행이 실패합니다. Microsoft 호스팅 Ubuntu 풀에서는 사용자 지정 cgroup 내의 단계를 실행하여 에이전트가 종료될 가능성을 줄여 줍니다. 사용 가능한 메모리를 초과하면 파이프라인이 여전히 실패할 수 있지만 에이전트 프로세스는 계속 유지되고 오류를 올바르게 보고할 가능성이 높습니다. 프라이빗 Linux 에이전트를 실행하는 경우 유사한 설정을 고려할 수 있도록 사용하는 설정을 게시 했습니다.
일회성 실행 에이전트
Azure Container Instances와 같은 인프라를 사용하여 탄력적 프라이빗 에이전트를 실행하는 경우 종종 각 에이전트가 사라지기 전에 하나의 작업만 허용하도록 합니다. 지금까지는 에이전트를 종료해야 하거나(보고 실패의 원인이 될 수 있습니다), 에이전트를 중지하기 전에 다른 작업을 받을 위험을 감수해야 했기 때문에 이 과정이 쉽지 않았습니다. 이 업데이트를 통해 에이전트 구성에 --once 플래그를 추가했습니다. 이러한 방식으로 에이전트를 구성하면 하나의 작업만 수락한 다음, 자체 작업을 종료합니다.
Visual Studio 테스트 작업의 VISUAL Studio 2019(VS2019) 지원
파이프라인의 Visual Studio 테스트 작업에 VS2019에 대한 지원을 추가했습니다. VS2019용 테스트 플랫폼을 사용하여 테스트를 실행하려면 테스트 플랫폼 버전 드롭다운에서 최신 또는 Visual Studio 2019 옵션을 선택합니다.
에이전트 풀 사용자 인터페이스 업데이트
프로젝트 설정의 에이전트 풀 관리 페이지가 새 사용자 인터페이스로 업데이트되었습니다. 이제 풀에서 실행 중인 모든 작업을 쉽게 볼 수 있습니다. 또한 작업이 실행되지 않는 이유를 알아볼 수 있습니다.
YAML 파일 편집을 위한 작업 도우미
파이프라인에 대한 YAML 파일을 더 쉽게 편집할 수 있도록 요청하는 많은 피드백을 계속 받습니다. 이전 업데이트에서는 intellisense 지원을 추가했습니다. 이제 YAML 편집기에서 작업 도우미를 추가합니다. 이렇게 하면 클래식 편집기에서와 같이 YAML 파일에 새 작업을 추가하는 것과 동일한 친숙한 환경이 제공됩니다. 이 새 도우미는 선택 목록 및 서비스 연결과 같은 대부분의 일반적인 작업 입력 유형을 지원합니다. 새 작업 도우미를 사용하려면 YAML 기반 파이프라인에서 편집을 선택한 다음 작업 도우미선택합니다.
호스트된 파이프라인 이미지 업데이트
Xcode 10.2에 대한 지원도 포함할 OS X Mojave(10.4)로 호스트된 macOS 풀에 대한 업데이트를 발표하게 되어 기쁩니다. 디자이너 기반 파이프라인이 호스트된 macOS 풀을 사용하는 경우 파이프라인은 자동으로 Mojave로 업그레이드됩니다. OS X High Sierra(10.3)에 유지하려면 빌드가 실행되는 풀을 Hosted macOS High Sierra로 변경합니다.
YAML을 사용하는 경우 사용할 수 있는 새 vmImage 레이블은 다음과 같습니다.
- 항상 최신 버전의 macOS(현재 10.4)를 가리키는 이미지 레이블
vmImage: 'macOS-latest'
- 이 이미지 레이블은 파이프라인이 Mojave에 대해 실행되는지 확인하려는 경우 특히 mac OS 10.4를 대상으로 합니다.
vmImage: 'macOS-10.4'
- 파이프라인이 High Sierra에서 제대로 실행되는지 확인하려면, macOS High Sierra를 대상으로 하는 특정 이미지 레이블을 사용하십시오.
vmImage: 'macOS-10.3'
또한 호스트된 Azure Pipelines에 대한 Windows Server 2019 이미지를 업데이트했습니다. 최신 릴리스는 여기에서 찾을 수 있습니다. 이 업데이트에는 VS2019 Preview, Docker, PowerShell Core, Node.js, npm 등의 새 버전이 포함되어 있습니다.
호스트된 macOS VM 이미지에 포함된 항목에 대한 자세한 내용과 이미지에서 사용할 수 있는 도구에 대한 자세한 내용은 GitHub의 이미지 생성 리포지토리 를 참조하세요.
ServiceNow 통합 개선 사항
지난 12월에는 릴리스 파이프라인과 ServiceNow 변경 관리 통합을 릴리스했습니다. 각 팀이 선택한 서비스를 사용하고 효과적인 엔드 투 엔드 배달을 가능하게 하는 팀 간 협업을 위한 주요 기능입니다. 이 업데이트를 통해 모든 유형의 변경(일반, 표준 및 긴급)을 지원하도록 통합이 향상되었습니다. 또한 이제 조직에서 수행된 ITSM 프로세스에 따라 기존 템플릿을 사용하여 새 변경 요청을 만드는 데 사용되는 게이트를 지정할 수 있습니다. 마지막으로 기존 변경 요청에 따라 릴리스를 제어할 수도 있습니다. 이를 통해 IT 팀에서 권장하는 프로세스를 변경할 필요 없이 CD를 채택할 수 있습니다.
Azure PowerShell Az 모듈 지원
Azure PowerShell은 명령줄에서 Azure 리소스를 관리하는 데 사용할 수 있는 cmdlet 집합을 제공합니다. 작년 12월에 Azure PowerShell Az 모듈을 사용할 수 있게 되었고 이제 Azure 리소스를 관리하기 위한 모듈이 되었습니다.
이전에는 호스트된 에이전트에서 Azure PowerShell Az 모듈에 대한 지원을 제공하지 않았습니다. 빌드 및 릴리스 파이프라인의 새 Azure PowerShell 작업 버전 4.*를 사용하여 모든 플랫폼에 대한 새 Az 모듈에 대한 지원을 추가했습니다. Azure PowerShell 작업 버전 3.*은 AzureRM 모듈을 계속 지원합니다. 그러나 최신 Azure 서비스 및 기능을 따라가려면 가능한 한 빨리 Azure PowerShell 작업 버전 4.*로 전환하는 것이 좋습니다.
Az 모듈에는 새 구문을 사용하도록 업데이트하는 동안 기존 스크립트를 사용하는 데 도움이 되는 호환성 모드가 있습니다. Az 모듈에 대한 호환성을 사용하도록 설정하려면 Enable-AzureRmAlias 명령을 사용합니다. 별칭을 사용하면 Az 모듈에서 이전 cmdlet 이름을 사용할 수 있습니다. 자세한 내용은 Azure RM 모듈에서 Azure PowerShell Az 모듈로 마이그레이션하는 에서 확인할 수 있습니다.
비고
프라이빗 에이전트를 사용하는 경우 에이전트 컴퓨터에 Az 모듈을 설치해야 합니다.
Azure PowerShell Az 모듈에 대한 자세한 내용은 설명서를 참조하세요.
리소스 권한 부여 개선
YAML 파일에서 참조할 때 보호된 리소스(예: 서비스 연결, 변수 그룹, 에이전트 풀, 보안 파일)에 대한 보안을 제공해야 했습니다. 동시에 비프로덕션 시나리오에 이러한 유형의 리소스를 사용하는 파이프라인을 보다 쉽게 설정하고 사용할 수 있도록 하고자 했습니다. 이전에는 리소스를 '모든 파이프라인에서 사용할 수 있는 권한'으로 표시하는 설정을 추가했습니다.
이 업데이트를 통해 리소스를 표시하지 않은 경우에도 리소스 권한 부여 문제를 보다 쉽게 해결할 수 있습니다. 새 환경에서 리소스 권한 부여 오류로 인해 빌드가 실패하면 파이프라인에서 해당 리소스의 사용을 명시적으로 승인한 다음 계속 진행하는 옵션이 표시됩니다. 리소스에 권한을 부여할 수 있는 권한이 있는 팀 구성원은 실패한 빌드에서 바로 이 작업을 완료할 수 있습니다.
빌드 파이프라인의 간소화된 데이터 보존 정책
YAML 빌드를 비롯한 모든 빌드 파이프라인에 대한 보존 모델을 간소화했습니다. 프로젝트 수준에는 각 파이프라인의 빌드를 보존하려는 일 수와 각 빌드의 아티팩트를 보존하려는 일 수를 제어할 수 있는 새 설정이 있습니다. 클래식 편집기를 사용하여 빌드 파이프라인을 만든 경우 이전 보존 설정은 계속 적용되지만 최신 파이프라인은 새 설정을 사용합니다. 프로젝트 설정의 파이프라인 설정 페이지에서 보존을 관리할 수 있습니다.
릴리스에서 파이프라인 아티팩트가 자동으로 가져옵니다.
이전에는 릴리스에 연결된 빌드 파이프라인이 파이프라인 아티팩트 게시 작업을 사용하여 아티팩트를 게시한 경우 아티 팩 트가 릴리스에서 자동으로 페치되지 않았습니다. 대신 릴리스 파이프라인에 파이프라인 아티팩트 다운로드 작업을 명시적으로 추가하여 아티팩트를 다운로드해야 했습니다.
이제 빌드 파이프라인에서 게시한 모든 파이프라인 아티팩트가 자동으로 다운로드되어 릴리스에서 사용할 수 있게 됩니다. 릴리스 파이프라인의 단계 속성에서 파이프라인 아티팩트 다운로드를 사용자 지정할 수도 있습니다.
Cobertura 코드 검사 보고서 업데이트
이전에는 파이프라인에서 테스트를 실행하고 Azure DevOps에 코드 검사 결과를 게시할 때 XML 요약과 HTML 보고서 파일을 모두 지정해야 했습니다. 또한 HTML 보고서의 스타일은 코드 검사 탭에서 렌더링되기 전에 제거되었습니다. 임의 HTML 파일을 업로드할 수 있으므로 보안 관점에서 이 스타일 제거가 필요했습니다.
이 업데이트를 통해 Cobertura 검사 보고서에 대한 이러한 제한 사항을 해결했습니다. 코드 검사 보고서를 게시할 때 더 이상 HTML 파일을 지정할 필요가 없습니다. 보고서는 자동으로 생성되고 코드 검사 탭에서 적절한 스타일 지정으로 렌더링됩니다. 이 기능은 오픈 소스 도구 ReportGenerator를 사용합니다.
보고
빌드 실패 및 소요 시간 보고서
파이프라인의 처리량과 안정성을 지속적으로 개선하기 위해 메트릭과 인사이트를 갖는 것이 중요합니다. 파이프라인 분석을 제공하는 첫 번째 단계로, 파이프라인에 대한 메트릭과 인사이트를 제공하기 위해 두 개의 보고서를 추가했습니다.
실패 보고서에는 빌드 통과율 및 실패 추세가 표시됩니다. 또한 태스크 실패 추세를 표시하여 최대 오류 수에 기여하는 태스크에 대한 인사이트를 제공합니다.
기간 보고서에는 추세와 함께 파이프라인 기간이 포함될 것입니다.
Analytics의 일반 제공
추가 비용 없이 다음 분석 기능이 Azure DevOps에 포함될 예정임을 발표하게 되어 기쁩니다.
분석 위젯은 대시보드에 데이터를 표시하고 작업의 진행 상황을 모니터링하는 데 도움이 되는 구성 가능한 모듈입니다. 포함된 위젯은 다음과 같습니다.
번다운 및 번업 차트는 일정 기간 동안 범위가 지정된 작업 집합의 진행률을 모니터링합니다.
팀의 개발 주기를 통해 작업이 이동하는 방식을 시각화하는 주기 시간 및 리드 타임
CFD(누적 흐름 다이어그램) 는 다양한 상태를 진행하면서 작업 항목을 추적합니다.
속도 는 팀이 여러 스프린트에서 가치를 제공하는 방법을 추적합니다.
테스트 결과 추세 는 테스트 추세를 모니터링하고, 단일 또는 여러 파이프라인을 통해 테스트에 대한 실패 및 기간 패턴을 검색합니다.
제품에서는 파이프라인 안정성을 개선하고 테스트 부채를 줄이는 데 도움이 되는 파이프라인의 주요 실패 테스트에 대한 인사이트를 얻기 위해 가장 실패한 테스트 보고서를 포함하고 있습니다.
또한 모든 Azure DevOps Services 고객에게 미리 보기 상태로 제공되는 분석 보기를 통한 Power BI 통합과 OData 엔드포인트에 대한 직접 액세스를 계속 제공합니다.
Analytics 마켓플레이스 확장을 사용하는 경우 이전처럼 분석을 계속 사용할 수 있으며 추가 단계를 따를 필요가 없습니다. 즉, 호스트된 고객에 대한 Analytics 마켓플레이스 확장을 더 이상 사용하지 않습니다.
Azure DevOps Analytics 제품은 보고의 미래이며 Analytics에서 구동하는 새로운 기능에 계속 투자할 것입니다. 분석에 대한 자세한 내용은 아래 링크에서 확인할 수 있습니다.
위키
위키 페이지의 알림
지금까지는 위키 페이지의 콘텐츠가 변경된 시기를 알 수 없었습니다. 이제 위키 페이지를 따라 페이지가 편집, 삭제 또는 이름이 변경될 때 전자 메일을 통해 알림을 받을 수 있습니다. 위키에 대한 변경 내용을 추적하려면 위키 페이지에서 팔로우 단추를 선택합니다.
이 기능은 이 제안 티켓의 따라 우선 순위가 지정되었습니다. 자세한 내용은 여기 설명서참조하세요.
관리
Azure DevOps에서 조직의 청구 관리
이제 Azure DevOps 포털에서 조직의 청구를 관리할 수 있음을 알려드리겠습니다. 관리자는 더 이상 Azure Portal을 통해 청구를 설정할 필요가 없습니다. 청구 설정을 관리하려면 조직 설정 으로 이동하여 청구를 선택합니다.
다음은 청구 탭에서 관리할 수 있는 설정 목록입니다.
청구에 사용할 Azure 구독을 선택할 수 있습니다.
다른 구독을 선택하여 조직에서 청구에 사용하는 Azure 구독을 변경할 수 있습니다. 이전에는 청구를 제거한 다음 각 유료 리소스(기본 사용자, 패키지 관리 사용자, MS 호스트된 파이프라인 등)에 대해 동일한 수준을 신중하게 재구매해야 했습니다. 이 프로세스는 지루하고 오류가 발생하기 쉽습니다. 이제 다른 구독을 선택하고 저장을 클릭하여 조직에서 청구에 사용하는 Azure 구독을 변경할 수 있습니다.
더 이상 Visual Studio Marketplace로 이동하여 청구 설정을 관리할 필요가 없습니다. 추가 기본, 테스트 관리자 및 패키지 관리(Azure Artifacts) 사용자에 대한 요금을 지불하는 기능을 추가했습니다. 새 청구 탭에서 조직에서 지불하는 사용자 수를 늘리거나 줄일 수 있습니다 .
다음 단계
비고
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 피드백 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
또한 Stack Overflow에서 커뮤니티로부터 조언을 얻고 질문에 대한 답변을 받을 수 있습니다.
감사
제레미 에블링