Azure DevOps Server 2020 릴리스 정보

| Developer Community시스템 요구 사항 | 사용 조건 | DevOps 블로그 | SHA-1 해시

이 문서에서는 Azure DevOps Server 최신 릴리스에 대한 정보를 찾을 수 있습니다.

Azure DevOps Server 배포 설치 또는 업그레이드에 대한 자세한 내용은 Azure DevOps Server 요구 사항을 참조하세요. Azure DevOps 제품을 다운로드하려면 Azure DevOps Server 다운로드 페이지를 방문하세요.

Azure DevOps Server 2020으로의 직접 업그레이드는 Azure DevOps Server 2019 또는 Team Foundation Server 2015 이상에서 지원됩니다. TFS 배포가 TFS 2010 이하에 있는 경우 Azure DevOps Server 2019로 업그레이드하기 전에 몇 가지 중간 단계를 수행해야 합니다. 자세한 내용은 온-프레미스에 Azure DevOps 설치 및 구성을 참조하세요.


2019년 Azure DevOps Server 2020년 Azure DevOps Server 안전하게 업그레이드

Azure DevOps Server 2020에는 프로젝트 수준 설정에 따라 작동하는 새 파이프라인 실행(빌드) 보존 모델이 도입되었습니다.

Azure DevOps Server 2020은 파이프라인 수준 보존 정책에 따라 빌드 보존을 다르게 처리합니다. 특정 정책 구성으로 인해 업그레이드 후 파이프라인 실행이 삭제됩니다. 수동으로 보존되었거나 릴리스에 의해 보존된 파이프라인 실행은 업그레이드 후에 삭제되지 않습니다.

Azure DevOps Server 2019에서 Azure DevOps Server 2020으로 안전하게 업그레이드하는 방법에 대한 자세한 내용은 블로그 게시물을 참조하세요.

Azure DevOps Server 2020.0.2 릴리스 날짜: 2022년 5월 17일

Azure DevOps Server 2020.0.2는 버그 수정의 롤업입니다. Azure DevOps Server 2020.0.2를 직접 설치하거나 Azure DevOps Server 2020 또는 Team Foundation Server 2013 이상에서 업그레이드할 수 있습니다.

참고

데이터 마이그레이션 도구는 이 릴리스 후 약 3주 후에 Azure DevOps Server 2020.0.2에 사용할 수 있습니다. 현재 가져오기에 지원되는 버전 목록은 여기서 볼 수 있습니다.

이 릴리스에는 다음에 대한 수정 사항이 포함되어 있습니다.

  • "다음 실행" 단추를 사용하여 빌드 큐를 건너뛸 수 없습니다. 이전에는 프로젝트 컬렉션 관리자만 "다음 실행" 단추를 사용하도록 설정했습니다.

  • 사용자의 Active Directory 계정을 사용하지 않도록 설정한 후 모든 개인용 액세스 토큰을 해지합니다.

Azure DevOps Server 2020.0.1 패치 9 릴리스 날짜: 2022년 1월 26일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020.0.1에 대한 패치를 릴리스했습니다.

  • 작업 항목에서 컨트롤을 사용할 때 전자 메일 알림이 @mention 전송되지 않았습니다.
  • 계정을 전환할 때 TF400813 오류를 수정합니다. 이 오류는 TFS 2018에서 Azure DevOps Server 2020.0.1로 업그레이드할 때 발생했습니다.
  • Project 개요 요약 페이지가 로드에 실패하는 문제를 해결합니다.
  • Active Directory 사용자 동기화 개선.
  • log4j 이진 파일에서 jndilookup 클래스를 제거하여 Elasticsearch 취약성을 해결했습니다.

설치 단계

  1. 패치 9를 사용하여 서버를 업그레이드합니다.
  2. HKLM:\Software\Elasticsearch\Version의 레지스트리 값을 확인합니다. 여기에 레지스트리 값이 없으면 문자열 값을 추가하고 버전을 5.4.1로 설정합니다(Name = Version, Value = 5.4.1).
  3. 추가 정보 파일에 안내된 대로 업데이트 명령 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update를 실행합니다. 원격 서버에 연결할 수 없습니다와 같은 경고가 반환될 수 있습니다. 업데이트가 완료될 때까지 다시 시도되므로 창을 닫지 마세요.

참고

Azure DevOps Server 및 Elasticsearch가 다른 컴퓨터에 설치된 경우 아래에 설명된 단계를 수행합니다.

  1. 패치 9를 사용하여 서버를 업그레이드합니다.
  2. HKLM:\Software\Elasticsearch\Version의 레지스트리 값을 확인합니다. 여기에 레지스트리 값이 없으면 문자열 값을 추가하고 버전을 5.4.1로 설정합니다(Name = Version, Value = 5.4.1).
  3. Elasticsearch 원격 파일 폴더에 C:\Program Files\{TFS Version Folder}\Search\zip 있는 zip 폴더의 내용을 복사합니다.
  4. Elasticsearch 서버 컴퓨터에서 실행 Configure-TFSSearch.ps1 -Operation update 합니다.

SHA-256 해시: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Azure DevOps Server 2020.0.1 패치 8 릴리스 날짜: 2021년 12월 15일

Azure DevOps Server 2020.0.1용 패치 8에는 다음에 대한 수정 사항이 포함되어 있습니다.

  • 사용자 지정 작업 항목 레이아웃 상태에 대한 지역화 문제입니다.
  • 전자 메일 알림 템플릿의 지역화 문제입니다.
  • 한 행에 동일한 링크가 여러 개 있을 때 콘솔 로그가 잘리는 문제입니다.
  • 필드에 대해 여러 NOTSAMEAS 규칙이 정의된 경우 NOTSAMEAS 규칙 평가와 관련된 문제입니다.

Azure DevOps Server 2020.0.1 패치 7 릴리스 날짜: 2021년 10월 26일

Azure DevOps Server 2020.0.1용 패치 7에는 다음에 대한 수정 사항이 포함되어 있습니다.

  • 이전에는 Azure DevOps Server GitHub Enterprise 서버에 대한 연결만 만들 수 있습니다. 이 패치를 사용하면 프로젝트 관리자가 GitHub.com에서 Azure DevOps Server 리포지토리 간에 연결을 만들 수 있습니다. 이 설정은 Project 설정 GitHub 연결 페이지에서 찾을 수 있습니다.
  • 테스트 계획 위젯 문제를 해결합니다. 테스트 실행 보고서에 결과에 잘못된 사용자가 표시되었습니다.
  • Project 개요 요약 페이지가 로드에 실패하는 문제를 해결합니다.
  • 제품 업그레이드를 확인하기 위해 전자 메일이 전송되지 않는 문제를 해결합니다.

Azure DevOps Server 2020.0.1 패치 6 릴리스 날짜: 2021년 9월 14일

Azure DevOps Server 2020.0.1용 패치 6에는 다음에 대한 수정 사항이 포함되어 있습니다.

  • Artifacts 다운로드/업로드 실패를 해결합니다.
  • 일관되지 않은 테스트 결과 데이터 문제를 해결합니다.

Azure DevOps Server 2020.0.1 패치 5 릴리스 날짜: 2021년 8월 10일

Azure DevOps Server 2020.0.1용 패치 5에는 다음에 대한 수정 사항이 포함되어 있습니다.

  • 빌드 정의 UI 오류를 수정합니다.
  • 루트 리포지토리 대신 파일을 표시하도록 검색 기록이 변경되었습니다.
  • 일부 작업 항목 유형의 전자 메일 배달 작업 문제를 해결합니다.

Azure DevOps Server 2020.0.1 패치 4 릴리스 날짜: 2021년 6월 15일

Azure DevOps Server 2020.0.1용 패치 4에는 다음에 대한 수정 사항이 포함되어 있습니다.

  • 데이터 가져오기 문제를 해결합니다. 부실 테스트 사례가 많은 고객에게는 데이터 가져오기에 오랜 시간이 소요되었습니다. 이는 테이블의 tbl_testCaseReferences 크기를 증가시킨 참조 때문입니다. 이 패치를 사용하여 데이터 가져오기 프로세스 속도를 높이기 위해 부실 테스트 사례에 대한 참조를 제거했습니다.

Azure DevOps Server 2020.0.1 패치 3 릴리스 날짜: 2021년 5월 11일

다음을 수정하는 Azure DevOps Server 2020.0.1에 대한 패치를 릴리스했습니다.

  • Microsoft.TeamFoundation.TestManagement.Client를 사용할 때 일치하지 않는 테스트 결과 데이터입니다.

Azure DevOps Server 2020.0.1이 있는 경우 Azure DevOps Server 2020.0.1 패치 3을 설치해야 합니다.

설치 확인

  • 옵션 1: 실행 devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe 위의 링크에서 다운로드한 파일입니다. 명령의 출력에 패치가 설치되었거나 설치되지 않았다고 표시됩니다.

  • 옵션 2: 다음 파일의 버전을 확인합니다 [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1은 기본적으로 설치됩니다c:\Program Files\Azure DevOps Server 2020. Azure DevOps Server 2020.0.1 패치 3을 설치한 후 버전은 18.170.31228.1이 됩니다.

Azure DevOps Server 2020.0.1 패치 2 릴리스 날짜: 2021년 4월 13일

참고

2020을 Azure DevOps Server 경우 먼저 Azure DevOps Server 2020.0.1로 업데이트해야 합니다. 2020.0.1에 Azure DevOps Server 2020.0.1 패치 2를 설치합니다.

다음을 수정하는 Azure DevOps Server 2020.0.1에 대한 패치를 릴리스했습니다.

이 패치에 대한 수정 사항을 구현하려면 일반 패치 설치, AzureResourceGroupDeploymentV2AzureResourceManagerTemplateDeploymentV3 작업 설치를 위해 아래에 나열된 단계를 따라야 합니다.

일반 패치 설치

Azure DevOps Server 2020.0.1이 있는 경우 Azure DevOps Server 2020.0.1 패치 2를 설치해야 합니다.

설치 확인

  • 옵션 1: 실행 devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe 위의 링크에서 다운로드한 파일입니다. 명령의 출력은 패치가 설치되었거나 설치되지 않았다고 말합니다.

  • 옵션 2: 다음 파일의 버전을 확인합니다 [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1은 기본적으로 설치됩니다c:\Program Files\Azure DevOps Server 2020. Azure DevOps Server 2020.0.1 패치 2를 설치한 후 버전은 18.170.31123.3이 됩니다.

AzureResourceGroupDeploymentV2 작업 설치

참고

아래에 언급된 모든 단계는 Windows 컴퓨터에서 수행해야 합니다.

설치

  1. 컴퓨터의 새 폴더에 AzureResourceGroupDeploymentV2.zip 패키지를 추출합니다. 예: D:\tasks\AzureResourceGroupDeploymentV2.

  2. 컴퓨터에 따라 14.15.1 및 npm(Node.js 다운로드와 함께 포함)을 다운로드하여 설치합니다.

  3. 관리자 모드에서 명령 프롬프트를 열고 다음 명령을 실행하여 tfx-cli를 설치합니다.

npm install -g tfx-cli
  1. 모든 액세스 권한으로 개인용 액세스 토큰을 만들고 복사합니다. 이 개인용 액세스 토큰은 tfx login 명령을 실행할 때 사용됩니다.

  2. 명령 프롬프트에서 다음 명령을 실행합니다. 메시지가 표시되면 서비스 URL 및 개인용 액세스 토큰을 입력합니다.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 다음 명령을 실행하여 서버에 작업을 업로드합니다. 1단계에서 추출한 .zip 파일의 경로를 사용합니다.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

AzureResourceManagerTemplateDeploymentV3 작업 설치

참고

아래에 언급된 모든 단계는 Windows 컴퓨터에서 수행해야 합니다.

설치

  1. 컴퓨터의 새 폴더에 AzureResourceManagerTemplateDeploymentV3.zip 패키지를 추출합니다. 예: D:\tasks\AzureResourceManagerTemplateDeploymentV3.

  2. 컴퓨터에 적합한 Node.js 14.15.1 및 npm(Node.js 다운로드에 포함)를 다운로드하여 설치합니다.

  3. 관리자 모드에서 명령 프롬프트를 열고 다음 명령을 실행하여 tfx-cli를 설치합니다.

npm install -g tfx-cli
  1. 모든 액세스 권한으로 개인용 액세스 토큰을 만들고 복사합니다. 이 개인용 액세스 토큰은 tfx login 명령을 실행할 때 사용됩니다.

  2. 명령 프롬프트에서 다음 명령을 실행합니다. 메시지가 표시되면 서비스 URL 및 개인용 액세스 토큰을 입력합니다.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 다음 명령을 실행하여 서버에 작업을 업로드합니다. 1단계에서 추출한 .zip 파일의 경로를 사용합니다.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 패치 1 릴리스 날짜: 2021년 2월 9일

다음을 수정하는 Azure DevOps Server 2020.0.1용 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

Azure DevOps Server 2020 패치 3 릴리스 날짜: 2021년 2월 9일

다음을 수정하는 Azure DevOps Server 2020에 대한 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

Azure DevOps Server 2020.0.1 릴리스 날짜: 2021년 1월 19일

Azure DevOps Server 2020.0.1은 버그 수정의 롤업입니다. Azure DevOps Server 2020.0.1을 직접 설치하거나 기존 설치에서 업그레이드할 수 있습니다. 업그레이드에 지원되는 버전은 Azure DevOps Server 2020, Azure DevOps Server 2019 및 Team Foundation Server 2012 이상입니다.

이 릴리스에는 다음과 같은 버그에 대한 수정 사항이 포함되어 있습니다.

  • 업그레이드 후 Git 프록시가 작동을 중지할 수 있는 Azure DevOps Server 2019의 업그레이드 문제를 해결합니다.
  • Azure DevOps Server 2020으로 업그레이드할 때 Team Foundation Server 2017 이전의 비 ENU 컬렉션에 대한 System.OutOfMemoryException 예외를 수정합니다. 이 Developer Community 피드백 티켓에 보고된 문제를 해결합니다.
  • Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll 누락으로 인한 서비스 오류입니다. 이 Developer Community 피드백 티켓에 보고된 문제를 해결합니다.
  • Azure DevOps Server 2020으로 업그레이드하는 동안 Analytics에서 잘못된 열 이름 오류를 수정합니다. 이 Developer Community 피드백 티켓에 보고된 문제를 해결합니다.
  • 테스트 사례 결과에 테스트 사례 단계를 표시할 때 저장된 XSS입니다.
  • 지점 결과 데이터를 TCM으로 마이그레이션하는 동안 단계 오류를 업그레이드합니다.

Azure DevOps Server 2020 패치 2 릴리스 날짜: 2021년 1월 12일

다음을 수정하는 Azure DevOps Server 2020에 대한 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

  • 테스트 실행 세부 정보는 OpsHub 마이그레이션을 사용하여 마이그레이션된 테스트 데이터에 대한 테스트 단계 세부 정보를 표시하지 않습니다.
  • 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger'에 대한 이니셜라이저에 대한 예외
  • 2020년 Azure DevOps Server 마이그레이션 후 확인되지 않은 빌드가 즉시 삭제됩니다.
  • 데이터 공급자 예외 수정

Azure DevOps Server 2020 패치 1 날짜: 2020년 12월 8일

다음을 수정하는 Azure DevOps Server 2020에 대한 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

  • CVE-2020-17145 : Azure DevOps Server 및 Team Foundation Services 스푸핑 취약성

Azure DevOps Server 2020 릴리스 날짜: 2020년 10월 6일

Azure DevOps Server 2020은 버그 수정의 롤업입니다. 여기에는 이전에 릴리스된 Azure DevOps Server 2020 RC2의 모든 기능이 포함됩니다.

참고

Azure DevOps 2020 Server에는 GVFS(Git 가상 파일 시스템)에서 사용하는 어셈블리 중 하나를 설치하는 데 문제가 있습니다.

Azure DevOps 2019(모든 릴리스) 또는 Azure DevOps 2020 릴리스 후보에서 업그레이드하고 이전 릴리스와 동일한 디렉터리에 설치하는 경우 어셈블리 Microsoft.TeamFoundation.Git.dll 가 설치되지 않습니다. 폴더 및 <Install Dir>\Tools 폴더를 <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Version Control Proxy\Web Services\bin검색 Microsoft.TeamFoundation.Git.dll 하여 문제가 발생했는지 확인할 수 있습니다. 파일이 누락된 경우 복구를 실행하여 누락된 파일을 복원할 수 있습니다.

복구를 실행하려면 Azure DevOps Server 컴퓨터/VM으로 이동하여 Settings -> Apps & Features Azure DevOps 2020 Server에서 복구를 실행합니다. 복구가 완료되면 컴퓨터/VM을 다시 시작할 수 있습니다.

Azure DevOps Server RC2 릴리스 날짜: 2020년 8월 11일

Azure DevOps Server RC2는 버그 수정의 롤업입니다. 여기에는 이전에 릴리스된 Azure DevOps Server RC1의 모든 기능이 포함되어 있습니다.

Azure DevOps Server RC1 릴리스 날짜: 2020년 7월 10일

이 Developer Community 피드백 티켓을 수정하기 위해 Azure DevOps Server RC1을 다시 릴리스했습니다.

이전에는 Azure DevOps Server 2019 업데이트 1.1에서 Azure DevOps Server 2020 RC1로 업그레이드한 후 웹 UI의 Repos, Pipelines 및 Wiki에서 파일을 볼 수 없었습니다. 페이지의 이 지역 내에서 예기치 않은 오류가 발생했음을 나타내는 오류 메시지가 있었습니다. 이 구성 요소를 다시 로드하거나 전체 페이지를 새로 고치면 됩니다. 이 릴리스에서는 이 문제를 해결했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

Azure DevOps Server RC1 릴리스 날짜: 2020년 6월 30일

2020년 Azure DevOps Server 새로운 기능 요약

Azure DevOps Server 2020에는 많은 새로운 기능이 도입되었습니다. 몇 가지 중요한 기능은 다음과 같습니다.

개별 섹션으로 이동하여 각 서비스에 대한 모든 새로운 기능을 볼 수도 있습니다.


일반

Azure DevOps CLI 일반 공급

2월에는 Azure CLI에 대한 Azure DevOps 확장을 도입했습니다. 확장을 사용하면 명령줄에서 Azure DevOps 조작할 수 있습니다. 확장을 개선하고 더 많은 명령을 추가하는 데 도움이 되는 피드백을 수집했습니다. 이제 확장이 일반 공급된다는 것을 발표하게 되어 기쁩니다.

AZURE DEVOPS CLI에 대한 자세한 내용은 여기 설명서를 참조하세요.

게시 프로필을 사용하여 배포 센터에서 Windows Azure WebApps 배포

이제 게시 프로필 기반 인증을 사용하여 배포 센터에서 Windows Azure WebApps를 배포할 수 있습니다. 게시 프로필을 사용하여 Windows Azure WebApp에 배포할 수 있는 권한이 있는 경우 배포 센터 워크플로에서 이 프로필을 사용하여 파이프라인을 설정할 수 있습니다.

Boards

작업 보드 및 스프린트 백로그에 "부모 작업 항목" 필터 추가

스프린트 보드와 스프린트 백로그 모두에 새 필터를 추가했습니다. 이렇게 하면 부모별로 요구 사항 수준 백로그 항목(왼쪽의 첫 번째 열)을 필터링할 수 있습니다. 예를 들어 아래 스크린샷에서는 부모가 "내 큰 기능"인 사용자 스토리만 표시하도록 보기를 필터링했습니다.

Screenshot showing the new Parent Work Item filter.

오류 처리 환경 개선 – 버그/작업에 필요한 필드

지금까지 Kanban 보드에서 작업 항목을 한 열에서 다른 열로 이동한 경우 상태 변경으로 인해 필드 규칙이 트리거된 경우 카드에 빨간색 오류 메시지가 표시되어 근본 원인을 이해하기 위해 작업 항목을 열어야 합니다. 스프린트 170에서는 이제 작업 항목 자체를 열지 않고도 빨간색 오류 메시지를 클릭하여 오류의 세부 정보를 볼 수 있도록 환경을 개선했습니다.

Screenshot showing the Missing fields dialog box that appears when you click the red error message.

작업 항목 라이브 다시 로드

이전에는 작업 항목을 업데이트할 때 두 번째 팀 구성원이 동일한 작업 항목을 변경할 때 두 번째 사용자가 변경 내용을 잃게 됩니다. 이제 둘 다 다른 필드를 편집하는 한 작업 항목에 대한 변경 내용의 실시간 업데이트가 표시됩니다.

Short video showing how the work item live reload works.

명령줄에서 반복 및 영역 경로 관리

이제 명령줄 및 명령을 사용하여 az boards iteration 명령줄에서 반복 및 az boards area 영역 경로를 관리할 수 있습니다. 예를 들어 CLI에서 대화형으로 반복 및 영역 경로를 설정 및 관리하거나 스크립트를 사용하여 전체 설정을 자동화할 수 있습니다. 명령 및 구문에 대한 자세한 내용은 여기 설명서를 참조 하세요.

작업 항목 부모 열을 열로 사용 옵션

이제 제품 백로그 또는 스프린트 백로그에서 모든 작업 항목의 부모를 볼 수 있는 옵션이 있습니다. 이 기능을 사용하려면 원하는 백로그의 열 옵션 으로 이동한 다음 부모 열을 추가합니다.

Screenshot of a backlog with the Column Options option called out.

프로젝트에서 사용하는 프로세스 변경

도구는 팀처럼 변경되어야 하며, 이제 프로젝트를 기본 제공 프로세스 템플릿에서 다른 기본 프로세스로 전환할 수 있습니다. 예를 들어 프로젝트를 Agile에서 스크럼으로, 기본에서 Agile로 변경할 수 있습니다. 여기에서 전체 단계별 설명서를 찾을 수 있습니다.

Screenshot of the Projects tab with the Change process option called out.

레이아웃에서 사용자 지정 필드 숨기기

이제 프로세스를 사용자 지정할 때 양식 레이아웃에서 사용자 지정 필드를 숨길 수 있습니다. 이 필드는 쿼리 및 REST API에서 계속 사용할 수 있습니다. 이는 다른 시스템과 통합할 때 추가 필드를 추적하는 데 편리합니다.

Screenshot showing the Hide from layout option.

세 가지 새로운 Azure Boards 보고서를 사용하여 팀의 상태에 대한 인사이트를 얻습니다.

볼 수 없는 항목을 수정할 수 없습니다. 따라서 작업 프로세스의 상태와 상태를 주의 깊게 관찰하려고 합니다. 이러한 보고서를 사용하면 Azure Boards 최소한의 노력으로 중요한 메트릭을 더 쉽게 추적할 수 있습니다.

세 가지 새로운 대화형 보고서는 번다운, CFD(누적 Flow 다이어그램) 및 속도입니다. 새 분석 탭에서 보고서를 볼 수 있습니다.

스프린트 번다운, 작업 흐름 및 팀 속도와 같은 메트릭은 팀의 진행 상황을 파악하고 다음과 같은 질문에 답변하는 데 도움이 됩니다.

  • 이 스프린트에서 남은 작업은 얼마나 될까요? 우리는 그것을 완료하기 위해 궤도에 있습니까?
  • 개발 프로세스의 어떤 단계가 가장 오래 걸리나요? 우리는 그것에 대해 뭔가를 할 수 있습니까?
  • 이전 반복에 따라 다음 스프린트에 대해 얼마나 많은 작업을 계획해야 하나요?

참고

헤더에 이전에 표시된 차트는 이러한 향상된 보고서로 대체되었습니다.

새 보고서는 완전히 대화형이며 필요에 맞게 조정할 수 있습니다. 각 허브의 분석 탭 에서 새 보고서를 찾을 수 있습니다.

  • 번다운 차트는 스프린트 허브에서 찾을 수 있습니다 .

    Screenshot of the burndown chart on the Analytics tab.

  • CFD 및 속도 보고서는 관련 카드를 클릭하여 Boards백로그 아래의 분석 탭에서 액세스할 수 있습니다.

    Screenshot of the Cumulative Flow Diagram report and Velocity report on the Analytics tab.

새 보고서를 사용하면 팀에 대한 더 많은 제어 및 정보를 사용할 수 있습니다. 몇 가지 예제는 다음과 같습니다.

  • 스프린트 번다운 및 속도 보고서는 작업 항목 수 또는 남은 작업의 합계를 사용하도록 설정할 수 있습니다.
  • 프로젝트 날짜에 영향을 주지 않고 스프린트 번다운의 시간 범위를 조정할 수 있습니다. 따라서 팀에서 일반적으로 각 스프린트 계획의 첫날을 보내는 경우 이제 차트를 일치하여 이를 반영할 수 있습니다.
  • 이제 번다운 차트에는 주말을 보여주는 워터마크가 있습니다.
  • CFD 보고서를 사용하면 디자인과 같은 보드 열을 제거하여 팀이 제어할 수 있는 흐름에 더 집중할 수 있습니다.

다음은 스토리 백로그의 지난 30일 동안의 흐름을 보여 주는 CFD 보고서의 예입니다.

Screenshot of the Cumulative Flow Diagram on the Analytics tab.

이제 모든 백로그 수준에 대해 속도 차트를 추적할 수 있습니다. 예를 들어 이제 기능과 에픽을 모두 추가할 수 있지만 이전 차트 앞에는 요구 사항만 지원됩니다. 다음은 기능 백로그의 마지막 6회 반복에 대한 속도 보고서의 예입니다.

Screenshot of the Velocity chart on the Analytics tab.

작업표 열 사용자 지정

작업 보드에서 열을 사용자 지정할 수 있는 옵션이 추가되었다는 사실을 알려드리게 되어 기쁩니다. 이제 열을 추가, 제거, 이름 바꾸기 및 다시 정렬할 수 있습니다.

작업 보드에서 열을 구성하려면 열 옵션으로 이동합니다.

Screenshot of a Taskboard with the Column Options option called out.

이 기능은 Developer Community 제안에 따라 우선 순위가 지정되었습니다.

백로그에서 완료된 자식 작업 항목을 표시하거나 숨기도록 설정/해제

백로그를 구체화할 때 완료되지 않은 항목만 보려고 하는 경우가 많습니다. 이제 백로그에서 완료된 자식 항목을 표시하거나 숨길 수 있습니다.

토글이 켜지면 모든 자식 항목이 완료된 상태로 표시됩니다. 토글이 꺼져 있으면 완료된 상태의 모든 자식 항목이 백로그에서 숨겨집니다.

Short video that shows how to show or hide child items on the backlog.

작업 항목에 태그를 지정할 때 표시되는 가장 최근 태그

작업 항목에 태그를 지정할 때 자동 완성 옵션은 이제 가장 최근에 사용한 태그를 최대 5개까지 표시합니다. 이렇게 하면 작업 항목에 올바른 정보를 더 쉽게 추가할 수 있습니다.

Screenshot showing the most recent used tags displayed when tagging a work item.

그룹 멤버 자격에 대한 읽기 전용 및 필수 규칙

작업 항목 규칙을 사용하면 작업 항목 필드에 대한 특정 작업을 설정하여 동작을 자동화할 수 있습니다. 그룹 멤버 자격에 따라 필드를 읽기 전용 또는 필수로 설정하는 규칙을 만들 수 있습니다. 예를 들어 제품 소유자에게 기능의 우선 순위를 설정하는 동시에 다른 모든 사용자에게 읽기 전용으로 설정할 수 있는 기능을 부여할 수 있습니다.

Screenshot of the New work item rule dialog box showing the Conditions section and the Actions section.

시스템 선택 목록 값 사용자 지정

이제 심각도, 활동, 우선 순위 등과 같은 모든 시스템 선택 목록(이유 필드 제외)에 대한 값을 사용자 지정할 수 있습니다. 선택 목록 사용자 지정은 각 작업 항목 유형에 대해 동일한 필드에 대해 서로 다른 값을 관리할 수 있도록 범위가 지정됩니다.

Short video that shows how to customize system picklist values.

새 작업 항목 URL 매개 변수

새 작업 항목 URL 매개 변수를 사용하여 보드 또는 백로그의 컨텍스트와 작업 항목에 대한 링크를 공유합니다. 이제 URL에 매개 변수 ?workitem=[ID] 를 추가하여 보드, 백로그 또는 스프린트 환경에서 작업 항목 대화 상자를 열 수 있습니다.

링크를 공유하는 모든 사용자는 링크를 공유할 때와 동일한 컨텍스트로 연결됩니다.

텍스트 필드에 사용자, 작업 항목 및 PR 언급

여러분의 의견을 들어보았을 때, 댓글뿐 아니라 작업 항목 설명 영역(및 기타 HTML 필드)에서 사람, 작업 항목 및 PR을 언급하는 기능을 원한다고 들었습니다. 작업 항목에서 다른 사용자와 공동 작업하거나 작업 항목 설명에서 PR을 강조 표시하려고 하지만 해당 정보를 추가할 방법이 없는 경우가 있습니다. 이제 작업 항목의 모든 긴 텍스트 필드에 사람, 작업 항목 및 PR을 언급할 수 있습니다.

여기에서 예제를 확인할 수 있습니다.

Screenshot showing that you can mention people, work items, and PRs in the work item Description area.

  • 사용자 멘션을 사용하려면 멘션할 사람 이름과 기호를 입력 @ 합니다. @mentions 작업 항목 필드에 주석에 대해 수행하는 것과 같은 전자 메일 알림이 생성됩니다.
  • 작업 항목 멘션을 사용하려면 작업 항목 ID 또는 제목 뒤에 기호를 입력 # 합니다. #mentions 두 작업 항목 간에 링크를 만듭니다.
  • PR 멘션을 사용하려면 ! 뒤에 PR ID 또는 이름을 추가합니다.

토론 댓글에 대한 반응

우리의 주요 목표 중 하나는 팀을 위해 작업 항목을 보다 공동으로 만드는 것입니다. 최근에 우리는 트위터에서 설문 조사를 실시하여 작업 항목에 대한 토론에서 원하는 공동 작업 기능을 알아 냈다. 댓글에 반응을 가져 오는 것은 설문 조사를 이겼다, 그래서 우리는 그들을 추가! 다음은 트위터 투표의 결과입니다.

Screenshot of the Azure DevOps twitter poll showing that 35% of the respondents wanted the Reactions on comments feature.

댓글에 반응을 추가할 수 있으며, 댓글의 오른쪽 위 모서리에 있는 웃는 아이콘과 기존 반응 옆에 있는 댓글의 아래쪽에 있는 두 가지 방법으로 반응을 추가할 수 있습니다. 원하는 경우 6개의 반응을 모두 추가하거나 하나 또는 두 개만 추가할 수 있습니다. 당신의 반응을 제거하려면, 당신의 의견의 하단에 반응을 클릭하면 제거됩니다. 아래에서 반응을 추가하는 경험뿐만 아니라 댓글에 대한 반응의 모양을 볼 수 있습니다.

Screenshot showing that you can add reactions to comments two different ways.

대시보드에 Azure Boards 보고서 고정

스프린트 155 업데이트에는 업데이트된 버전의 CFD 및 속도 보고서가 포함되어 있습니다. 이러한 보고서는 Boards 및 백로그의 분석 탭에서 사용할 수 있습니다. 이제 대시보드에 보고서를 직접 고정할 수 있습니다. 보고서를 고정하려면 보고서를 마우스로 가리키고 줄임표 "..."를 선택합니다. 메뉴 및 대시보드에 복사합니다.

Screenshot showing the Copy to Dashboard option.

Boards 백로그에서 롤업을 사용하여 부모 항목의 진행률 추적

롤업 열에는 계층 내의 숫자 필드 또는 하위 항목의 진행률 표시줄 및/또는 합계가 표시됩니다. 하위 항목은 계층 내의 모든 자식 항목에 해당합니다. 제품 또는 포트폴리오 백로그에 하나 이상의 롤업 열을 추가할 수 있습니다.

예를 들어 여기서는 닫힌 하위 항목의 백분율에 따라 오름차순 작업 항목의 진행률 표시줄을 표시하는 작업 항목별 진행 률을 보여 줍니다. Epics의 하위 항목에는 모든 자식 기능과 자식 또는 그랜드 자식 작업 항목이 포함됩니다. 기능의 하위 항목에는 모든 자식 사용자 스토리와 자식 작업 항목이 포함됩니다.

Screenshot of work items in a backlog.

작업표 라이브 업데이트

이제 변경 내용이 발생하면 작업 보드가 자동으로 새로 고쳐집니다. 다른 팀 구성원이 작업 보드에서 카드를 이동하거나 순서를 변경하면 보드가 이러한 변경 내용으로 자동으로 업데이트됩니다. 최신 변경 내용을 보려면 더 이상 F5 키를 누를 필요가 없습니다.

롤업 열의 사용자 지정 필드 지원

이제 사용자 지정 필드를 비롯한 모든 필드에서 롤업을 수행할 수 있습니다. 롤업 열을 추가할 때 빠른 목록에서 롤업 열을 선택할 수 있지만 기본 프로세스 템플릿의 일부가 아닌 숫자 필드를 롤업하려면 다음과 같이 직접 구성할 수 있습니다.

  1. 백로그에서 "열 옵션"을 클릭합니다. 그런 다음 패널에서 "롤업 열 추가"를 클릭하고 사용자 지정 롤업을 구성합니다.

    Screenshot of the Add a rollup column dropdown list.

  2. 진행률 표시줄합계 중에서 선택합니다.
  3. 작업 항목 유형 또는 백로그 수준을 선택합니다(일반적으로 백로그는 여러 작업 항목 유형을 집계합니다).
  4. 집계 유형을 선택합니다. 작업 항목 또는 합계의 수입니다. 합계의 경우 요약할 필드를 선택해야 합니다.
  5. 확인 단추를 누르면 새 사용자 지정 열의 순서를 변경할 수 있는 열 옵션 패널로 돌아갑니다.

Screenshot of the column options panel showing the new custom column.

확인을 클릭한 후에는 사용자 지정 열을 편집할 수 없습니다. 변경해야 하는 경우 사용자 지정 열을 제거하고 원하는 대로 다른 열을 추가합니다.

조건에 따라 작업 항목 양식의 필드를 숨기는 새 규칙

작업 항목 양식에서 필드를 숨길 수 있도록 상속된 규칙 엔진에 새 규칙을 추가했습니다. 이 규칙은 사용자 그룹 멤버 자격에 따라 필드를 숨깁니다. 예를 들어 사용자가 "제품 소유자" 그룹에 속하는 경우 개발자 특정 필드를 숨길 수 있습니다. 자세한 내용은 여기 설명서를 참조 하세요.

사용자 지정 작업 항목 알림 설정

사용자 또는 팀과 관련된 작업 항목을 최신 상태로 유지하는 것이 매우 중요합니다. 이는 팀이 프로젝트를 공동 작업하고 계속 진행하는 데 도움이 되며 모든 올바른 당사자가 참여하도록 합니다. 그러나 이해 관계자가 서로 다른 노력에 대해 서로 다른 수준의 투자를 하고 있으며, 작업 항목의 상태를 따르는 능력에 반영되어야 한다고 생각합니다.

이전에는 작업 항목을 따르고 변경 내용에 대한 알림을 받으려는 경우 작업 항목에 대한 모든 변경 내용에 대한 전자 메일 알림을 받게 됩니다. 피드백을 고려한 후에는 모든 관련자를 위해 작업 항목을 보다 유연하게 팔로우할 수 있도록 하고 있습니다. 이제 작업 항목의 오른쪽 위 모서리에 팔로우 단추 옆에 새 설정 단추가 표시됩니다. 그러면 다음 옵션을 구성할 수 있는 팝업으로 이동합니다.

Screenshot of the upper-right corner of a work item with the cursor hovering over the gear icon.

알림 설정 세 가지 알림 옵션 중에서 선택할 수 있습니다. 첫째, 구독을 완전히 취소할 수 있습니다. 둘째, 모든 작업 항목 변경에 대한 알림을 받는 완전히 구독할 수 있습니다. 마지막으로, 일부 주요 작업 항목 변경 이벤트에 대한 알림을 받도록 선택할 수 있습니다. 하나 또는 세 가지 옵션 모두를 선택할 수 있습니다. 이렇게 하면 팀 구성원이 더 높은 수준에서 작업 항목을 따르고 변경되는 모든 변경 내용에 주의를 빼앗기지 않습니다. 이 기능을 사용하면 불필요한 전자 메일을 제거하고 현재 진행 중인 중요한 작업에 집중할 수 있습니다.

Screenshot of the Notifications Settings dialog box showing the Custom radio button selected along with the State Changed option and the Iteration Changed option.

작업 항목 양식에서 배포 제어를 릴리스하게 되어 기쁩니다. 이 컨트롤은 작업 항목을 릴리스에 연결하고 작업 항목이 배포된 위치를 쉽게 추적할 수 있도록 합니다. 자세한 내용은 여기에서 설명서를 참조 하세요.

Screenshot showing the Deployment control on the work item form.

CSV 파일에서 작업 항목 가져오기

지금까지 CSV 파일에서 작업 항목을 가져오는 것은 Excel 플러그 인을 사용하는 데 의존했습니다. 이 업데이트에서는 새 작업 항목을 가져오거나 기존 작업 항목을 업데이트할 수 있도록 Azure Boards 직접 첫 번째 클래스 가져오기 환경을 제공합니다. 자세한 내용은 여기에서 설명서를 참조 하세요.

Short video that shows how to import work items from a CSV file.

작업 항목 카드에 부모 필드 추가

이제 Kanban 보드 내에서 부모 컨텍스트를 작업 항목 카드의 새 필드로 사용할 수 있습니다. 이제 태그 및 접두사와 같은 해결 방법을 사용할 필요가 없도록 카드에 부모 필드를 추가할 수 있습니다.

Screenshot showing a work item card with the Parent option called out.

백로그 및 쿼리에 부모 필드 추가

이제 백로그 및 쿼리 결과를 볼 때 부모 필드를 사용할 수 있습니다. 부모 필드를 추가하려면 열 옵션 보기를 사용합니다.

Screenshot of the Column options section with the Parent option called out.

Repos

끌어오기 요청에 대한 코드 검사 메트릭 및 분기 정책

이제 PR(끌어오기 요청) 보기 내에서 변경 내용에 대한 코드 검사 메트릭을 볼 수 있습니다. 이렇게 하면 자동화된 테스트를 통해 변경 내용을 적절하게 테스트할 수 있습니다. 적용 범위 상태는 PR 개요에 주석으로 표시됩니다. 파일 차이 보기에서 변경된 모든 코드 줄에 대한 검사 정보의 세부 정보를 볼 수 있습니다.

Screenshot showing that you can see code coverage metrics for changes within the pull request (PR) view.

Screenshot of a pull request diff showing a new line of code added to a file.

또한 리포지토리 소유자는 이제 코드 검사 정책을 설정하고 테스트되지 않은 대규모 변경 내용이 분기에 병합되지 않도록 방지할 수 있습니다. 원하는 검사 임계값은 리포지토리의 루트에서 체크 인된 설정 파일에서 정의 azurepipelines-coverage.yml 할 수 있으며 Azure Repos 추가 서비스 기능에 대한 기존 구성 분기 정책을 사용하여 검사 정책을 정의할 수 있습니다.

Screenshot of the Add status policy option called out and and the Add status policy section that appears when you select the option..

끌어오기 요청에서 주석 알림 필터링

끌어오기 요청의 주석은 종종 알림으로 인해 많은 노이즈를 생성할 수 있습니다. 댓글 연령, 주석 작성자, 삭제된 메모, 언급된 사용자, 끌어오기 요청 작성자, 대상 분기 및 스레드 참가자별로 구독하는 댓글 알림을 필터링할 수 있는 사용자 지정 구독을 추가했습니다. 오른쪽 위 모서리에 있는 사용자 아이콘을 클릭하고 사용자 설정으로 이동하여 이러한 알림 구독을 만들 수 있습니다.

Screenshot showing how to filter comment notifications from pull requests.

Screenshot showing the Filter criteria page and the contents of the Field dropdown list.

끌어오기 요청 주석에 대한 서비스 후크

이제 리포지토리 및 대상 분기를 기반으로 끌어오기 요청에서 주석에 대한 서비스 후크를 만들 수 있습니다.

Screenshot of the New Service Hooks Subscription wizard.

지정된 패턴의 파일을 차단하는 정책

이제 관리자는 파일 형식 및 경로에 따라 커밋이 리포지토리로 푸시되지 않도록 정책을 설정할 수 있습니다. 파일 이름 유효성 검사 정책은 제공된 패턴과 일치하는 푸시를 차단합니다.

Screenshot showing the Policies section with the File name validation option set to On.

키워드를 사용하여 커밋을 통해 작업 항목 확인

이제 수정, 수정 또는 수정과 같은 핵심 단어를 사용하여 기본 분기에 대한 커밋을 통해 작업 항목을 확인할 수 있습니다. 예를 들어 커밋 메시지의 "이 변경 내용 수정 #476"을 작성하면 커밋이 기본 분기에 푸시되거나 병합될 때 작업 항목 #476이 완료됩니다. 자세한 내용은 여기 설명서를 참조 하세요.

자동 검토자에 대한 세분성

이전에는 끌어오기 요청에 그룹 수준 검토자를 추가할 때 추가된 그룹에서 승인이 하나만 필요했습니다. 이제 자동 검토자를 추가할 때 팀에서 둘 이상의 검토자가 끌어오기 요청을 승인해야 하는 정책을 설정할 수 있습니다. 또한 요청자가 자신의 변경 내용을 승인하지 못하도록 정책을 추가할 수 있습니다.

Screenshot showing the Automatically include reviewers dialog box.

서비스 계정 기반 인증을 사용하여 AKS에 연결

이전에는 AKS 배포 센터에서 Azure Pipelines 구성할 때 Azure Resource Manager 연결을 사용했습니다. 이 연결은 파이프라인이 구성된 네임스페이스뿐만 아니라 전체 클러스터에 액세스할 수 있었습니다. 이 업데이트를 통해 파이프라인은 서비스 계정 기반 인증을 사용하여 클러스터에 연결하므로 파이프라인과 연결된 네임스페이스에만 액세스할 수 있습니다.

끌어오기 요청의 Markdown 파일 미리 보기 병렬 차이

이제 새 미리 보기 단추를 사용하여 markdown 파일의 모양을 미리 볼 수 있습니다. 또한 보기 단추를 선택하여 병렬 차이에서 파일의 전체 콘텐츠를 볼 수 있습니다.

Screenshot showing a markdown file in a project with the View and Preview options called out.

수동 빌드에 대한 빌드 정책 만료

정책은 팀의 코드 품질 및 변경 관리 표준을 적용합니다. 이전에는 자동화된 빌드에 대한 빌드 만료 정책을 설정할 수 있습니다. 이제 빌드 만료 정책을 수동 빌드로 설정할 수도 있습니다.

Screenshot of the Add build policy dialog box with the Build expiration section.

커밋 작성자 전자 메일을 기반으로 커밋을 차단하는 정책 추가

이제 관리자는 커밋 작성자 전자 메일이 제공된 패턴과 일치하지 않는 리포지토리로 커밋이 푸시되지 않도록 푸시 정책을 설정할 수 있습니다.

Screenshot showing Policies for all Git repositories on the Policies tab with the Commit author email validation option set to On.

이 기능은 비슷한 환경을 제공하기 위해 Developer Community 제안에 따라 우선 순위가 지정되었습니다. 계속해서 티켓을 열어 두고 사용자가 보고 싶은 다른 유형의 푸시 정책을 알려줄 것을 권장합니다.

끌어오기 요청에서 검토된 파일로 표시

경우에 따라 많은 수의 파일에 대한 변경 내용이 포함된 끌어오기 요청을 검토해야 하며 이미 검토한 파일을 추적하기 어려울 수 있습니다. 이제 끌어오기 요청에서 검토된 파일로 표시할 수 있습니다.

파일 이름 옆에 있는 드롭다운 메뉴를 사용하거나 마우스로 가리키고 파일 이름을 클릭하여 파일을 검토한 것으로 표시할 수 있습니다.

참고

이 기능은 끌어오기 요청을 검토할 때 진행 상황을 추적하기 위한 것입니다. 끌어오기 요청에 대한 투표를 나타내지 않으므로 이러한 표시는 검토자에게만 표시됩니다.

Screenshot showing a project with the View in file explorer and Mark as reviewed options visible.

이 기능은 Developer Community 제안에 따라 우선 순위가 지정되었습니다.

Azure Repos 방문 페이지에 대한 새 웹 UI

이제 Azure Repos 내에서 새롭고 빠르고 모바일 친화적인 방문 페이지를 사용해 볼 수 있습니다. 이러한 페이지는 새 Repos 방문 페이지로 사용할 수 있습니다. 방문 페이지에는 끌어오기 요청 세부 정보, 커밋 세부 정보 및 분기 비교를 제외한 모든 페이지가 포함됩니다.

Screenshot of the new web UI for Azure Repos landing pages.

모바일

Screenshot of the new mobile UI for Azure Repos landing pages.

리포지토리 간 분기 정책 관리

분기 정책은 중요한 분기를 보호하는 데 도움이 되는 Azure Repos 강력한 기능 중 하나입니다. 프로젝트 수준에서 정책을 설정하는 기능은 REST API에 있지만 사용자 인터페이스는 없습니다. 이제 관리자는 프로젝트의 모든 리포지토리에서 특정 분기 또는 기본 분기에 정책을 설정할 수 있습니다. 예를 들어 관리자는 프로젝트의 모든 리포지토리에 있는 모든 주 분기에 대해 수행되는 모든 끌어오기 요청에 대해 최소 두 명의 검토자가 필요할 수 있습니다. Repos Project 설정 분기 보호 추가 기능을 찾을 수 있습니다.

Screenshot of the Add branch protection dialog box.

새 웹 플랫폼 변환 방문 페이지

최신, 빠르고 모바일 친화적인 Repos 방문 페이지 사용자 환경을 업데이트했습니다. 다음은 업데이트된 페이지의 두 가지 예입니다. 향후 업데이트에서 다른 페이지를 계속 업데이트할 예정입니다.

웹 환경:

Screenshot of the web platform conversion landing pages.

모바일 환경:

Screenshot of the mobile platform conversion Files page.

Screenshot of the mobile platform conversion Commits page.

Kotlin 언어 지원

이제 파일 편집기에서 Kotlin 언어 강조 표시를 지원한다고 발표하게 되어 기쁩니다. 강조 표시는 Kotlin 텍스트 파일의 가독성을 향상시키고 신속하게 검색하여 오류를 찾는 데 도움이 됩니다. Developer Community 제안에 따라 이 기능의 우선 순위를 지정했습니다.

Screenshot of a Kotlin file displayed in the UI.

초안 끌어오기 요청에 대한 사용자 지정 알림 구독

끌어오기 요청의 전자 메일 알림 수를 줄이기 위해 이제 초안 상태에서 만들거나 업데이트된 끌어오기 요청에 대한 사용자 지정 알림 구독을 만들 수 있습니다. 끌어오기 요청 초안을 위해 특별히 이메일을 받거나 끌어오기 요청 초안에서 전자 메일을 필터링하여 끌어오기 요청을 검토할 준비가 되기 전에 팀에게 알림을 받지 않도록 할 수 있습니다.

Screenshot of the New subscription dialog box showing that Draft has been added as an option to the Filter criteria feature.

향상된 PR 실행 가능성

검토할 끌어오기 요청이 많은 경우 먼저 조치를 취해야 하는 위치를 이해하는 것이 어려울 수 있습니다. 끌어오기 요청 실행 가능성을 개선하기 위해 이제 초안 상태와 같이 필터링할 수 있는 몇 가지 새로운 옵션을 사용하여 끌어오기 요청 목록 페이지에 여러 사용자 지정 쿼리를 만들 수 있습니다. 이러한 쿼리는 "만든 사용자" 및 "나에게 할당됨" 외에도 끌어오기 요청 페이지에 별도의 축소 가능한 섹션을 만듭니다. 투표 메뉴 또는 끌어오기 요청 목록 페이지의 상황에 맞는 메뉴를 통해 추가된 끌어오기 요청 검토를 거부할 수도 있습니다. 이제 사용자 지정 섹션에서 검토를 제공했거나 검토를 거부한 끌어오기 요청에 대한 별도의 탭이 표시됩니다. 이러한 사용자 지정 쿼리는 컬렉션 홈 페이지의 "내 끌어오기 요청" 탭에 있는 리포지토리에서 작동합니다. 끌어오기 요청으로 돌아가려면 플래그를 지정하면 목록 맨 위에 표시됩니다. 마지막으로, 자동 완성으로 설정된 끌어오기 요청은 목록에 '자동 완성'이라고 표시된 알약으로 표시됩니다.

Pipelines

다단계 파이프라인

파이프라인을 관리하기 위해 업데이트된 사용자 환경에 대해 작업해 왔습니다. 이러한 업데이트는 파이프라인을 최신 환경으로 만들고 Azure DevOps 방향과 일치합니다. 또한 이러한 업데이트는 클래식 빌드 파이프라인과 다단계 YAML 파이프라인을 단일 환경으로 결합합니다. 모바일 친화적이며 파이프라인을 관리하는 방법에 대한 다양한 개선 사항을 제공합니다. 파이프라인 세부 정보, 실행 세부 정보, 파이프라인 분석, 작업 세부 정보, 로그 등을 드릴다운하고 볼 수 있습니다.

새 환경에는 다음과 같은 기능이 포함되어 있습니다.

  • 여러 단계 보기 및 관리
  • 파이프라인 실행 승인
  • 파이프라인이 아직 진행 중인 동안 로그에서 다시 스크롤합니다.
  • 파이프라인의 분기별 상태입니다.

YAML의 지속적인 배포

AZURE PIPELINES YAML CD 기능을 제공하게 되어 기쁩니다. 이제 CI, CD 또는 CI 및 CD를 함께 수행하도록 각 파이프라인을 구성할 수 있도록 통합 YAML 환경을 제공합니다. YAML CD 기능은 다단계 YAML 파이프라인을 사용하여 모든 컬렉션에 사용할 수 있는 몇 가지 새로운 고급 기능을 소개합니다. 몇 가지 중요한 기능은 다음과 같습니다.

빌드를 시작할 준비가 되면 다단계 CI/CD 파이프라인을 빌드하기 위한 설명서 또는 블로그 를 확인하세요.

YAML 편집기에서 파이프라인 변수 관리

YAML 편집기에서 파이프라인 변수를 관리하기 위한 환경을 업데이트했습니다. YAML 파이프라인에서 변수를 추가하거나 업데이트하기 위해 더 이상 클래식 편집기로 이동하지 않아도 됩니다.

Screenshot showing the Variables dialog box.

릴리스 허브에서 직접 릴리스 승인

보류 중인 승인에 대한 작업이 더 쉬워졌습니다. 이전에는 릴리스의 세부 정보 페이지에서 릴리스를 승인할 수 있었습니다. 이제 릴리스 허브에서 직접 릴리스를 승인할 수 있습니다.

Screenshot showing how to approve releases directly from Release hub.

Bitbucket 통합 및 파이프라인 시작의 기타 개선 사항

Pipelines 시작 마법사 환경이 Bitbucket 리포지토리에서 작동하도록 업데이트되었습니다. 이제 Azure Pipelines Bitbucket 리포지토리의 콘텐츠를 분석하고 YAML 템플릿을 권장합니다.

시작 마법사에 대한 일반적인 요청은 생성된 파일의 이름을 바꾸는 기능입니다. 현재 리포지토리의 루트에서와 같이 azure-pipelines.yml 체크 인됩니다. 이제 파이프라인을 저장하기 전에 다른 파일 이름 또는 위치로 업데이트할 수 있습니다.

마지막으로, 해당 분기에서 azure-pipelines.yml 끌어오기 요청 만들기를 건너뛰도록 선택할 수 있으므로 파일을 다른 분기로 체크 인할 때 더 많은 제어를 할 수 있습니다.

파이프라인을 커밋하거나 실행하지 않고 완전히 구문 분석된 YAML 문서 미리 보기

미리 보기를 추가했지만 YAML 파이프라인에 대한 모드를 실행하지 않습니다 . 이제 리포지토리에 커밋하거나 실행하지 않고 YAML 파이프라인을 사용해 볼 수 있습니다. 기존 파이프라인 및 선택적 새 YAML 페이로드가 제공되면 이 새 API는 전체 YAML 파이프라인을 다시 제공합니다. 이후 업데이트에서 이 API는 새 편집기 기능에서 사용됩니다.

개발자의 경우: 다음과 같이 JSON 본문을 사용하여 게시 dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview 합니다.

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

응답에는 렌더링된 YAML이 포함됩니다.

YAML의 Cron 일정

이전에는 UI 편집기를 사용하여 YAML 파이프라인에 대해 예약된 트리거를 지정할 수 있습니다. 이 릴리스에서는 YAML 파일에서 cron 구문을 사용하여 빌드를 예약하고 다음과 같은 이점을 활용할 수 있습니다.

  1. 코드로 구성: 코드의 일부로 파이프라인과 함께 일정을 추적할 수 있습니다.
  2. 표현: UI를 사용할 수 있었던 것보다 일정을 정의하는 데 더 많은 표현력이 있습니다. 예를 들어 매시간 실행을 시작하는 단일 일정을 지정하는 것이 더 쉽습니다.
  3. 업계 표준: 많은 개발자와 관리자는 이미 cron 구문에 익숙합니다.
schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

또한 cron 일정에 대한 문제를 쉽게 진단할 수 있도록 했습니다. 파이프라인 실행 메뉴에서 예약된 실행은 cron 일정으로 오류를 진단하는 데 도움이 되도록 파이프라인에 대해 예정된 몇 가지 실행의 미리 보기를 제공합니다.

Screenshot showing the Run pipeline menu with the Scheduled runs option called out.

서비스 연결 UI에 대한 업데이트

서비스 연결을 관리하기 위해 업데이트된 사용자 환경에 대해 작업해 왔습니다. 이러한 업데이트를 통해 서비스 연결 환경이 최신 상태이며 Azure DevOps 방향과 일치합니다. 올해 초 서비스 연결에 대한 새로운 UI를 미리 보기 기능으로 도입했습니다. 새로운 경험을 시도하고 우리에게 귀중한 피드백을 제공해 주신 모든 분들께 감사드립니다.

Screenshot of the New service connection dialog box.

사용자 환경 새로 고침과 함께 YAML 파이프라인에서 서비스 연결을 사용하는 데 중요한 두 가지 기능인 파이프라인 권한 부여 및 승인 및 검사도 추가되었습니다.

Screenshot showing the Edit menu in a YAML pipeline with the Approvals and checks option visible.

이 업데이트에서는 기본적으로 새 사용자 환경이 켜집니다 . 여전히 미리 보기를 옵트아웃할 수 있습니다.

참고

서비스 연결의 프로젝트 간 공유를 새로운 기능으로 도입할 계획입니다. 공유 환경 및 보안 역할에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

YAML 파이프라인의 단계 건너뛰기

수동 실행을 시작할 때 파이프라인에서 몇 단계를 건너뛰는 경우가 있습니다. 예를 들어 프로덕션에 배포하지 않으려는 경우 또는 프로덕션의 몇 가지 환경에 배포를 건너뛰려는 경우입니다. 이제 YAML 파이프라인을 사용하여 이 작업을 수행할 수 있습니다.

업데이트된 실행 파이프라인 패널은 YAML 파일의 단계 목록을 표시하며, 이러한 단계 중 하나 이상을 건너뛸 수 있는 옵션이 있습니다. 스테이지를 건너뛸 때는 주의해야 합니다. 예를 들어 첫 번째 단계에서 후속 단계에 필요한 특정 아티팩트가 생성되는 경우 첫 번째 단계를 건너뛰지 않아야 합니다. 실행 패널은 다운스트림 종속성이 있는 단계를 건너뛸 때마다 일반 경고를 표시합니다. 이러한 종속성이 실제 아티팩트 종속성인지 아니면 배포 시퀀싱을 위해 존재하는지 여부는 사용자에게 남아 있습니다.

Screenshot showing the Run pipeline section with the Stages to run option called out.

스테이지를 건너뛰는 것은 스테이지 간에 종속성을 다시 배선하는 것과 같습니다. 건너뛴 단계의 즉각적인 다운스트림 종속성은 건너뛴 단계의 업스트림 부모에 따라 달라집니다. 실행이 실패하고 실패한 단계를 다시 실행하려고 하면 해당 시도도 동일한 건너뛰기 동작을 갖습니다. 건너뛸 스테이지를 변경하려면 새 실행을 시작해야 합니다.

Screenshot showing the Stages to run section with the dev option and the deploy option selected.

서비스 연결 새 UI를 기본 환경으로

새 서비스 연결 UI가 있습니다. 이 새로운 UI는 최신 디자인 표준을 기반으로 하며 승인, 권한 부여 및 프로젝트 간 공유와 같은 다단계 YAML CD 파이프라인을 지원하는 다양한 중요한 기능을 제공합니다.

Screenshot of the Run pipeline dialog box.

서비스 연결에 대한 자세한 내용은 여기를 참조하세요.

실행 만들기 대화 상자의 파이프라인 리소스 버전 선택기

만들기 실행 대화 상자에서 파이프라인 리소스 버전을 수동으로 선택하는 기능을 추가했습니다. 파이프라인을 다른 파이프라인의 리소스로 사용하는 경우 이제 실행을 만들 때 해당 파이프라인의 버전을 선택할 수 있습니다.

Screenshot of the Stages to run dialog box.

azAzure Pipelines 대한 CLI 개선 사항

파이프라인 변수 그룹 및 변수 관리 명령

파이프라인 변수 및 변수 그룹을 수동으로 설정해야 하므로 YAML 기반 파이프라인을 한 프로젝트에서 다른 프로젝트로 이식하는 것은 어려울 수 있습니다. 그러나 파이프라인 변수 그룹변수 관리 명령을 사용하면 이제 파이프라인 변수 및 변수 그룹의 설정 및 관리를 스크립팅하여 버전을 제어할 수 있으므로 한 프로젝트에서 다른 프로젝트로 파이프라인을 이동하고 설정하는 지침을 쉽게 공유할 수 있습니다.

PR 분기에 대한 파이프라인 실행

PR을 만들 때 변경 내용이 대상 분기에서 파이프라인 실행을 중단시킬 수 있는지 확인하는 것이 어려울 수 있습니다. 그러나 파이프라인 실행을 트리거하거나 PR 분기에 대한 빌드를 큐에 대기하는 기능을 사용하면 이제 대상 파이프라인에 대해 실행하여 변경 내용의 유효성을 검사하고 시각화할 수 있습니다. 자세한 내용은 az pipelines runaz pipelines build queue 명령 설명서를 참조하세요.

첫 번째 파이프라인 실행 건너뛰기

파이프라인을 만들 때, 인프라가 준비되지 않았거나 변수/변수 그룹을 만들고 업데이트해야 하는 등 다양한 이유로 인해 오류가 발생할 수 있으므로 YAML 파일을 만들고 커밋하고 파이프라인 실행을 트리거하지 않으려는 경우가 있습니다. Azure DevOps CLI를 사용하면 --skip-first-run 매개 변수를 포함하여 파이프라인을 만들 때 첫 번째 자동화된 파이프라인 실행을 건너뛸 수 있습니다. 자세한 내용은 az pipeline create 명령 설명서를 참조하세요.

서비스 엔드포인트 명령 향상

서비스 엔드포인트 CLI 명령은 azure rm 및 github 서비스 엔드포인트 설정 및 관리만 지원합니다. 그러나 이 릴리스에서 서비스 엔드포인트 명령을 사용하면 파일을 통해 구성을 제공하여 모든 서비스 엔드포인트를 만들 수 있으며, 이러한 유형의 서비스 엔드포인트를 만드는 일류 지원을 제공하는 az devops service-endpoint github 및 az devops service-endpoint azurerm과 같은 최적화된 명령을 제공합니다. 자세한 내용은 명령 설명서를 참조하세요.

배포 작업

배포 작업은 환경에 앱을 배포하는 데 사용되는 특수한 유형의 작업 입니다. 이 업데이트를 통해 배포 작업의 단계 참조에 대한 지원이 추가되었습니다. 예를 들어 한 파일에서 단계 집합을 정의하고 배포 작업에서 참조할 수 있습니다.

또한 배포 작업에 추가 속성에 대한 지원도 추가했습니다. 예를 들어 이제 설정할 수 있는 배포 작업의 몇 가지 속성은 다음과 같습니다.

  • timeoutInMinutes - 자동으로 취소하기 전에 작업을 실행하는 기간
  • cancelTimeoutInMinutes - 종료하기 전에 '취소된 작업이라도 항상 실행'을 제공할 시간
  • 조건 - 조건부로 작업 실행
  • 변수 - 하드 코딩된 값을 직접 추가하거나, Azure Key Vault에서 지원되는 변수 그룹, 변수 그룹을 참조하거나 파일에 정의된 변수 집합을 참조할 수 있습니다.
  • continueOnError - 이 배포 작업이 실패하더라도 이후 작업을 실행해야 하는 경우 기본값은 'false'입니다.

배포 작업 및 배포 작업을 지정하는 전체 구문에 대한 자세한 내용은 배포 작업을 참조하세요.

CI 파이프라인에 연결된 CD 파이프라인 정보 표시

CI 파이프라인을 파이프라인 리소스라고 하는 CD YAML 파이프라인 세부 정보에 지원을 추가했습니다. 이제 CI 파이프라인 실행 보기에 파이프라인 및 아티팩트를 사용하는 모든 파이프라인 실행을 찾을 수 있는 새 '연결된 파이프라인' 탭이 표시됩니다.

Screenshot showing associated CD pipelines info in CI pipelines.

YAML 파이프라인에서 GitHub 패키지 지원

최근에 YAML 파이프라인의 리소스로 GitHub NuGetnpm 패키지를 사용하는 지원을 추가하는 패키지라는 새로운 리소스 유형을 도입했습니다. 이 리소스의 일부로 이제 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 packge 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 블레이드로 이동할 수 있도록 Kubernetes 환경의 리소스 보기에 대한 링크를 추가했습니다. 이는 Azure Kubernetes Service 클러스터의 네임스페이스에 매핑되는 환경에 적용됩니다.

Screenshot of the Kubernetes environment resource view with the Azure Kubernetes Service Cluster link called out.

알림 구독에서 폴더 필터 해제

폴더를 사용하면 파이프라인을 쉽게 검색하고 보안 제어할 수 있습니다. 폴더 아래의 모든 파이프라인에서 나타내는 모든 릴리스 파이프라인에 대한 사용자 지정 전자 메일 알림을 구성하는 것이 좋습니다. 이전에는 집중형 전자 메일을 얻기 위해 여러 구독을 구성하거나 구독에 복잡한 쿼리가 있어야 했습니다. 이 업데이트를 사용하면 배포 완료승인 보류 중인 이벤트에 릴리스 폴더 절을 추가하고 구독을 간소화할 수 있습니다.

Screenshot of the release folder filters in notification subscriptions.

현재 작업 항목을 클래식 빌드와 자동으로 연결할 수 있습니다. 그러나 YAML 파이프라인에서는 불가능했습니다. 이 업데이트를 통해 이 격차를 해결했습니다. 지정된 분기의 코드를 사용하여 파이프라인을 성공적으로 실행하면 Azure Pipelines 해당 코드의 커밋을 통해 유추되는 모든 작업 항목과 실행을 자동으로 연결합니다. 작업 항목을 열면 해당 작업 항목에 대한 코드가 빌드된 실행을 볼 수 있습니다. 이를 구성하려면 파이프라인의 설정 패널을 사용합니다.

다단계 YAML 파이프라인 실행의 취소 단계

다단계 YAML 파이프라인을 실행하는 경우 진행 중인 단계의 실행을 취소할 수 있습니다. 이는 스테이지가 실패할 것임을 알고 있거나 시작하려는 다른 실행이 있는 경우에 유용합니다.

실패한 스테이지 다시 시도

다단계 파이프라인에서 가장 많이 요청되는 기능 중 하나는 처음부터 시작하지 않고도 실패한 단계를 다시 시도하는 기능입니다. 이 업데이트를 통해 이 기능의 큰 부분을 추가하고 있습니다.

이제 실행이 실패할 때 파이프라인 단계를 다시 시도할 수 있습니다. 첫 번째 시도에서 실패한 작업과 실패한 작업에 전이적으로 의존하는 작업은 모두 다시 시도됩니다.

이렇게 하면 여러 가지 방법으로 시간을 절약할 수 있습니다. 예를 들어 한 단계에서 여러 작업을 실행하는 경우 각 스테이지가 다른 플랫폼에서 테스트를 실행하도록 할 수 있습니다. 한 플랫폼의 테스트가 다른 플랫폼이 통과하는 동안 실패하는 경우 통과한 작업을 다시 실행하지 않음으로써 시간을 절약할 수 있습니다. 또 다른 예로, 네트워크 연결이 불안정하여 배포 단계가 실패했을 수 있습니다. 해당 단계를 다시 시도하면 다른 빌드를 생성할 필요가 없으므로 시간을 절약할 수 있습니다.

이 기능에는 몇 가지 알려진 간격이 있습니다. 예를 들어 명시적으로 취소하는 단계를 다시 시도할 수 없습니다. 향후 업데이트에서 이러한 격차를 줄이기 위해 노력하고 있습니다.

다단계 YAML 파이프라인의 승인

YAML CD 파이프라인에는 수동 승인이 포함될 수 있습니다. 인프라 소유자는 파이프라인의 단계가 배포되기 전에 환경을 보호하고 수동 승인을 요청할 수 있습니다. 인프라(환경)와 애플리케이션(파이프라인) 소유자 간의 역할을 완전히 분리하면 특정 파이프라인에서 배포에 대한 수동 로그오프를 보장하고 모든 배포에서 동일한 검사를 환경에 적용할 때 중앙에서 제어할 수 있습니다.

Screenshot of the Add resources menu with the Checks option underlined.

개발 배포를 실행하는 파이프라인은 단계 시작 시 승인을 위해 중지됩니다.

Screenshot showing that a deployment is waiting for approval.

게이트 제한 시간 제한 및 빈도 증가

이전에는 릴리스 파이프라인의 게이트 제한 시간이 3일이었습니다. 이 업데이트를 사용하면 시간이 더 긴 게이트를 허용하기 위해 제한 시간이 15일 로 증가했습니다. 또한 게이트의 빈도를 30분으로 늘렸습니다.

Dockerfile에 대한 새 빌드 이미지 템플릿

이전에는 새 파이프라인을 만들 때 Dockerfile에 대한 새 파이프라인을 만들 때 템플릿에서 이미지를 Azure Container Registry 푸시하고 Azure Kubernetes Service 배포하는 것이 좋습니다. 컨테이너 레지스트리에 푸시할 필요 없이 에이전트를 사용하여 이미지를 빌드할 수 있도록 새 템플릿을 추가했습니다.

Screenshot of the Docker dialog box.

Azure App Service 앱 설정을 구성하기 위한 새 작업

Azure App Service 앱 설정, 연결 문자열 및 기타 일반 구성 설정과 같은 다양한 설정을 통해 구성을 허용합니다. 이제 웹앱 또는 배포 슬롯에서 JSON 구문을 사용하여 이러한 설정을 대량으로 구성할 수 있도록 지원하는 새 Azure Pipelines 작업 Azure App Service 설정 있습니다. 이 작업을 다른 App Service 작업과 함께 사용하여 웹앱, 함수 앱 또는 기타 컨테이너화된 App Services를 배포, 관리 및 구성할 수 있습니다.

Screenshot showing the Azure App Service Settings dialog box.

이제 Azure App Service 미리 보기로 교환을 지원합니다.

이제 Azure App Service 배포 슬롯에서 미리 보기로 교환을 지원합니다. 이는 앱이 실제로 스테이징 슬롯에서 프로덕션 슬롯으로 교환되기 전에 프로덕션 구성을 사용하여 앱의 유효성을 검사하는 좋은 방법입니다. 이렇게 하면 대상/프로덕션 슬롯에 가동 중지 시간이 발생하지 않습니다.

이제 Azure App Service 작업은 다음과 같은 새 작업을 통해 이 다단계 교환을 지원합니다.

  • 미리 보기로 교환 시작 - 미리 보기(다단계 교환)를 사용하여 교환을 시작하고 대상 슬롯(예: 프로덕션 슬롯) 구성을 원본 슬롯에 적용합니다.
  • 미리 보기로 교환 완료 - 보류 중인 교환을 완료할 준비가 되면 미리 보기로 교환 완료 작업을 선택합니다.
  • 미리 보기로 교환 취소 - 보류 중인 교환을 취소하려면 미리 보기로 교환 취소를 선택합니다.

Screenshot showing the Azure App Service manage dialog box with the new multi-phase swap setting in the Action dropdown list.

Azure Container Registry 및 Docker Hub 아티팩트 스테이지 수준 필터

이전에는 릴리스 파이프라인 수준에서만 Azure Container Registry 및 Docker Hub 아티팩트용 정규식 필터를 사용할 수 있었습니다. 이제 스테이지 수준에서도 추가되었습니다.

Screenshot showing that you can use regular expressions at the staging level.

YAML 파이프라인의 승인 향상

서비스 연결 및 에이전트 풀에 대한 승인을 구성할 수 있습니다. 승인을 위해 인프라 소유자와 개발자 간의 역할 분리를 따릅니다. 환경, 서비스 연결 및 에이전트 풀과 같은 리소스에 대한 승인을 구성하면 리소스를 사용하는 모든 파이프라인 실행에 먼저 승인이 필요합니다.

환경은 환경에 대한 승인을 구성하는 것과 비슷합니다. 단계에서 참조된 리소스에 대한 승인이 보류 중인 경우 파이프라인 실행은 파이프라인이 수동으로 승인될 때까지 대기합니다.

Screenshot showing the Policies tab with the Use manual approvals page and the Create option visible.

Azure Pipelines 컨테이너 구조 테스트 지원

애플리케이션에서 컨테이너의 사용량이 증가하고 있으므로 강력한 테스트 및 유효성 검사가 필요합니다. 이제 Azure Pipelines 컨테이너 구조 테스트에 대한 지원을 제공합니다. 이 프레임워크는 컨테이너의 내용과 구조를 확인하는 편리하고 강력한 방법을 제공합니다.

명령 테스트, 파일 존재 테스트, 파일 콘텐츠 테스트 및 메타데이터 테스트 등 함께 실행할 수 있는 네 가지 테스트 범주를 기반으로 이미지 구조의 유효성을 검사할 수 있습니다. 파이프라인의 결과를 사용하여 go/no go 결정을 내릴 수 있습니다. 테스트 데이터는 오류 문제를 더 잘 해결하는 데 도움이 되는 오류 메시지와 함께 파이프라인 실행에서 사용할 수 있습니다.

구성 파일 및 이미지 세부 정보 입력

Screenshot showing the Container Structure Test page.

테스트 데이터 및 요약

Screenshot showing that a summary and test data is available.

릴리스 파이프라인에 대한 파이프라인 데코레이터

파이프라인 데코레이터를 사용하면 모든 작업의 시작과 끝에 단계를 추가할 수 있습니다. 컬렉션의 모든 파이프라인에 적용되므로 단일 정의에 단계를 추가하는 것과는 다릅니다.

빌드 및 YAML 파이프라인에 대한 데코레이터를 지원하고 있으며, 고객은 이를 사용하여 작업의 단계를 중앙에서 제어합니다. 이제 파이프라인 릴리스에 대한 지원도 확장하고 있습니다. 확장을 만들어 새 기여 지점을 대상으로 하는 단계를 추가할 수 있으며 릴리스 파이프라인의 모든 에이전트 작업에 추가됩니다.

구독 및 관리 그룹 수준에 ARM(Azure Resource Manager) 배포

이전에는 리소스 그룹 수준에만 배포를 지원했습니다. 이 업데이트를 통해 구독 및 관리 그룹 수준 모두에 ARM 템플릿을 배포하는 지원이 추가되었습니다. 이렇게 하면 리소스 집합을 함께 배포할 때 도움이 되지만 다른 리소스 그룹 또는 구독에 배치할 수 있습니다. 예를 들어 Azure Site Recovery 백업 가상 머신을 별도의 리소스 그룹 및 위치에 배포합니다.

다단계 YAML 파이프라인에 대한 CD 기능

이제 CI 파이프라인에서 게시한 아티팩트 사용 및 파이프라인 완료 트리거를 사용하도록 설정할 수 있습니다. 다단계 YAML 파이프라인에서는 리소스로 도입하고 pipelines 있습니다. 이제 YAML에서 다른 파이프라인을 참조하고 CD 트리거를 사용하도록 설정할 수 있습니다.

파이프라인 리소스에 대한 자세한 YAML 스키마는 다음과 같습니다.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

또한 작업을 사용하여 파이프라인 리소스에서 게시한 아티팩트도 다운로드할 - download 수 있습니다.

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

자세한 내용은 여기에서 아티팩트 다운로드 설명서를 참조 하세요.

Kubernetes 환경에 대한 카나리아 배포 전략 오케스트레이션

애플리케이션 업데이트를 지속적으로 업데이트할 때의 주요 이점 중 하나는 특정 마이크로 서비스에 대한 업데이트를 프로덕션으로 신속하게 푸시할 수 있다는 점입니다. 이렇게 하면 비즈니스 요구 사항의 변화에 신속하게 대응할 수 있습니다. 환경 은 배포 전략을 오케스트레이션하고 가동 중지 시간 릴리스를 용이하게 하는 일류 개념으로 도입되었습니다. 이전에는 단계를 한 번 순차적으로 실행하는 runOnce 전략을 지원했습니다. 다단계 파이프라인에서 카나리아 전략을 지원하면 이제 변경 내용을 작은 하위 집합으로 천천히 롤아웃하여 위험을 줄일 수 있습니다. 새 버전에 대한 신뢰도가 높아짐에 따라 인프라의 더 많은 서버에 배포를 시작하고 더 많은 사용자를 라우팅할 수 있습니다.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kuberenetes에 대한 카나리아 전략은 먼저 PostRouteTraffic 동안 상태를 모니터링하는 동안 10% Pod 및 20%로 변경 내용을 배포합니다. 모든 것이 잘되면 100 %로 승격됩니다.

환경에서 VM 리소스를 지원하고 여러 머신에서 롤링 배포 전략을 수행하는 방법에 대한 초기 피드백을 찾고 있습니다. 등록하려면 문의하세요.

YAML 파이프라인에 대한 승인 정책

YAML 파이프라인에서는 리소스 소유자가 제어하는 승인 구성을 따릅니다. 리소스 소유자는 리소스를 사용하는 단계를 시작하기 전에 승인을 위해 리소스 일시 중지를 사용하는 모든 파이프라인 및 리소스에 대한 승인을 구성합니다. SOX 기반 애플리케이션 소유자는 배포 요청자가 자체 배포를 승인하지 못하도록 제한하는 것이 일반적입니다.

이제 고급 승인 옵션을 사용하여 요청자가 승인하지 않아야 하고, 사용자 하위 집합의 승인이 필요하고, 승인 시간 제한이 필요한 등의 승인 정책을 구성할 수 있습니다.

Screenshot showing the Create approvals dialog box.

ACR을 일류 파이프라인 리소스로 사용

파이프라인의 일부로 ACR(Azure Container Registry)에 게시된 컨테이너 이미지를 사용하고 새 이미지가 게시될 때마다 파이프라인을 트리거해야 하는 경우 ACR 컨테이너 리소스를 사용할 수 있습니다.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

또한 미리 정의된 변수를 사용하여 ACR 이미지 메타 데이터에 액세스할 수 있습니다. 다음 목록에는 파이프라인에서 ACR 컨테이너 리소스를 정의하는 데 사용할 수 있는 ACR 변수가 포함되어 있습니다.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

파이프라인에서 아티팩트 검사 정책을 평가하기 위한 향상된 기능

기본 정책 정의 목록에서 정책을 더 쉽게 추가할 수 있도록 평가 아티 팩트 검사를 개선했습니다. 정책 정의는 자동으로 생성되고 필요한 경우 업데이트할 수 있는 검사 구성 에 추가됩니다.

Screenshot showing the Evaluate artifact dialog box with the Use templates option underlined.

Screenshot showing the Configure artifact policy dialog box with the list of templates to include.

배포 작업의 출력 변수 지원

이제 배포 작업의 수 명 주기 후크 에서 출력 변수를 정의하고 동일한 단계 내의 다른 다운스트림 단계 및 작업에서 사용할 수 있습니다.

배포 전략을 실행하는 동안 다음 구문을 사용하여 작업 전체의 출력 변수에 액세스할 수 있습니다.

  • runOnce 전략의 경우:$[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
  • 카나리아 전략의 경우:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
  • 롤링 전략의 경우:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

다중 작업 출력 변수를 설정하는 방법에 대해 자세히 알아보기

중요한 변경 내용 롤백 방지

클래식 릴리스 파이프라인에서는 일반 업데이트를 위해 예약된 배포를 사용하는 것이 일반적입니다. 그러나 중요한 수정 사항이 있는 경우 대역 외 수동 배포를 시작하도록 선택할 수 있습니다. 이렇게 하면 이전 릴리스는 계속 예약된 상태로 유지됩니다. 이렇게 하면 일정에 따라 배포가 다시 시작될 때 수동 배포가 롤백되기 때문에 문제가 발생했습니다. 많은 사용자가 이 문제를 보고했으며 이제 문제를 해결했습니다. 수정을 사용하면 수동으로 배포를 시작할 때 환경에 대한 모든 이전 예약 배포가 취소됩니다. 이는 큐에 대기 옵션이 "최신 배포 및 다른 사용자 취소"로 선택된 경우에만 적용됩니다.

YAML 파이프라인에서 간소화된 리소스 권한 부여

리소스는 파이프라인 외부에 있는 파이프라인에서 사용되는 모든 항목입니다. 리소스를 사용하려면 먼저 권한을 부여해야 합니다. 이전에는 YAML 파이프라인에서 권한 없는 리소스를 사용할 때 리소스 권한 부여 오류로 실패했습니다. 실패한 실행의 요약 페이지에서 리소스에 권한을 부여해야 했습니다. 또한 권한이 없는 리소스를 참조하는 변수를 사용하는 경우 파이프라인이 실패했습니다.

이제 리소스 권한 부여를 더 쉽게 관리할 수 있습니다. 실행에 실패하는 대신, 실행은 리소스를 사용하는 단계의 시작 부분에 리소스에 대한 권한을 기다립니다. 리소스 소유자는 파이프라인을 보고 보안 페이지에서 리소스에 권한을 부여할 수 있습니다.

Screenshot showing a Dev stage is in a Waiting state with an indicator that says that Permission is needed.

아티팩트 검사 평가

이제 정책 집합을 정의하고 컨테이너 이미지 아티팩트 환경에 대한 확인으로 정책 평가를 추가할 수 있습니다. 파이프라인이 실행되면 환경을 사용하는 단계를 시작하기 전에 실행이 일시 중지됩니다. 지정된 정책은 배포되는 이미지에 대해 사용 가능한 메타데이터에 대해 평가됩니다. 정책이 성공하면 검사가 통과되고 확인이 실패하면 단계를 실패로 표시합니다.

Screenshot of the Evaluate artifact policies dialog box.

ARM 템플릿 배포 작업 업데이트

이전에는 ARM 템플릿 배포 태스크에서 서비스 연결을 필터링하지 않았습니다. 이로 인해 더 넓은 범위에 ARM 템플릿 배포를 수행하기 위해 하위 범위의 서비스 연결을 선택하는 경우 배포가 실패할 수 있습니다. 이제 선택한 배포 범위에 따라 범위가 낮은 서비스 연결을 필터링하기 위해 서비스 연결 필터링을 추가했습니다.

환경의 ReviewApp

ReviewApp은 Git 리포지토리의 모든 끌어오기 요청을 동적 환경 리소스에 배포합니다. 검토자는 이러한 변경 내용이 주 분기에 병합되고 프로덕션에 배포되기 전에 다른 종속 서비스와 함께 작동하는 방식을 확인할 수 있습니다. 이렇게 하면 reviewApp 리소스를 쉽게 만들고 관리하고 환경 기능의 모든 추적 가능성 및 진단 기능을 활용할 수 있습니다. reviewApp 키워드를 사용하여 리소스의 복제본을 만들고(환경의 기존 리소스를 기반으로 동적으로 새 리소스 만들기) 환경에 새 리소스를 추가할 수 있습니다.

다음은 환경에서 reviewApp을 사용하는 샘플 YAML 코드 조각입니다.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

파이프라인에서 자동 및 사용자 지정 메타데이터 수집

이제 파이프라인 작업에서 자동 및 사용자 지정 메타데이터 컬렉션을 사용하도록 설정할 수 있습니다. 메타데이터를 사용하여 평가 아티팩트 검사를 사용하여 환경에 아티팩트 정책을 적용할 수 있습니다.

Screenshot of the General dialog box with the Publish metadata from pipelines option turned on.

환경을 사용하는 VM 배포

환경에서 가장 많이 요청된 기능 중 하나는 VM 배포였습니다. 이 업데이트를 통해 환경에서 Virtual Machine 리소스를 사용하도록 설정합니다. 이제 여러 컴퓨터에서 배포를 오케스트레이션하고 YAML 파이프라인을 사용하여 롤링 업데이트를 수행할 수 있습니다. 각 대상 서버에 에이전트를 직접 설치하고 해당 서버에 롤링 배포를 구동할 수도 있습니다. 또한 대상 컴퓨터에서 전체 작업 카탈로그를 사용할 수 있습니다.

Screenshot of the New environment dialog box with the Virtual machines option selected and called out.

롤링 배포는 이전 버전의 애플리케이션 인스턴스를 각 반복의 컴퓨터 집합(롤링 세트)에서 새 버전의 애플리케이션 인스턴스로 바꿉니다.

예를 들어 아래 롤링 배포는 각 반복에서 최대 5개의 대상을 업데이트합니다. maxParallel 는 병렬로 배포할 수 있는 대상 수를 결정합니다. 선택 영역은 배포되는 대상을 제외하고 언제든지 사용 가능한 상태로 유지해야 하는 대상 수를 고려합니다. 또한 배포 중에 성공 및 실패 조건을 확인하는 데도 사용됩니다.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

참고

이 업데이트를 사용하면 현재 파이프라인 및 연결된 파이프라인 리소스에서 사용 가능한 모든 아티팩트가 수명 주기 후크에서 deploy 만 다운로드됩니다. 그러나 파이프라인 아티팩트 다운로드 작업을 지정하여 다운로드하도록 선택할 수 있습니다. 이 기능에는 몇 가지 알려진 간격이 있습니다. 예를 들어 스테이지를 다시 시도할 때 실패한 대상뿐만 아니라 모든 VM에서 배포를 다시 실행합니다. 향후 업데이트에서 이러한 격차를 해소하기 위해 노력하고 있습니다.

배포에 대한 추가 제어

Azure Pipelines 몇 시간 동안 수동 승인으로 제어되는 배포를 지원했습니다. 최신 향상된 기능을 통해 이제 배포를 추가로 제어할 수 있습니다. 이제 리소스 소유자는 승인 외에도 자동화된 checks 기능을 추가하여 보안 및 품질 정책을 확인할 수 있습니다. 이러한 검사는 작업을 트리거한 다음 완료될 때까지 기다리는 데 사용할 수 있습니다. 추가 검사를 사용하여 이제 여러 원본을 기반으로 상태 조건을 정의하고 배포를 수행하는 YAML 파이프라인에 관계없이 리소스를 대상으로 하는 모든 배포가 안전하다는 것을 확신할 수 있습니다. 각 검사의 평가는 검사에 대해 지정된 재시도 간격 에 따라 주기적으로 반복될 수 있습니다. 이제 다음 추가 검사를 사용할 수 있습니다.

  • REST API를 호출하고 응답 본문 또는 외부 서비스의 콜백에 따라 유효성 검사를 수행합니다.
  • Azure 함수를 호출하고 함수의 응답 또는 콜백에 따라 유효성 검사를 수행합니다.
  • 활성 경고에 대한 Azure Monitor 규칙 쿼리
  • 파이프라인이 하나 이상의 YAML 템플릿을 확장하는지 확인합니다.

Screenshot of the Add check dialog box.

승인 알림

환경 또는 서비스 연결에 승인을 추가하면 리소스를 사용하는 모든 다단계 파이프라인이 단계 시작 시 승인을 자동으로 기다립니다. 지정된 승인자는 파이프라인을 계속하기 전에 승인을 완료해야 합니다.

이 업데이트를 통해 승인자는 보류 중인 승인에 대한 이메일 알림을 보냅니다. 사용자 및 팀 소유자는 알림 설정을 사용하여 사용자 지정 구독을 옵트아웃하거나 구성할 수 있습니다.

Screenshot of an approval notification.

Azure Portal 배포 전략 구성

이 기능을 사용하면 선택한 배포 전략(예: 롤링, 카나리아 또는 Blue-Green)을 사용하는 파이프라인을 더 쉽게 구성할 수 있습니다. 이러한 기본 제공 전략을 사용하여 안전한 방식으로 업데이트를 배포하고 관련 배포 위험을 완화할 수 있습니다. 액세스하려면 Azure Virtual Machine에서 '지속적인 업데이트' 설정을 클릭합니다. 구성 창에서 파이프라인을 만들 Azure DevOps 프로젝트, 배포 그룹, 배포할 패키지를 게시하는 빌드 파이프라인 및 선택한 배포 전략에 대한 세부 정보를 선택하라는 메시지가 표시됩니다. 계속 진행하면 선택한 패키지를 이 Virtual Machine에 배포하는 완벽하게 작동하는 파이프라인이 구성됩니다.

자세한 내용은 배포 전략 구성에 대한 설명서를 참조하세요.

Screenshot that shows the Continuous delivery dialog box.

런타임 매개 변수

런타임 매개 변수를 사용하면 파이프라인에 전달할 수 있는 값을 더 많이 제어할 수 있습니다. 변수와 달리 런타임 매개 변수에는 데이터 형식이 있으며 자동으로 환경 변수가 되지 않습니다. 런타임 매개 변수를 사용하여 다음을 수행할 수 있습니다.

  • 런타임 시 스크립트 및 작업에 다양한 값 제공
  • 컨트롤 매개 변수 형식, 허용되는 범위 및 기본값
  • 템플릿 식을 사용하여 동적으로 작업 및 단계 선택

런타임 매개 변수에 대한 자세한 내용은 여기 설명서를 참조 하세요.

파이프라인에서 extends 키워드 사용

현재 파이프라인은 템플릿으로 고려되어 재사용을 촉진하고 상용구 수를 줄일 수 있습니다. 파이프라인의 전체 구조는 여전히 루트 YAML 파일에 의해 정의되었습니다. 이 업데이트를 통해 파이프라인 템플릿을 사용하는 보다 구조화된 방법을 추가했습니다. 이제 루트 YAML 파일은 키워드 확장을 사용하여 주 파이프라인 구조를 다른 파일에서 찾을 수 있음을 나타낼 수 있습니다. 이렇게 하면 확장 또는 변경할 수 있는 세그먼트와 고정된 세그먼트를 제어할 수 있습니다. 또한 데이터 형식을 사용하여 파이프라인 매개 변수를 개선하여 제공할 수 있는 후크를 명확히 했습니다.

이 예제에서는 파이프라인 작성자가 사용할 간단한 후크를 제공하는 방법을 보여 줍니다. 템플릿은 항상 빌드를 실행하고, 필요에 따라 파이프라인에서 제공하는 추가 단계를 실행한 다음, 선택적 테스트 단계를 실행합니다.


# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

큐 시간에 재정의할 수 있는 컨트롤 변수

이전에는 새 실행을 시작하기 전에 UI 또는 REST API를 사용하여 변수의 값을 업데이트할 수 있습니다. 파이프라인 작성자가 특정 변수를 표시 _settable at queue time_할 수 있지만 시스템에서 이를 적용하지 않았거나 다른 변수가 설정되지 않도록 방지했습니다. 즉, 이 설정은 새 실행을 시작할 때 추가 입력을 요청하는 데만 사용되었습니다.

매개 변수를 적용하는 새 컬렉션 설정을 추가했습니다 _settable at queue time_ . 이렇게 하면 새 실행을 시작할 때 변경할 수 있는 변수를 제어할 수 있습니다. 앞으로 작성 _settable at queue time_자가 표시하지 않은 변수는 변경할 수 없습니다.

참고

이 설정은 기존 컬렉션에서 기본적으로 해제되어 있지만 새 Azure DevOps 컬렉션을 만들 때 기본적으로 설정됩니다.

YAML 파이프라인의 새 미리 정의된 변수

변수는 파이프라인의 다양한 부분으로 데이터의 키 비트를 가져오는 편리한 방법을 제공합니다. 이 업데이트를 통해 배포 작업에 미리 정의된 몇 가지 변수를 추가했습니다. 이러한 변수는 시스템에서 자동으로 설정되고 특정 배포 작업 범위가 지정되며 읽기 전용입니다.

  • Environment.Id - 환경의 ID입니다.
  • Environment.Name - 배포 작업의 대상이 되는 환경의 이름입니다.
  • Environment.ResourceId - 배포 작업의 대상이 되는 환경의 리소스 ID입니다.
  • Environment.ResourceName - 배포 작업의 대상이 되는 환경의 리소스 이름입니다.

여러 리포지토리 체크 아웃

Pipelines 종종 여러 리포지토리에 의존합니다. 코드를 빌드하는 데 필요한 원본, 도구, 스크립트 또는 기타 항목을 사용하여 다른 리포지토리를 가질 수 있습니다. 이전에는 git 체크 아웃을 실행하기 위해 이러한 리포지토리를 하위 모듈 또는 수동 스크립트로 추가해야 했습니다. 이제 YAML 파이프라인을 저장하는 데 사용하는 리포지토리 외에도 다른 리포지토리를 가져오고 체크 아웃할 수 있습니다.

예를 들어 YAML 파이프라인이 있는 MyCode 라는 리포지토리와 Tools라는 두 번째 리포지토리가 있는 경우 YAML 파이프라인은 다음과 같습니다.

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

세 번째 단계에서는 원본 디렉터리에 MyCodeTools 의 두 디렉터리를 표시합니다.

Azure Repos Git, GitHub 및 Bitbucket Cloud 리포지토리가 지원됩니다. 자세한 내용은 다중 리포지토리 체크 아웃을 참조하세요.

런타임에 여러 리포지토리에 대한 세부 정보 가져오기

파이프라인이 실행 중일 때 Azure Pipelines 실행을 트리거한 리포지토리, 분기 및 커밋에 대한 정보를 추가합니다. 이제 YAML 파이프라인이 여러 리포지토리 체크 아웃을 지원하므로 다른 리포지토리에 대해 체크 아웃된 리포지토리, 분기 및 커밋을 알고 싶을 수도 있습니다. 이 데이터는 이제 변수에 매핑할 수 있는 런타임 식을 통해 사용할 수 있습니다. 예를 들면 다음과 같습니다.

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

다른 Azure Repos 컬렉션에 대한 리포지토리 참조 허용

이전에는 YAML 파이프라인에서 리포지토리를 참조할 때 모든 Azure Repos 리포지토리가 파이프라인과 동일한 컬렉션에 있어야 했습니다. 이제 서비스 연결을 사용하여 다른 컬렉션의 리포지토리를 가리킬 수 있습니다. 예를 들면 다음과 같습니다.

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection다른 Azure DevOps 컬렉션을 가리키고 다른 프로젝트의 리포지토리에 액세스할 수 있는 자격 증명이 있습니다. 리포지토리와 otherrepo리포 self 지토리 모두 체크 아웃됩니다.

중요

MyServiceConnection는 Azure Repos/Team Foundation Server 서비스 연결이어야 합니다. 아래 그림을 참조하세요.

Screenshot of the Project Settings page with the Azure Repos/Team Foundation Server option highlighted.

미리 정의된 변수로 파이프라인 리소스 메타 데이터

파이프라인에서 YAML 파이프라인 리소스에 대해 미리 정의된 변수를 추가했습니다. 다음은 사용할 수 있는 파이프라인 리소스 변수의 목록입니다.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

KubernetesManifest 작업의 베이킹 옵션으로 kustomize 및 kompose

kustomize (Kubernetes sig-cli의 일부)를 사용하면 템플릿이 없는 원시 YAML 파일을 여러 용도로 사용자 지정할 수 있으며 원래 YAML은 그대로 유지됩니다. kustomization.yaml 파일이 포함된 폴더를 KubernetesManifest 작업의 배포 작업에 사용되는 매니페스트 파일을 생성하는 데 사용할 수 있도록 KubernetesManifest 작업의 준비 작업 아래에 kustomize 옵션이 추가되었습니다.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose는 Docker Compose 파일을 Kubernetes 리소스로 변환합니다.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

HelmDeploy 작업의 클러스터 관리자 자격 증명 지원

이전에는 HelmDeploy 작업에서 배포에 클러스터 사용자 자격 증명을 사용했습니다. 이로 인해 대화형 로그인 프롬프트가 표시되고 Azure Active Directory 기반 RBAC 사용 클러스터에 대한 파이프라인이 실패했습니다. 이 문제를 해결하기 위해 클러스터 사용자 자격 증명 대신 클러스터 관리자 자격 증명을 사용할 수 있는 확인란을 추가했습니다.

Screenshot of Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Docker Compose 작업의 인수 입력

Docker Compose 작업에 새 필드가 도입되어 다음과 같은 --no-cache인수를 추가할 수 있습니다. 빌드와 같은 명령을 실행할 때 태스크에서 인수를 전달합니다.

Screenshot of the Docker Compose task showing the new Arguments text box.

GitHub 릴리스 작업 향상

GitHub 릴리스 작업을 몇 가지 개선했습니다. 이제 태그 정규식을 지정하여 태그 패턴 필드를 사용하여 릴리스 만들기를 보다 효율적으로 제어할 수 있으며, 트리거 커밋에 일치하는 문자열로 태그가 지정된 경우에만 릴리스가 만들어집니다.

Screenshot showing the GitHub release task with the Task version and Tag Pattern sections called out.

변경 로그의 만들기 및 서식을 사용자 지정하는 기능도 추가되었습니다. 이제 changelog 구성에 대한 새 섹션에서 현재 릴리스를 비교할 릴리스를 지정할 수 있습니다. 비교 릴리스는 마지막 전체 릴리스(시험판 제외), 마지막 초안이 아닌 릴리스 또는 제공된 릴리스 태그와 일치하는 이전 릴리스일 수 있습니다. 또한 이 작업은 changelog 형식 필드를 제공하여 변경 로그의 형식을 지정합니다. 선택에 따라 변경 로그는 커밋 목록 또는 레이블에 따라 분류된 문제/PR 목록을 표시합니다.

Screenshot showing the GitHub release task with the Compare to and Changelog type sections highlighted.

정책 에이전트 설치 관리자 작업 열기

Open Policy Agent는 통합된 컨텍스트 인식 정책 적용을 가능하게 하는 오픈 소스 범용 정책 엔진입니다. Open Policy Agent 설치 관리자 작업을 추가했습니다. 코드 공급자로서의 인프라와 관련하여 파이프라인 내 정책 적용에 특히 유용합니다.

예를 들어 Open Policy Agent는 파이프라인에서 Rego 정책 파일 및 Terraform 계획을 평가할 수 있습니다.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Azure CLI 작업에서 PowerShell 스크립트 지원

이전에는 Azure CLI 태스크의 일부로 일괄 처리 및 bash 스크립트를 실행할 수 있습니다. 이 업데이트를 통해 PowerShell 및 PowerShell 핵심 스크립트에 대한 지원이 작업에 추가되었습니다.

Screenshot of the Azure CLI task showing that Powershell and Powershell Core are options in the Script Type dropdown list.

KubernetesManifest 작업의 서비스 Mesh 인터페이스 기반 카나리아 배포

이전에는 KubernetesManifest 태스크에서 카나리아 전략을 지정했을 때 복제본이 안정적인 워크로드에 사용되는 복제본의 백분율과 같은 기준 및 카나리아 워크로드를 만듭니다. 이는 요청 수준에서 원하는 백분율로 트래픽을 분할하는 것과 정확히 동일하지 않습니다. 이 문제를 해결하기 위해 KubernetesManifest 작업에 서비스 Mesh 인터페이스 기반 카나리아 배포에 대한 지원을 추가했습니다.

서비스 Mesh 인터페이스 추상화는 Linkerd 및 Istio와 같은 서비스 메시 공급자를 사용하여 플러그 앤 플레이 구성을 허용합니다. 이제 KubernetesManifest 작업은 배포 전략의 수명 주기 동안 SMI의 TrafficSplit 개체를 안정적인 기준 및 카나리아 서비스에 매핑하는 작업을 제거합니다. 서비스 메시 평면의 요청에서 트래픽 분할 비율이 제어되므로 안정적인 기준선과 카나리아 간 트래픽의 원하는 비율 분할이 더 정확합니다.

다음은 롤링 방식으로 SMI 기반 카나리아 배포를 수행하는 샘플입니다.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

이제 Azure 파일 복사 태스크에서 AzCopy V10을 지원합니다.

Azure 파일 복사 작업은 빌드 또는 릴리스 파이프라인에서 사용하여 Microsoft Storage Blob 또는 VM(가상 머신)에 파일을 복사할 수 있습니다. 이 작업은 Azure Storage 계정에서 데이터를 빠르게 복사하기 위해 명령줄 유틸리티 빌드인 AzCopy를 사용합니다. 이 업데이트를 통해 AzCopy의 최신 버전인 AzCopy V10에 대한 지원이 추가되었습니다.

azcopy copy 명령은 연결된 인수 만 지원합니다. AzCopy 구문이 변경되어 AzCopy V10에서는 일부 기존 기능을 사용할 수 없습니다. 여기에는 다음이 포함됩니다.

  • 로그 위치 지정
  • 복사 후 로그 및 계획 파일 정리
  • 작업이 실패하면 복사 다시 시작

이 버전의 작업에서 지원되는 추가 기능은 다음과 같습니다.

  • 소스의 파일 이름/경로에 있는 와일드카드 기호
  • 인수가 제공되지 않은 경우 파일 확장자를 기반으로 콘텐츠 형식 유추
  • 인수를 전달하여 로그 파일의 로그 세부 정보 표시 정의

액세스 토큰의 범위를 제한하여 파이프라인 보안 향상

Azure Pipelines 실행되는 모든 작업은 액세스 토큰을 가져옵니다. 액세스 토큰은 태스크 및 스크립트에서 Azure DevOps 다시 호출하는 데 사용됩니다. 예를 들어 액세스 토큰을 사용하여 소스 코드를 가져오거나, 로그를 업로드하고, 결과, 아티팩트 테스트하거나, REST를 Azure DevOps 호출합니다. 각 작업에 대해 새 액세스 토큰이 생성되고 작업이 완료되면 만료됩니다. 이 업데이트를 통해 다음과 같은 향상된 기능을 추가했습니다.

  • 토큰이 팀 프로젝트 외부의 리소스에 액세스하지 못하도록 방지

    지금까지 모든 파이프라인의 기본 범위는 팀 프로젝트 컬렉션이었습니다. 범위를 클래식 빌드 파이프라인의 팀 프로젝트로 변경할 수 있습니다. 그러나 클래식 릴리스 또는 YAML 파이프라인에 대한 컨트롤이 없습니다. 이 업데이트를 통해 파이프라인에 구성된 내용에 관계없이 모든 작업이 프로젝트 범위 토큰을 가져오도록 강제하는 컬렉션 설정이 도입되었습니다. 또한 프로젝트 수준에서 설정을 추가했습니다. 이제 새로 만드는 모든 프로젝트 및 컬렉션에 이 설정이 자동으로 설정됩니다.

    참고

    컬렉션 설정은 프로젝트 설정을 재정의합니다.

    기존 프로젝트 및 컬렉션에서 이 설정을 설정하면 파이프라인이 액세스 토큰을 사용하여 팀 프로젝트 외부에 있는 리소스에 액세스하는 경우 특정 파이프라인이 실패할 수 있습니다. 파이프라인 오류를 완화하기 위해 Project 빌드 서비스 계정에 원하는 리소스에 대한 액세스 권한을 명시적으로 부여할 수 있습니다. 이러한 보안 설정을 설정하는 것이 좋습니다.

  • 빌드 서비스 리포지토리 범위 액세스 제한

    액세스 토큰의 범위를 제한하여 파이프라인 보안을 개선할 때 Azure Pipelines 이제 해당 리포지토리 액세스 범위를 YAML 기반 파이프라인에 필요한 리포지토리로만 지정할 수 있습니다. 즉, 파이프라인의 액세스 토큰이 누출되면 파이프라인에서 사용되는 리포지토리만 볼 수 있습니다. 이전에는 액세스 토큰이 프로젝트의 모든 Azure Repos 리포지토리 또는 잠재적으로 전체 컬렉션에 적합했습니다.

    이 기능은 새 프로젝트 및 컬렉션에 대해 기본적으로 설정됩니다. 기존 컬렉션의 경우 컬렉션 설정>Pipelines설정> 사용하도록 설정해야 합니다. 이 기능을 사용하는 경우 빌드에 필요한 모든 리포지토리(스크립트를 사용하여 복제하는 리포지토리)가 파이프라인의 리포지토리 리소스 에 포함되어야 합니다.

  • 액세스 토큰에 대한 특정 권한 제거

    기본적으로 액세스 토큰에 대한 여러 권한을 부여합니다. 이 권한 중 하나는 큐 빌드입니다. 이 업데이트를 통해 액세스 토큰에 대한 이 권한을 제거했습니다. 파이프라인에 이 권한이 필요한 경우 사용하는 토큰에 따라 Project Build Service 계정 또는 Project 컬렉션 빌드 서비스 계정에 명시적으로 부여할 수 있습니다.

서비스 연결에 대한 Project 수준 보안

서비스 연결에 대한 허브 수준 보안을 추가했습니다. 이제 사용자를 추가/제거하고, 역할을 할당하고, 모든 서비스 연결에 대한 중앙 집중식 위치에서 액세스를 관리할 수 있습니다.

Screenshot of the Service connections page with the Security option called out.

단계 대상 지정 및 명령 격리

Azure Pipelines 컨테이너 또는 에이전트 호스트에서 실행 작업을 지원합니다. 이전에는 전체 작업이 이러한 두 대상 중 하나로 설정되었습니다. 이제 선택한 대상에서 개별 단계(작업 또는 스크립트)를 실행할 수 있습니다. 단계가 다른 컨테이너를 대상으로 할 수도 있으므로 파이프라인은 특수한 용도로 빌드된 컨테이너에서 각 단계를 실행할 수 있습니다.

컨테이너는 격리 경계 역할을 하여 코드가 호스트 컴퓨터에서 예기치 않게 변경되지 않도록 할 수 있습니다. 단계 가 에이전트와 통신하고 서비스에 액세스 하는 방식은 컨테이너의 단계를 격리하여 영향을 받지 않습니다. 따라서 단계 대상과 함께 사용할 수 있는 명령 제한 모드도 도입되었습니다. 이 기능을 켜면 단계가 에이전트에서 요청할 수 있는 서비스가 제한됩니다. 더 이상 로그를 연결하고 아티팩트 및 특정 다른 작업을 업로드할 수 없습니다.

다음은 작업 컨테이너 및 다른 컨테이너의 호스트에서 실행 중인 단계를 보여 주는 포괄적인 예제입니다.

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

읽기 전용 변수

시스템 변수는 변경할 수 없는 것으로 문서화되었지만 실제로는 태스크에서 덮어쓸 수 있으며 다운스트림 작업은 새 값을 선택합니다. 이 업데이트를 통해 파이프라인 변수에 대한 보안을 강화하여 시스템 및 큐 시간 변수를 읽기 전용으로 만듭니다. 또한 YAML 변수를 다음과 같이 표시하여 읽기 전용으로 만들 수 있습니다.

variables:
- name: myVar
  value: myValue
  readonly: true

서비스 연결에 대한 역할 기반 액세스

서비스 연결에 대한 역할 기반 액세스가 추가되었습니다. 이전에는 엔드포인트 관리자 및 엔드포인트 작성자와 같은 미리 정의된 Azure DevOps 그룹을 통해서만 서비스 연결 보안을 관리할 수 있었습니다.

이 작업의 일환으로 독자, 사용자, 작성자 및 관리자의 새로운 역할을 소개했습니다. 프로젝트의 서비스 연결 페이지를 통해 이러한 역할을 설정할 수 있으며 개별 연결에서 상속됩니다. 또한 각 서비스 연결에서 상속을 설정하거나 해제하고 서비스 연결 범위에서 역할을 재정의하는 옵션이 있습니다.

Screenshot that shows role-based access for service connections.

서비스 연결 보안에 대한 자세한 내용은 여기를 참조하세요.

서비스 연결의 프로젝트 간 공유

프로젝트 간에 서비스 연결 공유에 대한 지원을 사용하도록 설정했습니다. 이제 안전하고 안전하게 프로젝트와 서비스 연결을 공유할 수 있습니다.

Screenshot that shows cross-project sharing of service connections.

여기에서 공유하는 서비스 연결에 대해 자세히 알아봅니 .

파이프라인 및 ACR 리소스에 대한 추적 가능성

파이프라인 및 ACR 컨테이너 리소스가 파이프라인에서 사용되는 경우 전체 E2E 추적 가능성을 보장합니다. YAML 파이프라인에서 사용하는 모든 리소스에 대해 커밋, 작업 항목 및 아티팩트로 다시 추적할 수 있습니다.

파이프라인 실행 요약 보기에서 다음을 확인할 수 있습니다.

  • 실행을 트리거한 리소스 버전입니다. 이제 다른 Azure 파이프라인 실행이 완료되거나 컨테이너 이미지가 ACR로 푸시될 때 파이프라인을 트리거할 수 있습니다.

    Screenshot showing that a pipeline was automatically triggered.

  • 파이프라인 에서 사용하는 커밋 입니다. 파이프라인에서 사용하는 각 리소스에 의한 커밋 분석도 확인할 수 있습니다.

    Screenshot showing the commits in the Current pipeline section.

  • 파이프라인에서 사용하는 각 리소스와 연결된 작업 항목 입니다.

  • 실행에서 사용할 수 있는 아티팩 트입니다.

    Screenshot showing the Artifacts page for the pipeline.

환경의 배포 보기에서 환경에 배포된 각 리소스에 대한 커밋 및 작업 항목을 볼 수 있습니다.

Screenshot of the Deployment by section showing the Workitems tab.

대규모 테스트 첨부 파일 지원

Azure Pipelines 테스트 결과 게시 작업을 사용하면 테스트를 실행할 때 테스트 결과를 게시하여 포괄적인 테스트 보고 및 분석 환경을 제공할 수 있습니다. 지금까지 테스트 실행 및 테스트 결과 모두에 대한 테스트 첨부 파일의 경우 100MB의 제한이 있었습니다. 이로 인해 크래시 덤프 또는 비디오와 같은 큰 파일의 업로드가 제한되었습니다. 이 업데이트에서는 실패한 테스트 문제를 해결하기 위해 사용 가능한 모든 데이터를 포함할 수 있도록 대규모 테스트 첨부 파일에 대한 지원을 추가했습니다.

로그에 403 또는 407 오류를 반환하는 VSTest 작업 또는 테스트 결과 게시 태스크가 표시될 수 있습니다. 아웃바운드 요청을 필터링하는 방화벽 뒤에서 자체 호스팅 빌드 또는 릴리스 에이전트를 사용하는 경우 이 기능을 사용할 수 있도록 몇 가지 구성을 변경해야 합니다. ​

Screenshot showing a 403 error returned in the logs.

이 문제를 해결하려면 아웃바운드 요청에 대한 방화벽을 업데이트하는 https://*.vstmrblob.vsassets.io것이 좋습니다. 여기서 설명서에서 문제 해결 정보를 찾을 수 있습니다. ​

참고

이는 자체 호스팅 Azure Pipelines 에이전트를 사용하고 아웃바운드 트래픽을 필터링하는 방화벽 뒤에 있는 경우에만 필요합니다. 클라우드에서 Microsoft 호스팅 에이전트를 사용하거나 아웃바운드 네트워크 트래픽을 필터링하지 않는 경우 아무 작업도 수행할 필요가 없습니다.

각 작업에 올바른 풀 정보 표시

이전에는 행렬을 사용하여 작업 또는 변수를 확장하여 풀을 식별할 때 로그 페이지에서 잘못된 풀 정보를 확인했습니다. 이러한 문제가 해결되었습니다.

새 분기에 대한 CI 트리거

새 분기가 만들어지고 분기가 변경되지 않은 경우 CI 빌드를 트리거하지 않는 것은 오랫동안 보류 중인 요청이었습니다. 다음 예제를 살펴보세요.

  • 웹 인터페이스를 사용하여 기존 분기를 기반으로 새 분기를 만듭니다. 그러면 분기 필터가 새 분기의 이름과 일치하는 경우 새 CI 빌드가 즉시 트리거됩니다. 기존 분기와 비교할 때 새 분기의 콘텐츠가 동일하기 때문에 이는 원치 않습니다.
  • 앱과 문서라는 두 개의 폴더가 있는 리포지토리가 있습니다. "앱"에 일치하도록 CI에 대한 경로 필터를 설정합니다. 즉, 변경 내용이 문서에 푸시된 경우 새 빌드를 만들지 않으려는 것입니다. 로컬로 새 분기를 만들고, 문서를 변경한 다음, 해당 분기를 서버로 푸시합니다. 새 CI 빌드를 트리거하는 데 사용했습니다. docs 폴더에서 변경 내용을 찾지 말라고 명시적으로 요청했기 때문에 이는 원치 않습니다. 그러나 새 분기 이벤트를 처리하는 방식 때문에 앱 폴더도 변경된 것처럼 보입니다.

이제 이러한 문제를 해결하기 위해 새 분기에 대한 CI를 처리하는 더 나은 방법이 있습니다. 새 분기를 게시할 때 해당 분기에서 새 커밋을 명시적으로 찾고 경로 필터와 일치하는지 확인합니다.

작업은 이전 단계의 출력 변수에 액세스할 수 있습니다.

이제 YAML 기반 파이프라인의 여러 단계에서 출력 변수를 사용할 수 있습니다. 이렇게 하면 이동/이동 안 됨 의사 결정 또는 생성된 출력의 ID와 같은 유용한 정보를 한 단계에서 다음 단계로 전달할 수 있습니다. 이전 단계 및 해당 작업의 결과(상태)도 사용할 수 있습니다.

출력 변수는 여전히 작업 내의 단계에 의해 생성됩니다. 단계를 참조하는 dependencies.jobName.outputs['stepName.variableName']대신 을 참조합니다 stageDependencies.stageName.jobName.outputs['stepName.variableName'].

참고

기본적으로 파이프라인의 각 단계는 YAML 파일의 바로 앞에 있는 단계에 따라 달라집니다. 따라서 각 단계에서는 이전 단계의 출력 변수를 사용할 수 있습니다. 종속성 그래프를 변경할 수 있습니다. 그러면 사용할 수 있는 출력 변수도 변경됩니다. 예를 들어 3단계에 1단계의 변수가 필요한 경우 1단계에서 명시적 종속성을 선언해야 합니다.

풀 수준에서 자동 에이전트 업그레이드 사용 안 함

현재 파이프라인 에이전트는 필요한 경우 자동으로 최신 버전으로 업데이트됩니다. 이 문제는 일반적으로 새 기능 또는 최신 에이전트 버전이 올바르게 작동해야 하는 작업이 있는 경우에 발생합니다. 이 업데이트를 통해 풀 수준에서 자동 업그레이드를 사용하지 않도록 설정하는 기능이 추가되었습니다. 이 모드에서 올바른 버전의 에이전트가 풀에 연결되어 있지 않으면 에이전트에 업데이트를 요청하는 대신 명확한 오류 메시지와 함께 파이프라인이 실패합니다. 이 기능은 대부분 자체 호스팅 풀과 매우 엄격한 변경 제어 요구 사항이 있는 고객에게 중요합니다. 자동 업데이트는 기본적으로 사용하도록 설정되며 대부분의 고객은 사용하지 않도록 설정하는 것이 좋습니다.

Sceenshot of the Default Settings page with the Agent update settings option turned on and called out.

에이전트 진단

많은 네트워킹 문제 및 업그레이드 실패의 일반적인 원인과 같은 많은 일반적인 에이전트 관련 문제에 대한 진단을 추가했습니다. 진단을 시작하려면 Windows run.sh --diagnostics 또는 run.cmd --diagnostics를 사용합니다.

YAML 파이프라인에 대한 서비스 후크

서비스를 YAML 파이프라인과 통합하는 것이 더 쉬워졌습니다. YAML 파이프라인에 대한 서비스 후크 이벤트를 사용하면 이제 파이프라인 실행 진행률에 따라 사용자 지정 앱 또는 서비스에서 활동을 구동할 수 있습니다. 예를 들어 승인이 필요할 때 기술 지원팀 티켓을 만들거나, 스테이지가 완료된 후 모니터링 워크플로를 시작하거나, 스테이지가 실패할 때 팀의 모바일 디바이스에 푸시 알림을 보낼 수 있습니다.

파이프라인 이름 및 스테이지 이름에 대한 필터링은 모든 이벤트에 대해 지원됩니다. 승인 이벤트는 특정 환경에 대해서도 필터링할 수 있습니다. 마찬가지로 상태 변경 이벤트는 파이프라인 실행 또는 스테이지의 새 상태로 필터링할 수 있습니다.

Screenshot of the NEW SERVICE HOOKS SUBSCRIPTION wizard showing the Trigger on this type of event dropdown list with the Run stage options called out.

최적화 통합

Optimizely는 제품 팀을 위한 강력한 A/B 테스트 및 기능 플래그 지정 플랫폼입니다. Azure Pipelines Optimizely 실험 플랫폼과 통합하면 제품 팀이 빠른 속도로 테스트, 학습 및 배포하는 동시에 Azure Pipelines 모든 DevOps 이점을 얻을 수 있습니다.

Azure DevOps 대한 Optimizely 확장은 빌드 및 릴리스 파이프라인에 실험 및 기능 플래그 롤아웃 단계를 추가하므로 Azure Pipelines 사용하여 지속적으로 반복, 롤아웃 및 롤백할 수 있습니다.

Azure DevOps Optimizely 확장에 대해 자세히 알아보세요.

Optimizely

아티팩트 원본으로 GitHub 릴리스 추가

이제 GitHub 릴리스를 Azure DevOps 릴리스 파이프라인에서 아티팩트 원본으로 연결할 수 있습니다. 이렇게 하면 배포의 일부로 GitHub 릴리스를 사용할 수 있습니다.

릴리스 파이프라인 정의에서 아티팩트 추가를 클릭하면 새 GitHub 릴리스 원본 유형을 찾을 수 있습니다. 서비스 연결 및 GitHub 리포지토리를 제공하여 GitHub 릴리스를 사용할 수 있습니다. GitHub 릴리스의 기본 버전을 선택하여 최신 특정 태그 버전으로 사용하거나 릴리스를 만들 때 선택할 수도 있습니다. GitHub 릴리스가 연결되면 자동으로 다운로드되고 릴리스 작업에서 사용할 수 있게 됩니다.

Screenshot of the Add an artifact dialog box with the GitHub Release option selected and called out.

Azure Pipelines Terraform 통합

Terraform은 인프라를 안전하고 효율적으로 개발, 변경 및 버전 관리하기 위한 오픈 소스 도구입니다. Terraform은 API를 선언적 구성 파일로 코딩하여 고급 구성 언어를 사용하여 인프라를 정의하고 프로비전할 수 있도록 합니다. Terraform 확장을 사용하여 Azure, AWS(Amazon Web Services) 및 GCP(Google Cloud Platform)와 같은 모든 주요 인프라 공급자에서 리소스를 만들 수 있습니다.

Terraform 확장에 대한 자세한 내용은 여기 설명서를 참조 하세요.

Screenshot of the Terraform integration with Azure Pipelines.

Google Analytics와 통합

Google Analytics 실험 프레임워크를 사용하면 웹 사이트 또는 앱에 대한 거의 모든 변경 또는 변형을 테스트하여 특정 목표에 미치는 영향을 측정할 수 있습니다. 예를 들어 사용자가 완료하려는 활동(예: 구매, 뉴스레터 등록) 및/또는 개선하려는 메트릭(예: 수익, 세션 기간, 반송률)이 있을 수 있습니다. 이러한 활동을 통해 기능 성능에 미치는 직접적인 영향에 따라 구현할 가치가 있는 변경 내용을 식별할 수 있습니다.

Azure DevOps 대한 Google Analytics 실험 확장은 빌드 및 릴리스 파이프라인에 실험 단계를 추가하므로 Azure Pipelines 모든 DevOps 이점을 확보하면서 실험을 지속적으로 관리하여 가속 속도로 지속적으로 반복, 학습 및 배포할 수 있습니다.

Marketplace에서 Google Analytics 실험 확장을 다운로드할 수 있습니다.

Screenshot showing the Google Analytics Experiments task.

Azure Pipelines ServiceNow 통합 업데이트

ServiceNow용 Azure Pipelines 앱은 Azure Pipelines ServiceNow 변경 관리를 통합하는 데 도움이 됩니다. 이 업데이트를 사용하면 뉴욕 버전의 ServiceNow와 통합할 수 있습니다. 이제 OAuth 및 기본 인증을 사용하여 두 서비스 간의 인증을 수행할 수 있습니다. 또한 이제 모든 변경 속성을 사용하여 게이트 결과를 결정할 수 있도록 고급 성공 조건을 구성할 수 있습니다.

VSCode에서 Azure Pipelines 만들기

VSCode용 Azure Pipelines 확장에 새로운 기능이 추가되었습니다. 이제 IDE를 벗어나지 않고 VSCode에서 직접 Azure Pipelines 만들 수 있습니다.

Screenshot of VS Code with an alert in the lower-right corner that says: Your pipeline has been set up successfully.

벗겨진 버그 관리 및 해결 방법

탐지, 보고 및 해결을 통해 종단 간 수명 주기를 지원하기 위해 벗겨진 테스트 관리를 도입했습니다. 이를 더욱 개선하기 위해 테스트 버그 관리 및 해결 방법을 추가하고 있습니다.

벗겨진 테스트를 조사하는 동안 버그 동작을 사용하여 버그 를 만들 수 있습니다. 그러면 개발자에게 할당하여 잘못된 테스트의 근본 원인을 추가로 조사할 수 있습니다. 버그 보고서에는 오류 메시지, 스택 추적 및 테스트와 관련된 기타 정보와 같은 파이프라인에 대한 정보가 포함됩니다.

버그 보고서가 해결되거나 닫히면 테스트의 표시를 자동으로 취소합니다.

최소 테스트 수가 실행되지 않는 경우 VSTest 태스크가 실패하도록 설정

VSTest 작업은 사용 중인 테스트 프레임워크와 관련된 테스트 어댑터뿐만 아니라 사용자 입력(테스트 파일, 필터 조건 등)을 사용하여 테스트를 검색하고 실행합니다. 사용자 입력 또는 테스트 어댑터를 변경하면 테스트가 검색되지 않고 예상되는 테스트의 하위 집합만 실행되는 경우가 발생할 수 있습니다. 이로 인해 코드 품질이 충분히 높기보다는 테스트를 건너뛰기 때문에 파이프라인이 성공하는 상황이 발생할 수 있습니다. 이러한 상황을 방지하기 위해 VSTest 태스크에 태스크를 통과하기 위해 실행해야 하는 최소 테스트 수를 지정할 수 있는 새 옵션이 추가되었습니다.

Screenshot showing the Fail the task if a minimum number of tests are not run option.

VSTest TestResultsDirectory 옵션은 작업 UI에서 사용할 수 있습니다.

VSTest 작업은 테스트 결과 및 관련 파일을 폴더에 $(Agent.TempDirectory)\TestResults 저장합니다. 테스트 결과를 저장하도록 다른 폴더를 구성할 수 있도록 작업 UI에 옵션을 추가했습니다. 이제 특정 위치의 파일이 필요한 후속 작업에서 사용할 수 있습니다.

Screenshot showing the Test results folder text box.

자동화된 테스트 오류 메시지의 Markdown 지원

자동화된 테스트에 대한 오류 메시지에 Markdown 지원을 추가했습니다. 이제 테스트 실행 및 테스트 결과 모두에 대한 오류 메시지의 서식을 쉽게 지정하여 가독성을 향상시키고 Azure Pipelines 테스트 실패 문제 해결 환경을 완화할 수 있습니다. 지원되는 markdown 구문은 여기에서 찾을 수 있습니다.

Screenshot showing markdown support in automated test error messages.

파이프라인 데코레이터를 사용하여 배포 작업에 자동으로 단계 삽입

이제 파이프라인 데코레이터를 배포 작업에 추가할 수 있습니다. 모든 배포 작업의 모든 수 명 주기 후크 실행에 사용자 지정 단계(예: 취약성 스캐너)를 자동으로 삽입할 수 있습니다. 파이프라인 데코레이터는 컬렉션의 모든 파이프라인에 적용할 수 있으므로 안전한 배포 방법을 적용하는 과정의 일부로 활용할 수 있습니다.

또한 배포 작업은 정의된 경우 서비스 사이드카와 함께 컨테이너 작업으로 실행할 수 있습니다.

Test Plans

새 테스트 계획 페이지

모든 Azure DevOps 컬렉션에서 새 Test Plans 페이지(Test Plans *)를 사용할 수 있습니다. 새 페이지에서는 현재 작업(테스트 계획, 작성 또는 실행)에 집중할 수 있도록 간소화된 보기를 제공합니다. 또한 복잡하지 않으며 나머지 Azure DevOps 제품과 일치합니다.

Screenshot showing two identially named test plans that share a backend store.

새 페이지를 이해하는 데 도움을 주세요.

test plan overview page

새 Test Plans 페이지에는 총 6개의 섹션이 있으며, 그 중 처음 4개 섹션은 새로운 섹션이며 차트 & 확장성 섹션은 기존 기능입니다.

  1. 테스트 계획 헤더: 테스트 계획을 찾고, 즐겨찾기, 편집, 복사 또는 복제하는 데 사용합니다.
  2. 테스트 도구 모음 트리: 테스트 도구 모음을 추가, 관리, 내보내기 또는 주문하는 데 사용합니다. 이를 활용하여 구성을 할당하고 사용자 승인 테스트를 수행합니다.
  3. 정의 탭: 이 탭을 통해 선택한 테스트 도구 모음에서 테스트 사례를 데이터 정렬, 추가 및 관리합니다.
  4. 실행 탭: 이 탭을 통해 테스트를 할당하고 실행하거나 드릴인할 테스트 결과를 찾습니다.
  5. 차트 탭: 대시보드에 고정할 수도 있는 차트를 통해 테스트 실행 및 상태를 추적합니다.
  6. 확장성: 제품 내의 현재 확장성 지점을 지원합니다 .

아래에서 이러한 새 섹션을 광범위하게 볼 수 있습니다.

1. 계획 헤더 테스트

test plan header page

작업

테스트 계획 헤더를 사용하면 다음 작업을 수행할 수 있습니다.

  • 테스트 계획을 즐겨찾기로 표시
  • 즐겨찾는 테스트 계획 표시 해제
  • 즐겨 찾는 테스트 계획 중에서 쉽게 탐색
  • 테스트 계획이 현재 또는 과거인지 명확하게 나타내는 테스트 계획의 반복 경로를 봅니다.
  • 보고서로 이동할 링크가 있는 테스트 진행률 보고서의 빠른 요약 보기
  • 전체/광산 Test Plans 페이지로 다시 이동합니다.

상황에 맞는 메뉴 옵션

테스트 계획 헤더의 상황에 맞는 메뉴에서는 다음 옵션을 제공합니다.

  • 테스트 계획 복사: 현재 테스트 계획을 빠르게 복사할 수 있는 새로운 옵션입니다. 아래 세부 정보를 참조하세요.
  • 테스트 계획 편집: 이 옵션을 사용하면 테스트 계획 작업 항목 양식을 편집하여 작업 항목 필드를 관리할 수 있습니다.
  • 테스트 계획 설정: 이 옵션을 사용하면 테스트 실행 설정(빌드 또는 릴리스 파이프라인 연결) 및 테스트 결과 설정을 구성할 수 있습니다.

테스트 계획 복사(새 기능)

copy test plan page

스프린트/릴리스당 새 테스트 계획을 만드는 것이 좋습니다. 이렇게 하면 일반적으로 이전 주기에 대한 테스트 계획을 복사할 수 있으며 몇 가지 변경 내용으로 복사된 테스트 계획이 새 주기에 대해 준비됩니다. 이 프로세스를 쉽게 하기 위해 새 페이지에서 '테스트 계획 복사' 기능을 사용하도록 설정했습니다. 이를 활용하여 테스트 계획을 복사하거나 복제할 수 있습니다. 지원 REST API는 여기에서 다루며 API를 사용하면 여러 프로젝트에서 테스트 계획을 복사/복제할 수 있습니다.
Test Plans 사용에 대한 자세한 지침은 여기를 참조하세요.

2. 테스트 도구 모음 트리

test suites tree page

작업

테스트 도구 모음 헤더를 사용하면 다음 작업을 수행할 수 있습니다.

  • 확장/축소: 이 도구 모음 옵션을 사용하면 제품군 계층 트리를 확장하거나 축소할 수 있습니다.
  • 자식 도구 모음의 테스트 지점 표시: 이 도구 모음 옵션은 "실행" 탭에 있는 경우에만 표시됩니다. 이렇게 하면 개별 제품군으로 한 번에 하나씩 이동할 필요 없이 테스트 지점을 보다 쉽게 관리할 수 있도록 지정된 제품군 및 해당 자식에 대한 모든 테스트 지점을 한 보기로 볼 수 있습니다.
  • 주문 제품군: 제품군을 끌어서 놓으면 제품군의 계층 구조를 다시 정렬하거나 테스트 계획 내의 한 제품군 계층에서 다른 제품군 계층으로 이동할 수 있습니다.

상황에 맞는 메뉴 옵션

테스트 도구 모음 트리의 상황에 맞는 메뉴에서는 다음 옵션을 제공합니다.

  • 새 제품군 만들기: 다음과 같이 3가지 유형의 제품군을 만들 수 있습니다.
    • 정적 제품군 또는 폴더 그룹을 사용하여 테스트를 구성합니다.
    • 원활한 추적을 위해 요구 사항 기반 제품군을 사용하여 요구 사항/사용자 스토리에 직접 연결합니다.
    • 쿼리 기반을 사용하여 쿼리 조건을 충족하는 테스트 사례를 동적으로 구성합니다.
  • 구성 할당: 제품군에 대한 구성(예: Chrome, Firefox, EdgeChromium)을 할당할 수 있으며, 이러한 구성은 나중에 이 제품군에 추가하는 모든 기존 테스트 사례 또는 새 테스트 사례에 적용할 수 있습니다.
  • pdf/전자 메일로 내보내기: 테스트 계획 속성, 테스트 도구 모음 속성 및 테스트 사례 및 테스트 지점에 대한 세부 정보를 "전자 메일" 또는 "pdf로 인쇄"로 내보냅니다.
  • 테스트 도구 모음 작업 항목 열기: 이 옵션을 사용하면 테스트 도구 모음 작업 항목 양식을 편집하여 작업 항목 필드를 관리할 수 있습니다.
  • 모든 테스트를 실행하도록 테스터 할당: 이 옵션은 일반적으로 다른 부서에 속하는 여러 테스터가 동일한 테스트를 실행/실행해야 하는 UAT(사용자 승인 테스트) 시나리오에 매우 유용합니다.
  • 이름 바꾸기/삭제: 이러한 옵션을 사용하면 제품군 이름을 관리하거나 테스트 계획에서 제품군 및 해당 콘텐츠를 제거할 수 있습니다.

3. 정의 탭

define tab page

정의 탭을 사용하면 테스트 도구 모음에 대한 테스트 사례를 대조, 추가 및 관리할 수 있습니다. 반면 실행 탭은 테스트 지점을 할당하고 실행하기 위한 것입니다.

정의 탭 및 특정 작업은 기본 + Test Plans 액세스 수준 또는 동등한 사용자만 사용할 수 있습니다. 다른 모든 항목은 '기본' 액세스 수준을 가진 사용자가 행사할 수 있어야 합니다.

작업

정의 탭을 사용하면 다음 작업을 수행할 수 있습니다.

  • 작업 항목 양식을 사용하여 새 테스트 사례 추가: 이 옵션을 사용하면 작업 항목 양식을 사용하여 새 테스트 사례를 만들 수 있습니다. 생성된 테스트 사례가 자동으로 제품군에 추가됩니다.
  • 그리드를 사용하여 새 테스트 사례 추가: 이 옵션을 사용하면 테스트 사례 그리드 보기를 사용하여 하나 이상의 테스트 사례를 만들 수 있습니다. 생성된 테스트 사례는 자동으로 제품군에 추가됩니다.
  • 쿼리를 사용하여 기존 테스트 사례 추가: 이 옵션을 사용하면 쿼리를 지정하여 기존 테스트 사례를 제품군에 추가할 수 있습니다.
  • 끌어서 놓기를 통해 테스트 사례 정렬: 지정된 제품군 내에서 하나 이상의 테스트 사례를 끌어서 놓아 테스트 사례를 다시 정렬할 수 있습니다. 테스트 사례의 순서는 수동 테스트 사례에만 적용되며 자동화된 테스트에는 적용되지 않습니다.
  • 테스트 사례를 한 도구 모음에서 다른 제품군으로 이동: 끌어서 놓기를 사용하여 테스트 사례를 한 테스트 도구 모음에서 다른 테스트 도구 모음으로 이동할 수 있습니다.
  • 그리드 표시: 테스트 단계와 함께 테스트 사례를 보거나 편집하는 데 그리드 모드를 사용할 수 있습니다.
  • 전체 화면 보기: 이 옵션을 사용하여 전체 화면 모드에서 전체 정의 탭의 내용을 볼 수 있습니다.
  • 필터링: 필터 표시줄을 사용하여 "테스트 사례 제목", "할당 대상" 및 "상태" 필드를 사용하여 테스트 사례 목록을 필터링할 수 있습니다. 열 머리글을 클릭하여 목록을 정렬할 수도 있습니다.
  • 열 옵션: "열 옵션"을 사용하여 정의 탭에 표시되는 열 목록을 관리할 수 있습니다. 선택할 수 있는 열 목록은 주로 테스트 사례 작업 항목 양식의 필드입니다.

상황에 맞는 메뉴 옵션

define tab context menu page

정의 탭 내의 테스트 사례 노드에 있는 상황에 맞는 메뉴에는 다음 옵션이 제공됩니다.

  • 테스트 사례 작업 항목 양식 열기/편집: 이 옵션을 사용하면 테스트 단계를 포함하여 작업 항목 필드를 편집할 수 있는 작업 항목 양식을 사용하여 테스트 사례를 편집할 수 있습니다.
  • 테스트 사례 편집: 이 옵션을 사용하면 테스트 사례 작업 항목 필드를 대량 편집할 수 있습니다. 그러나 이 옵션을 사용하여 테스트 단계를 대량 편집할 수는 없습니다.
  • 그리드에서 테스트 사례 편집: 이 옵션을 사용하면 그리드 보기를 사용하여 테스트 단계를 포함하여 선택한 테스트 사례를 대량으로 편집할 수 있습니다.
  • 구성 할당: 이 옵션을 사용하면 테스트 사례 수준 구성을 사용하여 제품군 수준 구성을 재정의할 수 있습니다.
  • 테스트 사례 제거: 이 옵션을 사용하면 지정된 제품군에서 테스트 사례를 제거할 수 있습니다. 하지만 기본 테스트 사례 작업 항목은 변경되지 않습니다.
  • 테스트 사례의 복사/복제 만들기: 이 옵션을 사용하면 선택한 테스트 사례의 복사/복제를 만들 수 있습니다. 자세한 내용은 다음을 참조하세요.
  • 연결된 항목 보기: 이 옵션을 사용하면 지정된 테스트 사례에 대한 연결된 항목을 볼 수 있습니다. 자세한 내용은 다음을 참조하세요.

테스트 사례 복사/복제(새 기능)

define tab copy test cases page

테스트 사례를 복사/복제하려는 시나리오의 경우 "테스트 사례 복사" 옵션을 사용할 수 있습니다. 복사/복제된 테스트 사례를 만들 대상 프로젝트, 대상 테스트 계획 및 대상 테스트 제품군을 지정할 수 있습니다. 또한 복제된 복사본으로 흐를 기존 링크/첨부 파일을 포함할지 여부를 지정할 수도 있습니다.

연결된 항목 보기(새 기능)

define tab view linked items page

테스트 아티팩트, 요구 사항 및 버그 간의 추적성은 Test Plans 제품의 중요한 가치 제안입니다. "연결된 항목 보기" 옵션을 사용하면 이 테스트 사례가 연결된 모든 연결된 요구 사항, 이 테스트 사례가 사용된 모든 테스트 도구 모음/테스트 계획 및 테스트 실행의 일부로 제출된 모든 버그를 쉽게 확인할 수 있습니다.

4. 실행 탭

execute tab page

정의 탭을 사용하면 테스트 도구 모음에 대한 테스트 사례를 대조, 추가 및 관리할 수 있습니다. 반면 실행 탭은 테스트 지점을 할당하고 실행하기 위한 것입니다.

테스트 지점이란? 테스트 사례 자체는 실행 가능하지 않습니다. 테스트 도구 모음에 테스트 사례를 추가하면 테스트 지점이 생성됩니다. 테스트 지점은 테스트 사례, 테스트 도구 모음, 구성 및 테스터의 고유한 조합입니다. 예: 테스트 사례를 "테스트 로그인 기능"으로 사용하고 2개의 구성을 Edge 및 Chrome으로 추가하면 2개의 테스트 지점이 생성됩니다. 이제 이러한 테스트 지점을 실행할 수 있습니다. 실행 시 테스트 결과가 생성됩니다. 테스트 결과 보기(실행 기록)를 통해 테스트 지점의 모든 실행을 볼 수 있습니다. 테스트 지점에 대한 최신 실행은 실행 탭에 표시되는 내용입니다.
따라서 테스트 사례는 재사용 가능한 엔터티입니다. 테스트 계획 또는 제품군에 포함하면 테스트 지점이 생성됩니다. 테스트 지점을 실행하여 개발 중인 제품 또는 서비스의 품질을 결정합니다.

새 페이지의 주요 이점 중 하나는 주로 테스트 실행/추적을 수행하는 사용자('기본' 액세스 수준만 있어야 함)가 제품군 관리의 복잡성에 압도되지 않는다는 것입니다(정의 탭은 이러한 사용자에 대해 숨겨짐).

정의 탭 및 특정 작업은 기본 + Test Plans 액세스 수준 또는 동등한 사용자만 사용할 수 있습니다. "실행" 탭을 비롯한 다른 모든 항목은 '기본' 액세스 수준이 있는 사용자가 실행할 수 있어야 합니다.

작업

실행 탭을 사용하면 다음 작업을 수행할 수 있습니다.

  • 대량 표시 테스트 지점: 이 옵션을 사용하면 테스트 실행기를 통해 테스트 사례를 실행하지 않고도 통과, 실패, 차단 또는 적용할 수 없는 테스트 지점의 결과를 신속하게 표시할 수 있습니다. 한 번에 하나 이상의 테스트 지점에 대한 결과를 표시할 수 있습니다.
  • 테스트 지점 실행: 이 옵션을 사용하면 각 테스트 단계를 개별적으로 진행하여 테스트 실행기를 사용하여 통과/실패를 표시하여 테스트 사례를 실행할 수 있습니다. 테스트 중인 애플리케이션에 따라 데스크톱 및/또는 웹 애플리케이션을 테스트하기 위해 "웹 애플리케이션" 또는 "데스크톱 실행기"를 테스트하는 데 "Web Runner"를 사용할 수 있습니다. "옵션으로 실행"을 호출하여 수행하려는 테스트에 대한 빌드를 지정할 수도 있습니다.
  • 열 옵션: "열 옵션"을 사용하여 실행 탭에 표시되는 열 목록을 관리할 수 있습니다. 선택에 사용할 수 있는 열 목록은 실행 기준, 할당된 테스터, 구성 등과 같은 테스트 지점과 연결됩니다.
  • 전체 화면 보기: 이 옵션을 사용하여 전체 실행 탭의 내용을 전체 화면 모드로 볼 수 있습니다.
  • 필터링: 필터 표시줄을 사용하여 "테스트 사례 제목", "할당 대상", "상태", "테스트 결과", "테스터" 및 "구성" 필드를 사용하여 테스트 지점 목록을 필터링할 수 있습니다. 열 머리글을 클릭하여 목록을 정렬할 수도 있습니다.

상황에 맞는 메뉴 옵션

execute tab context menu page

실행 탭 내의 테스트 지점 노드에 있는 상황에 맞는 메뉴에서는 다음 옵션을 제공합니다.

  • 테스트 결과 표시: 위와 동일하게 통과, 실패, 차단 또는 적용할 수 없는 테스트 지점의 결과를 신속하게 표시할 수 있습니다.
  • 테스트 지점 실행: 위와 동일하게 테스트 실행기를 통해 테스트 사례를 실행할 수 있습니다.
  • 테스트를 활성으로 다시 설정: 이 옵션을 사용하면 테스트 결과를 활성으로 다시 설정하여 테스트 지점의 마지막 결과를 무시할 수 있습니다.
  • 테스트 사례 작업 항목 양식 열기/편집: 이 옵션을 사용하면 테스트 단계를 포함하여 작업 항목 필드를 편집할 수 있는 작업 항목 양식을 사용하여 테스트 사례를 편집할 수 있습니다.
  • 테스터 할당: 이 옵션을 사용하면 테스트 실행을 위해 테스트 지점을 테스터에게 할당할 수 있습니다.
  • 테스트 결과 보기: 이 옵션을 사용하면 각 테스트 단계의 결과, 추가된 주석 또는 버그를 포함하여 최신 테스트 결과 세부 정보를 볼 수 있습니다.
  • 실행 기록 보기: 이 옵션을 사용하면 선택한 테스트 지점에 대한 전체 실행 기록을 볼 수 있습니다. 선택한 테스트 지점뿐만 아니라 전체 테스트 사례에 대한 실행 기록을 볼 수 있도록 필터를 조정할 수 있는 새 페이지가 열립니다.

Test Plans 진행률 보고서

이 기본 제공 보고서는 프로젝트에서 하나 이상의 Test Plans 실행 및 상태를 추적하는 데 도움이 됩니다. Test Plans > 진행률 보고서*를 방문하여 보고서 사용을 시작합니다.

Screenshot of the Test Plans section with the Progress report option highlighted.

보고서의 세 섹션은 다음과 같습니다.

  1. 요약: 선택한 테스트 계획에 대한 통합 보기를 표시합니다.
  2. 결과 추세: 매일 스냅샷을 렌더링하여 실행 및 상태 추세선을 제공합니다. 14일(기본값), 30일 또는 사용자 지정 범위에 대한 데이터를 표시할 수 있습니다.
  3. 세부 정보: 이 섹션에서는 각 테스트 계획을 드릴다운하고 각 테스트 도구 모음에 대한 중요한 분석을 제공합니다.

Screenshot of the Progress report.

Artifacts

참고

Azure DevOps Server 2020은 데이터를 가져오는 동안 휴지통에 있는 피드를 가져오지 않습니다. 휴지통에 있는 피드를 가져오려면 데이터 가져오기를 시작하기 전에 휴지통에서 복원하세요.

라이선스 식 및 포함된 라이선스

이제 Visual Studio 패키지를 검색하는 동안 Azure Artifacts 저장된 NuGet 패키지에 대한 라이선스 정보의 세부 정보를 볼 수 있습니다. 이는 라이선스 식 또는 포함된 라이선스를 사용하여 표현되는 라이선스에 적용됩니다. 이제 Visual Studio 패키지 세부 정보 페이지에서 라이선스 정보에 대한 링크를 볼 수 있습니다(아래 이미지의 빨간색 화살표).

Screenshot of the Newtonsoft.Json NuGet package with a red arrow pointing to the package's license.

링크를 클릭하면 라이선스의 세부 정보를 볼 수 있는 웹 페이지로 이동됩니다. 이 환경은 라이선스 식과 포함된 라이선스 모두에 대해 동일하므로 한 곳에서 Azure Artifacts 저장된 패키지에 대한 라이선스 세부 정보를 볼 수 있습니다(라이선스 정보를 지정하고 Visual Studio 지원되는 패키지의 경우).

Screenshot of a browser window dispalying the MIT licence text

간단한 인증 작업

이제 경량 인증 작업을 사용하여 Azure Pipelines 인기 있는 패키지 관리자에게 인증할 수 있습니다. 여기에는 NuGet, npm, PIP, Twine 및 Maven이 포함됩니다. 이전에는 패키지를 게시하고 다운로드하는 기능을 포함하여 많은 기능을 제공하는 작업을 사용하여 이러한 패키지 관리자에게 인증할 수 있었습니다. 그러나 패키지 관리자와 상호 작용하는 모든 활동에 이러한 작업을 사용해야 했습니다. 패키지 게시 또는 다운로드와 같은 작업을 수행하기 위해 실행할 고유한 스크립트가 있는 경우 파이프라인에서 사용할 수 없습니다. 이제 파이프라인 YAML에서 고유한 디자인의 스크립트를 사용하고 이러한 새로운 경량 작업을 사용하여 인증을 수행할 수 있습니다. npm 사용하는 예제:

Screenshot of an example of a lightweight authentication task.

이 그림에서 "ci" 및 "publish" 명령을 사용하는 것은 임의이므로 Azure Pipelines YAML에서 지원하는 모든 명령을 사용할 수 있습니다. 이렇게 하면 명령 호출을 완벽하게 제어할 수 있으며 파이프라인 구성에서 공유 스크립트를 쉽게 사용할 수 있습니다. 자세한 내용은 NuGet, npm, PIP, TwineMaven 인증 작업 설명서를 참조하세요.

피드 페이지 로드 시간 개선 사항

피드 페이지 로드 시간이 향상되었음을 발표하게 되어 기쁩니다. 평균적으로 피드 페이지 로드 시간은 10% 감소했습니다. 가장 큰 피드는 99번째 백분위수 피드 페이지 로드 시간(모든 피드 중 가장 높은 99%의 로드 시간)이 75% 감소한 것을 가장 많이 개선했습니다.

퍼블릭 피드를 사용하여 공개적으로 패키지 공유

이제 퍼블릭 피드 내에 패키지를 만들고 저장할 수 있습니다. 퍼블릭 피드 내에 저장된 패키지는 컬렉션에 있든 아니든, Azure DevOps 컬렉션에 로그인하든 관계없이 인증 없이 인터넷의 모든 사용자가 사용할 수 있습니다. 피드 설명서에서 공개 피드에 대해 자세히 알아보거나 패키지를 공개적으로 공유하기 위한 자습서로 바로 이동합니다.

Screenshot showing the PublicFeed page for your packages.

AAD 테넌트 내의 다른 컬렉션에서 업스트림 구성

이제 Azure Active Directory(AAD) 테넌트에 연결된 다른 컬렉션의 피드를 Artifacts 피드에 업스트림 원본으로 추가할 수 있습니다. 피드는 업스트림 원본으로 구성된 피드에서 패키지를 찾아서 사용할 수 있으므로 AAD 테넌트와 연결된 컬렉션 간에 패키지를 쉽게 공유할 수 있습니다. 문서에서 이를 설정하는 방법을 참조하세요.

Python 자격 증명 공급자를 사용하여 pip를 인증하고 Azure Artifacts 피드로 꼬기

이제 Python 자격 증명 공급자(아티팩트 키링)를 설치하고 사용하여 Azure Artifacts 피드에서 Python 패키지를 게시하거나 사용하는 인증을 자동으로 설정할 수 있습니다. 자격 증명 공급자를 사용하면 구성 파일(/pip.conf/.pypirc pip.ini)을 설정할 필요가 없습니다. pip 또는 twine을 처음 호출할 때 웹 브라우저에서 인증 흐름을 통해 간단히 수행됩니다. 설명서에서 자세한 내용을 참조하세요.

Visual Studio 패키지 관리자 피드 Azure Artifacts

이제 Azure Artifacts 피드에서 제공되는 패키지에 대한 Visual Studio NuGet 패키지 관리자 패키지 아이콘, 설명 및 작성자가 표시됩니다. 이전에는 이 메타데이터의 대부분이 VS에 제공되지 않았습니다.

피드 환경으로 업데이트된 커넥트

피드할 커넥트 대화 상자는 Azure Artifacts 사용하는 진입로입니다. Azure DevOps 피드에서 패키지를 푸시하고 끌어오도록 클라이언트 및 리포지토리를 구성하는 방법에 대한 정보가 포함되어 있습니다. 자세한 설정 정보를 추가하도록 대화 상자를 업데이트하고 지침을 제공하는 도구를 확장했습니다.

퍼블릭 피드는 이제 업스트림 지원과 함께 일반 공급됩니다.

공개 피드의 공개 미리 보기는 훌륭한 채택 및 피드백을 받았습니다. 이 릴리스에서는 추가 기능을 일반 공급으로 확장했습니다. 이제 프라이빗 피드에서 퍼블릭 피드를 업스트림 원본으로 설정할 수 있습니다. 프라이빗 피드와 프로젝트 범위 피드를 모두 업스트림할 수 있으므로 구성 파일을 간단하게 유지할 수 있습니다.

포털에서 프로젝트 범위 피드 만들기

공개 피드를 릴리스할 때 프로젝트 범위 피드도 릴리스했습니다. 지금까지 REST API를 통해 또는 퍼블릭 피드를 만든 다음 프로젝트를 비공개로 전환하여 프로젝트 범위 피드를 만들 수 있습니다. 이제 필요한 권한이 있는 경우 모든 프로젝트에서 포털에서 직접 프로젝트 범위 피드를 만들 수 있습니다. 프로젝트인 피드와 피드 선택기에서 컬렉션 범위가 지정된 피드를 확인할 수도 있습니다.

npm 성능 향상

Azure Artifacts 피드에 npm 패키지를 저장하고 제공하는 방식을 개선하기 위해 핵심 디자인을 변경했습니다. 이를 통해 npm 가장 많이 사용되는 일부 API의 대기 시간을 최대 10배까지 줄일 수 있습니다.

내게 필요한 옵션 기능 향

피드 페이지에서 접근성 문제를 해결하기 위한 수정 사항을 배포했습니다. 수정 사항에는 다음이 포함됩니다.

  • 피드 환경 만들기
  • 전역 피드 설정 환경
  • 피드 환경 커넥트

Wiki

코드 위키 페이지에 대한 다양한 편집

이전에는 코드 위키 페이지를 편집할 때 편집을 위해 Azure Repos 허브로 리디렉션되었습니다. 현재 리포지토리 허브는 markdown 편집에 최적화되지 않았습니다.

이제 wiki 내의 병렬 편집기에서 코드 위키 페이지를 편집할 수 있습니다. 이렇게 하면 다양한 markdown 도구 모음을 사용하여 프로젝트 wiki의 편집 환경과 동일한 콘텐츠를 만들 수 있습니다. 상황에 맞는 메뉴에서 Repos 편집 옵션을 선택하여 리포지토리에서 편집하도록 선택할 수 있습니다.

Screenshot showing the Edit menu with the Edit in Repos option called out.

위키 페이지에서 작업 항목 만들기 및 포함

피드백을 들으면서 wiki를 사용하여 브레인스토밍 문서, 계획 문서, 기능에 대한 아이디어, 사양 문서, 회의 시간(분)을 캡처하는 것을 들었습니다. 이제 위키 페이지를 벗어나지 않고 계획 문서에서 직접 기능 및 사용자 스토리를 쉽게 만들 수 있습니다.

작업 항목을 만들려면 위키 페이지에서 작업 항목을 포함할 텍스트를 선택하고 새 작업 항목을 선택합니다. 이렇게 하면 작업 항목을 먼저 만들 필요가 없으므로 시간을 절약하고 편집으로 이동한 다음 포함할 작업 항목을 찾습니다. 또한 wiki 범위를 벗어나지 않으므로 컨텍스트 전환을 줄입니다.

Short video showing how to create and embed work items from a wiki page.

wiki에서 작업 항목을 만들고 포함하는 방법에 대한 자세한 내용은 여기에서 설명서를 참조 하세요.

위키 페이지의 메모

이전에는 위키 내의 다른 위키 사용자와 상호 작용할 방법이 없었습니다. 이렇게 하면 메일 또는 채팅 채널을 통해 대화가 발생해야 했기 때문에 콘텐츠에 대한 공동 작업과 질문 받기가 어려운 과제에 응답했습니다. 이제 주석을 사용하여 위키 내에서 직접 다른 사용자와 공동 작업할 수 있습니다. 주석 내에서 사용자 기능을 활용하여 @mention 다른 팀 구성원의 관심을 끌 수 있습니다. 이 기능은 이 제안 티켓에 따라 우선 순위가 지정되었습니다. 의견에 대한 자세한 내용은 여기에서 설명서를 참조하세요.

Screenshot showing how to add comments on wiki pages.

""로 시작하는 폴더 및 파일을 숨깁니다. 위키 트리에서

지금까지 위키 트리는 위키 트리에 점(.)으로 시작하는 모든 폴더와 파일을 보여 줍니다. 코드 위키 시나리오에서 이로 인해 숨겨야 하는 .vscode와 같은 폴더가 위키 트리에 표시됩니다. 이제 점으로 시작하는 모든 파일과 폴더가 위키 트리에 숨겨지므로 불필요한 혼란이 줄어듭니다.

이 기능은 이 제안 티켓에 따라 우선 순위가 지정되었습니다.

짧고 읽기 가능한 Wiki 페이지 URL

더 이상 여러 줄 URL을 사용하여 위키 페이지 링크를 공유할 필요가 없습니다. URL의 페이지 ID를 활용하여 매개 변수를 제거하므로 URL을 더 짧고 읽기 쉽게 만듭니다.

URL의 새 구조는 다음과 같습니다.

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

다음은 시작 Azure DevOps Wiki 페이지에 대한 새 URL의 예입니다.

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Developer Community 이 기능 제안 티켓에 따라 우선 순위가 지정되었습니다.

위키 페이지를 편집하기 위한 동기 스크롤

이제 편집 창과 미리 보기 창 간에 동기 스크롤을 사용하여 위키 페이지를 더 쉽게 편집할 수 있습니다. 한쪽을 스크롤하면 자동으로 다른 쪽을 스크롤하여 해당 섹션을 매핑합니다. 토글 단추를 사용하여 동기 스크롤을 사용하지 않도록 설정할 수 있습니다.

Screenshot of the wiki toolbar with the synchronus scroll icon called out and the Disable Synchronized scroll toggle button above it.

참고

동기 스크롤 토글의 상태는 사용자 및 계정별로 저장됩니다.

위키 페이지의 페이지 방문

이제 위키 페이지의 페이지 방문에 대한 인사이트를 얻을 수 있습니다. REST API를 사용하면 지난 30일 동안의 페이지 방문 정보에 액세스할 수 있습니다. 이 데이터를 사용하여 위키 페이지에 대한 보고서를 만들 수 있습니다. 또한 이 데이터를 데이터 원본에 저장하고 대시보드를 만들어 상위 n개 페이지와 같은 특정 인사이트를 얻을 수 있습니다.

또한 모든 페이지에서 지난 30일 동안 집계된 페이지 방문 횟수가 표시됩니다.

Screenshot showing the previous visits for a wiki page.

참고

페이지 방문은 지정된 사용자가 15분 간격으로 페이지 보기로 정의합니다.

보고

파이프라인 오류 및 기간 보고서

메트릭 및 인사이트는 파이프라인의 처리량과 안정성을 지속적으로 개선하는 데 도움이 됩니다. 파이프라인에 대한 인사이트를 제공하기 위해 두 개의 새 보고서를 추가했습니다.

  1. 파이프라인 오류 보고서에는 빌드 통과율 및 실패 추세가 표시됩니다. 또한 파이프라인의 태스크가 최대 실패 횟수에 기여하는 인사이트를 제공하는 작업 실패 추세도 보여 줍니다.

Screenshot showing the Analytics tab displaying the Pipeline pass rate badge, the Test pass rate badge, and the Pipeline duration badge.

Screenshot showing the Pipeline failure report.

  1. 파이프라인 기간 보고서에는 파이프라인을 실행하는 데 걸린 시간 추세가 표시됩니다. 또한 파이프라인에서 가장 많은 시간이 걸리는 작업을 보여 줍니다.

쿼리 결과 위젯 개선

쿼리 결과 위젯은 가장 인기 있는 위젯 중 하나이며 좋은 이유입니다. 위젯은 대시보드에 쿼리 결과를 직접 표시하며 많은 경우에 유용합니다.

이 업데이트를 통해 오랫동안 기다려온 많은 개선 사항이 포함되었습니다.

  • 이제 위젯에 표시할 열을 최대한 많이 선택할 수 있습니다. 더 이상 5열 제한이 없습니다!
  • 위젯은 1x1에서 10x10까지 의 모든 크기를 지원합니다.
  • 열 크기를 조정하면 열 너비가 저장됩니다.
  • 위젯을 전체 화면 보기로 확장할 수 있습니다. 확장하면 쿼리에서 반환된 모든 열이 표시됩니다.

잠재 고객 및 주기 시간 위젯 고급 필터링

잠재 고객 및 주기 시간은 팀이 개발 파이프라인을 통과하는 데 걸리는 시간을 확인하고 궁극적으로 고객에게 가치를 제공하는 데 사용됩니다.

지금까지 잠재 고객 및 주기 시간 위젯 은 고급 필터 기준을 지원하지 않아 다음과 같은 질문을 할 수 있습니다.

이와 같은 업데이트 질문은 보드 스윔 레인에서 필터링하여 답변할 수 있습니다.

Screenshot showing the Configuration dialog box with the Swimlane section called out.

차트에 표시되는 작업 항목을 제한하기 위해 작업 항목 필터도 포함했습니다.

Screenshot showing the Configuration dialog box with the Field criteria section called out.

스토리 포인트를 사용한 인라인 스프린트 번다운

이제 스프린트 번다운이 스토리로 번다운할 수 있습니다. 이렇게 하면 Developer Community 피드백이 해결됩니다.

스프린트 허브에서 분석 탭을 선택합니다. 그런 다음 다음과 같이 보고서를 구성합니다.

  1. 스토리 백로그 선택
  2. 스토리 포인트의 합계를 번다운하려면 선택합니다.

Screenshot showing the inline sprint burndown using story points.

당신이 요구한 모든 것을 가진 스프린트 번다운 위젯

새 스프린트 번다운 위젯은 스토리 포인트, 작업 수 또는 사용자 지정 필드의 합계를 계산하여 불타는 것을 지원합니다. 기능 또는 에픽에 대한 스프린트 번다운을 만들 수도 있습니다. 위젯은 평균 번다운, 완료율 및 범위 증가를 표시합니다. 팀을 구성하여 동일한 대시보드에 여러 팀에 대한 스프린트 번다운을 표시할 수 있습니다. 이 모든 유용한 정보를 표시하여 대시보드에서 최대 10x10까지 크기를 조정할 수 있습니다.

Sceenshot showing the new Sprint Burndown widget.

사용해 보려면 위젯 카탈로그에서 추가하거나 기존 Sprint Burndown 위젯에 대한 구성을 편집하고 지금 새 버전 사용해 보기 상자를 선택하여 추가할 수 있습니다.

참고

새 위젯은 분석을 사용합니다. Analytics에 액세스할 수 없는 경우 레거시 스프린트 번다운을 유지했습니다.

인라인 스프린트 번다운 축소판 그림

스프린트 번다운이 돌아왔습니다! 몇 스프린트 전에 스프린트 번다운 및 태스크보드 헤더에서 컨텍스트 내 스프린트 번다운을 제거했습니다. 피드백에 따라 스프린트 번다운 썸네일을 개선하고 다시 도입했습니다.

Screenshot showing the inline sprint burndown thumbnail.

썸네일을 클릭하면 분석 탭 아래에서 전체 보고서를 볼 수 있는 옵션이 있는 더 큰 버전의 차트가 즉시 표시됩니다. 전체 보고서의 변경 내용은 머리글에 표시된 차트에 반영됩니다. 이제 남은 작업량이 아니라 스토리, 스토리 포인트 또는 작업 수에 따라 번다운되도록 구성할 수 있습니다.

팀 없이 대시보드 만들기

이제 팀과 연결하지 않고 대시보드를 만들 수 있습니다. 대시보드를 만들 때 Project 대시보드 유형을 선택합니다.

Screenshot showing the Create a dashboard dialog box with the Project Dashboard option selected and called out.

Project 대시보드는 팀과 연결되지 않고 대시보드를 편집/관리할 수 있는 사용자를 결정할 수 있다는 점을 제외하고 팀 대시보드와 같습니다. 팀 대시보드와 마찬가지로 프로젝트의 모든 사용자에게 표시됩니다.

팀 컨텍스트가 필요한 모든 Azure DevOps 위젯이 업데이트되어 구성에서 팀을 선택할 수 있습니다. 이러한 위젯을 Project 대시보드에 추가하고 원하는 특정 팀을 선택할 수 있습니다.

Screenshot of he Team dropdown.

참고

사용자 지정 또는 타사 위젯의 경우 Project 대시보드는 기본 팀의 컨텍스트를 해당 위젯에 전달합니다. 팀 컨텍스트를 사용하는 사용자 지정 위젯이 있는 경우 팀을 선택할 수 있도록 구성을 업데이트해야 합니다.


사용자 의견

Microsoft는 여러분의 의견을 기다리고 있습니다! 문제를 보고하거나 아이디어를 제공하고 Developer Community 통해 추적하고 Stack Overflow에 대한 조언을 얻을 수 있습니다.


맨 위로 이동