Azure DevOps Server 2020 릴리스 정보

개발자 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 설치 및 구성을 참조하세요.


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

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

  • 이전에는 Azure DevOps Server GitHub Enterprise Server에 대한 연결만 만들 수 있었습니다. 이 패치를 사용하면 프로젝트 관리자가 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일

참고

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

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

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

일반 패치 설치

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 예외를 수정합니다. 이 개발자 Community 피드백 티켓에 보고된 문제를 해결합니다.
  • Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll 누락으로 인한 서비스 오류입니다. 이 개발자 Community 피드백 티켓에 보고된 문제를 해결합니다.
  • Azure DevOps Server 2020으로 업그레이드하는 동안 Analytics에서 잘못된 열 이름 오류를 수정합니다. 이 개발자 Community 피드백 티켓에 보고 된 문제를 해결 합니다.
  • 테스트 사례 결과에 테스트 사례 단계를 표시할 때 저장 된 XSS.
  • 요소 결과 데이터를 TCM로 마이그레이션하는 동안 업그레이드 단계가 실패 했습니다.

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

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

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

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 서버는 gvfs (Git 가상 파일 시스템)에서 사용 하는 어셈블리 중 하나를 설치 하는 데 문제가 있습니다.

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

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

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

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

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

이 개발자 Community 피드백 티켓을 해결 하기 위해 Azure DevOps Server 2020 RC1을 다시 릴리스 했습니다.

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

Azure DevOps Server 2020 RC1 릴리스 날짜: June 30, 2020

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

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

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


일반

Azure DevOps CLI 일반 가용성

2 월에는 Azure CLI에 대 한 Azure DevOps 확장이 도입 되었습니다. 확장을 사용 하면 명령줄에서 Azure DevOps와 상호 작용할 수 있습니다. 확장을 개선 하 고 더 많은 명령을 추가 하는 데 도움이 되는 피드백을 수집 했습니다. 이제 확장이 일반적으로 사용 가능 하다는 것을 발표 하 게 되어 기쁘게 생각 합니다.

CLI Azure DevOps에 대해 자세히 알아보려면 여기에서 설명서를 참조 하세요.

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

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

Boards

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

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

새 부모 작업 항목 필터를 보여 주는 스크린샷

오류 처리 환경 개선 – – 버그/태스크에 대 한 필수 필드

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

빨간색 오류 메시지를 클릭할 때 나타나는 누락 된 필드 대화 상자를 보여 주는 스크린샷

작업 항목 라이브 다시 로드

이전에는 작업 항목을 업데이트할 때 두 번째 팀 멤버가 동일한 작업 항목을 변경 하려고 했지만 두 번째 사용자는 변경 내용을 잃게 됩니다. 이제 서로 다른 필드를 편집 하는 동안 작업 항목에 대 한 변경 내용의 라이브 업데이트가 표시 됩니다.

작업 항목 라이브 다시 로드의 작동 방식을 보여 주는 짧은 비디오입니다.

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

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

작업 항목 부모 열을 열 옵션으로

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

열 옵션 옵션이 out 인 백로그의 스크린샷

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

팀이 수행 하는 대로 도구를 변경 해야 합니다. 이제 기본 프로세스 템플릿에서 다른 기본 프로세스로 프로젝트를 전환할 수 있습니다. 예를 들어 Agile에서 스크럼으로 또는 Basic에서 Agile로 프로젝트를 변경할 수 있습니다. 전체 단계별 설명서는 여기에서 확인할 수 있습니다.

변경 프로세스 옵션을 out으로 호출한 프로젝트 탭의 스크린샷

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

이제 프로세스를 사용자 지정할 때 양식 레이아웃에서 사용자 지정 필드를 숨길 수 있습니다. 이 필드는 여전히 쿼리 및 REST Api에서 사용할 수 있습니다. 이 기능은 다른 시스템과 통합할 때 추가 필드를 추적 하는 데 유용 합니다.

레이아웃에서 숨기기 옵션을 보여 주는 스크린샷

3 개의 새로운 Azure Boards 보고서를 사용 하 여 팀의 상태에 대 한 통찰력 얻기

표시 되지 않는 항목은 수정할 수 없습니다. 따라서 작업 프로세스의 상태와 상태를 거의 파악 하 고 싶을 수 있습니다. 이러한 보고서를 사용 하 여 Azure Boards에서 최소한의 노력으로 중요 한 메트릭을 쉽게 추적할 수 있습니다.

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

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

  • 이 스프린트에서 남은 작업량은 얼마인가요? 완료를 위해 계속 진행 중입니까?
  • 개발 프로세스의 어떤 단계에서 가장 오래 걸리나요? 어떤 작업을 수행할 수 있나요?
  • 이전 반복에 따라 다음 스프린트를 위해 얼마나 많은 작업을 계획해야 할까요?

참고

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

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

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

    분석 탭의 번다운 차트 스크린샷.

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

    분석 탭의 누적 Flow 다이어그램 보고서 및 속도 보고서의 스크린샷.

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

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

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

분석 탭의 누적 Flow 다이어그램 스크린샷.

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

분석 탭의 속도 차트 스크린샷.

작업 보드 열 사용자 지정

작업 보드의 열을 사용자 지정할 수 있는 옵션을 추가했다고 발표하게 되어 기쁘게 생각합니다. 이제 열을 추가, 제거, 이름 바꾸기 및 다시 지정할 수 있습니다.

Taskboard에서 열을 구성하려면 열 옵션 이동합니다.

열 옵션 옵션이 호출된 Taskboard의 스크린샷.

이 기능은 개발자 Community 제안에 따라 우선 순위가 정해져 있습니다.

백로그에서 완료된 자식 작업 항목을 표시하거나 숨기도록 토글

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

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

백로그에 자식 항목을 표시하거나 숨기는 방법을 보여 주는 짧은 비디오입니다.

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

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

작업 항목에 태그를 지정할 때 표시되는 가장 최근에 사용한 태그를 보여주는 스크린샷.

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

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

조건 섹션 및 작업 섹션을 보여주는 새 작업 항목 규칙 대화 상자의 스크린샷.

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

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

시스템 선택 목록 값을 사용자 지정하는 방법을 보여 주는 짧은 비디오입니다.

새 작업 항목 URL 매개 변수

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

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

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

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

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

작업 항목 설명 영역에서 사람, 작업 항목 및RS를 언급할 수 있음을 보여 주는 스크린샷

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

토론 댓글에 대한 반응

주요 목표 중 하나는 작업 항목이 팀을 위해 더 공동으로 작동하도록 만드는 것입니다. 최근에 Twitter에서 설문 조사를 수행하여 작업 항목에 대한 논의에서 원하는 협업 기능을 확인했습니다. 댓글에 대한 반응 가져오기가 설문 조사 결과, 추가되었습니다. Twitter 설문 조사의 결과는 다음과 같습니다.

응답자의 35%가 댓글에 대한 반응 기능을 원하는 것을 보여 주는 Azure DevOps Twitter 설문 조사 스크린샷.

댓글에 반응을 추가할 수 있으며, 댓글의 오른쪽 위 모서리에 있는 웃는 얼굴 아이콘과 기존 반응 옆에 있는 댓글의 맨 아래에 있는 두 가지 방법으로 반응을 추가할 수 있습니다. 6개 반응(원하는 경우)을 모두 추가하거나 하나 또는 두 개만 추가할 수 있습니다. 반응을 제거하려면 주석 맨 아래에 있는 반응 을 클릭하면 제거됩니다. 아래에서 반응 추가 환경과 주석에 대한 반응의 모양을 확인할 수 있습니다.

두 가지 방법으로 주석에 반응을 추가할 수 있음을 보여 주는 스크린샷.

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

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

대시보드에 복사 옵션을 보여주는 스크린샷.

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

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

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

백로그의 작업 항목 스크린샷.

작업 보드 라이브 업데이트

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

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

이제 사용자 지정 필드를 비롯한 모든 필드에서 롤업을 수행할 수 있습니다. 롤업 열을 추가할 때 빠른 목록에서 롤업 열을 선택할 수 있지만, 첫 번째 프로세스 템플릿에 속하지 않는 숫자 필드에 롤업하려는 경우 다음과 같이 직접 구성할 수 있습니다.

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

    롤업 열 추가 드롭다운 목록의 스크린샷.

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

새 사용자 지정 열을 보여주는 열 옵션 패널의 스크린샷.

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

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

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

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

사용자 또는 팀과 관련된 작업 항목을 최신 상태로 유지하는 것은 매우 중요합니다. 이를 통해 팀은 프로젝트를 공동 작업하고 계속 추적할 수 있으며 모든 올바른 당사자가 관련되어 있는지 확인할 수 있습니다. 그러나 이해 관계자의 투자 수준이 다르기 때문에 작업 항목의 상태를 따르는 기능에 반영되어야 한다고 생각합니다.

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

커서가 기어 아이콘 위로 마우스를 가져가는 작업 항목의 오른쪽 위 모서리 스크린샷

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

상태 변경 옵션 및 반복 변경 옵션과 함께 선택된 사용자 지정 라디오 단추를 보여 주는 알림 설정 대화 상자의 스크린샷

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

작업 항목 양식의 배포 컨트롤을 보여주는 스크린샷.

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

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

CSV 파일에서 작업 항목을 가져오는 방법을 보여 주는 짧은 비디오입니다.

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

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

부모 옵션이 호출된 작업 항목 카드를 보여주는 스크린샷.

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

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

부모 옵션이 호출된 열 옵션 섹션의 스크린샷.

Repos

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

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

PR(끌어오기 요청) 보기 내에서 변경 내용에 대한 코드 검사 메트릭을 볼 수 있음을 보여 주는 스크린샷

파일에 추가된 새 코드 줄을 보여주는 끌어오기 요청 diff의 스크린샷.

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

호출된 상태 정책 추가 옵션 및 옵션을 선택할 때 표시되는 상태 정책 추가 섹션의 스크린샷.

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

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

끌어오기 요청에서 주석 알림을 필터링하는 방법을 보여주는 스크린샷

필터 조건 페이지와 필드 드롭다운 목록의 내용을 보여주는 스크린샷.

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

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

새 서비스 후크 구독 마법사의 스크린샷.

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

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

파일 이름 유효성 검사 옵션이 켜기로 설정된 정책 섹션을 보여주는 스크린샷

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

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

자동 검토자의 세분성

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

검토자 자동 포함 대화 상자를 보여주는 스크린샷.

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

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

끌어오기 요청의 Markdown 파일 미리 보기 side-by-side diff

이제 새 미리 보기 단추를 사용하여 Markdown 파일의 모양에 대한 미리 보기를 볼 수 있습니다. 또한 보기 단추를 선택하여 Side-by-Side diff에서 파일의 전체 콘텐츠를 볼 수 있습니다.

보기 및 미리 보기 옵션이 호출된 프로젝트의 Markdown 파일을 보여주는 스크린샷.

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

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

빌드 만료 섹션이 있는 빌드 정책 추가 대화 상자의 스크린샷.

커밋 작성자 메일에 따라 커밋을 차단하는 정책 추가

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

작성자 전자 메일 유효성 검사 커밋 옵션이 켜기로 설정된 정책 탭의 모든 Git 리포지토리에 대한 정책을 보여주는 스크린샷

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

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

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

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

참고

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

파일 탐색기에서 보기 및 검토된 옵션으로 표시가 표시된 프로젝트를 보여주는 스크린샷.

이 기능은 개발자 Community제안에 따라 우선 순위가 정해져 있습니다.

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

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

Azure Repos 방문 페이지에 대한 새 웹 UI의 스크린샷

모바일

Azure Repos 방문 페이지에 대한 새 모바일 UI의 스크린샷

리포지점 간 분기 정책 관리

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

분기 보호 추가 대화 상자의 스크린샷.

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

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

웹 환경:

웹 플랫폼 변환 방문 페이지의 스크린샷.

모바일 환경:

모바일 플랫폼 변환 파일 페이지의 스크린샷.

모바일 플랫폼 변환 커밋 페이지의 스크린샷.

Kotlin 언어 지원

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

UI에 표시되는 Kotlin 파일의 스크린샷.

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

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

초안이 필터 조건 기능에 옵션으로 추가된 것을 보여 주는 새 구독 대화 상자의 스크린샷.

PR 실행 가능성이 향상되었습니다.

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

Pipelines

다단계 파이프라인

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

새 환경은 다음과 같은 기능을 제공합니다.

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

YAML에서 지속적인 배포

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

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

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

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

변수 대화 상자를 보여주는 스크린샷.

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

보류 중인 승인에 대한 조치를 더 쉽게 만들었습니다. 이전에는 릴리스의 세부 정보 페이지에서 릴리스를 승인할 수 있었습니다. 이제 릴리스 허브에서 직접 릴리스를 승인할 수 있습니다.

릴리스 허브에서 직접 릴리스를 승인하는 방법을 보여주는 스크린샷.

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

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

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

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

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

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

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

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

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

YAML에서 일정 Cron

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

  1. 코드로 구성: 코드의 일부로 파이프라인을 사용 하 여 일정을 추적할 수 있습니다.
  2. 표현: UI를 사용할 수 있는 것 보다 더 다양 한 일정 정의 기능을 제공 합니다. 예를 들어 1 시간 마다 실행을 시작 하는 단일 일정을 지정 하는 것이 더 쉽습니다.
  3. 업계 표준: 많은 개발자와 관리자는 이미 cron 구문에 대해 잘 알고 있습니다.
schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

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

예약 된 실행 옵션 (out)을 사용 하 여 파이프라인 실행 메뉴를 보여 주는 스크린샷

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

서비스 연결을 관리 하기 위해 업데이트 된 사용자 환경에 대해 노력 하 고 있습니다. 이러한 업데이트는 서비스 연결 환경을 최신 상태로 만들고 Azure DevOps 방향과 일치 합니다. 올해 이전에는 서비스 연결에 대 한 새 UI를 미리 보기 기능으로 도입 했습니다. 새 환경을 시도 하 고 저희에 게 소중한 의견을 제공 해 주셔서 감사 합니다.

새 서비스 연결 대화 상자의 스크린샷

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

승인 및 확인 옵션이 표시 된 YAML 파이프라인의 편집 메뉴를 보여 주는 스크린샷

새 사용자 환경은이 업데이트를 사용 하 여 기본적으로 켜 집니다. 미리 보기에서 옵트아웃 (opt out) 할 수 있는 옵션이 제공 됩니다.

참고

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

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

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

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

실행 단계를 실행 하는 단계를 보여 주는 실행 파이프라인 섹션을 보여 주는 스크린샷

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

Dev 옵션 및 배포 옵션을 선택 하 여 실행할 단계 섹션을 보여 주는 스크린샷

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

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

파이프라인 실행 대화 상자의 스크린샷

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

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

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

실행할 스테이지 대화 상자 스크린샷

azAzure Pipelines에 대 한 CLI 개선 사항

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

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

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

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

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

파이프라인을 만들 때 경우에 따라, YAML 파일을 만들고 커밋하는 등의 다양 한 이유로 인해 실행이 잘못 될 수 있습니다. 즉, 인프라가 준비 되지 않았거나 변수/변수 그룹 등을 만들고 업데이트할 필요가 없습니다. Azure DevOps CLI를 사용 하면 이제--skip-run 매개 변수를 포함 하 여 파이프라인을 만들 때 자동화 된 첫 번째 파이프라인 실행을 건너뛸 수 있습니다. 자세한 내용은 az 파이프라인 create command 설명서 를 참조 하세요.

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

서비스 끝점 CLI 명령은 azure rm 및 github 서비스 끝점 설정 및 관리만 지원 합니다. 그러나이 릴리스에서 서비스 끝점 명령을 사용 하면 파일을 통해 구성을 제공 하 여 모든 서비스 끝점을 만들 수 있으며, 이러한 형식의 서비스 끝점을 만들기 위한 첫 번째 클래스 지원을 제공 하는 최적화 된 명령 az devops service-끝점 github 및 az devops service-endpoint azurerm를 제공 합니다. 자세한 내용은 명령 설명서 를 참조 하세요.

배포 작업

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

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

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

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

CI 파이프라인에서 관련 CD 파이프라인 정보 표시

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

CI 파이프라인의 관련 CD 파이프라인 정보를 보여 주는 스크린샷

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 클러스터의 네임 스페이스에 매핑되는 환경에 적용 됩니다.

Azure Kubernetes Service 클러스터 링크를 사용 하는 Kubernetes environment 리소스 뷰의 스크린샷

알림 구독의 릴리스 폴더 필터

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

알림 구독의 릴리스 폴더 필터 스크린샷

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

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

다중 단계 YAML 파이프라인을 실행 하는 경우 현재 진행 중인 단계 실행을 취소할 수 있습니다. 이는 단계가 실패 하거나 시작 하려는 다른 실행이 있는 경우에 유용 합니다.

실패 한 단계 다시 시도

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

이제 실행이 실패할 때 파이프라인 단계를 다시 시도할 수 있습니다. 첫 번째 시도에서 실패 한 작업과 실패 한 작업에 대해 전이적으로 종속 된 모든 작업은 다시 시도 됩니다.

이를 통해 여러 가지 방법으로 시간을 절약할 수 있습니다. 예를 들어 한 단계에서 여러 작업을 실행 하는 경우 각 단계에서 다른 플랫폼에 대 한 테스트를 실행 하도록 할 수 있습니다. 한 플랫폼의 테스트가 실패 하는 경우 다른 플랫폼에서 테스트가 성공 하면 전달 된 작업을 다시 실행 하지 않고 시간을 절약할 수 있습니다. 또 다른 예로, 부실 네트워크 연결로 인해 배포 단계가 실패할 수 있습니다. 해당 단계를 다시 시도 하면 다른 빌드를 생성 하지 않고도 시간을 절약할 수 있습니다.

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

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

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

검사 옵션이 밑줄로 표시 된 리소스 추가 메뉴의 스크린샷

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

배포가 승인을 기다리는 중임을 보여 주는 스크린샷

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

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

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

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

Docker 대화 상자의 스크린샷

Azure App Service 앱 설정을 구성 하는 새 작업

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

Azure App Service 설정 대화 상자를 보여 주는 스크린샷

현재 Azure App Service 미리 보기와의 교환을 지원 합니다.

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

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

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

작업 드롭다운 목록에서 새 다단계 교환 설정을 사용 하 여 Azure App Service 관리 대화 상자를 보여 주는 스크린샷

Azure Container Registry 및 Docker 허브 아티팩트에 대 한 단계 수준 필터

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

스테이징 수준에서 정규식을 사용할 수 있음을 보여 주는 스크린샷

YAML 파이프라인의 승인 향상

서비스 연결 및 에이전트 풀에서 승인 구성을 사용 하도록 설정 했습니다. 승인은 인프라 소유자와 개발자 간의 역할 분리를 따릅니다. 환경, 서비스 연결 및 에이전트 풀과 같은 리소스에 대 한 승인을 구성 하 여 리소스를 사용 하는 모든 파이프라인 실행은 먼저 승인을 받아야 합니다.

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

수동 승인 사용 페이지와 만들기 옵션이 표시 된 정책 탭을 보여 주는 스크린샷

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

응용 프로그램에서 컨테이너를 사용 하는 것은 늘어나고이로 인해 강력한 테스트 및 유효성 검사가 필요 합니다. 이제 Azure Pipelines는 컨테이너 구조 테스트 를 지원 합니다. 이 프레임 워크는 컨테이너의 내용과 구조를 확인 하는 편리 하 고 강력한 방법을 제공 합니다.

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

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

컨테이너 구조 테스트 페이지를 보여 주는 스크린샷

테스트 데이터 및 요약

요약 및 테스트 데이터를 사용할 수 있음을 보여 주는 스크린샷

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

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

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

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

이전에는 리소스 그룹 수준에 대 한 배포만 지원 했습니다. 이 업데이트를 사용 하 여 ARM 템플릿을 구독 및 관리 그룹 수준 모두에 배포 하는 지원을 추가 했습니다. 이렇게 하면 일련의 리소스를 함께 배포 하 고 다른 리소스 그룹 또는 구독에 배치 하는 데 도움이 됩니다. 예를 들어 Azure Site Recovery에 대 한 백업 가상 컴퓨터를 별도의 리소스 그룹 및 위치에 배포 합니다.

다중 단계 YAML 파이프라인을 위한 CD 기능

이제 CI 파이프라인이 게시 한 아티팩트를 사용 하 고 파이프라인 완성 트리거를 사용 하도록 설정할 수 있습니다. Multi-factor AML 파이프라인에서 리소스를 소개 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에 대 한 환경에서 카나리아 배포 전략 오케스트레이션

응용 프로그램 업데이트를 지속적으로 제공 하는 주요 이점 중 하나는 특정 마이크로 서비스에 대 한 업데이트를 프로덕션으로 신속 하 게 푸시하는 기능입니다. 이를 통해 비즈니스 요구 사항 변화에 빠르게 대응할 수 있습니다. 환경은 배포 전략 오케스트레이션을 사용 하 고 가동 중지 시간이 0 인 릴리스를 용이 하 게 하는 최고 수준의 개념으로 도입 되었습니다. 이전에는 단계를 순차적으로 실행 하는 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 기반 응용 프로그램 소유자가 배포의 요청 자가 자신의 배포를 승인 하지 못하도록 제한 하는 것이 일반적입니다.

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

승인 만들기 대화 상자를 보여 주는 스크린샷

첫 번째 클래스 파이프라인 리소스로 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

파이프라인의 아티팩트 검사 평가에 대 한 향상 된 기능

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

템플릿 사용 옵션이 밑줄로 표시 된 아티팩트 평가 대화 상자를 보여 주는 스크린샷

허용 목록 sources 옵션과 Azure 파이프라인 빌드 이미지 옵션이 선택 된 상태에서 아티팩트 정책 구성 대화 상자를 보여 주는 스크린샷

배포 작업의 출력 변수 지원

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

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

  • 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 파이프라인에서 권한이 없는 리소스를 사용 하는 경우 리소스 권한 부여 오류로 인해 실패 했습니다. 실패 한 실행의 요약 페이지에서 리소스에 권한을 부여 해야 했습니다. 또한 권한이 없는 리소스를 참조 하는 변수를 사용 하는 경우 파이프라인이 실패 합니다.

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

개발 단계를 보여 주는 스크린샷은 해당 권한이 필요 함을 나타내는 표시기를 사용 하 여 대기 상태입니다.

아티팩트 확인 평가

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

아티팩트 정책 평가 대화 상자의 스크린샷

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

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

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

파이프라인에서 메타 데이터 게시 옵션이 설정 된 일반 대화 상자의 스크린샷

환경을 사용 하 여 VM 배포

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

가상 컴퓨터 옵션을 선택 하 고 호출 하는 새 환경 대화 상자의 스크린샷

롤링 배포는 이전 버전의 응용 프로그램 인스턴스를 각 반복의 일련의 컴퓨터 (롤링 집합)에 있는 새 버전의 응용 프로그램 인스턴스로 바꿉니다.

예를 들어 롤링 배포 아래에서 각 반복에서 최대 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 템플릿을 확장 하는지 확인 합니다.

Check 추가 대화 상자의 스크린샷

승인 알림

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

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

승인 알림의 스크린샷

Azure Portal에서 배포 전략 구성

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

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

지속적인 업데이트 대화 상자를 보여 주는 스크린샷.

런타임 매개 변수

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

  • 런타임 시 스크립트 및 태스크에 다른 값 제공
  • 매개 변수 형식, 허용되는 범위 및 기본값 제어
  • 템플릿 식을 통해 동적으로 작업 및 단계 선택

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

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

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

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


# 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라는 리포지토리와 도구라는 두 번째 리포지토리가 있는 경우 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 컬렉션을 가리키고 다른 프로젝트의 리포지토리에 액세스할 수 있는 자격 증명을 가합니다. 리포지토리와 는 모두 self otherrepo 체크 아웃됩니다.

중요

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

Azure Repos/Team Foundation Server 옵션이 강조 표시된 Project 설정 페이지의 스크린샷.

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

파이프라인에 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은 그대로 유지됩니다. kustomize에 대한 옵션이 KubernetesManifest 작업의 준비 작업 아래에 추가되어 kustomization.yaml 파일이 포함된 모든 폴더를 사용하여 KubernetesManifest 작업의 배포 작업에 사용되는 매니페스트 파일을 생성할 수 있습니다.

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 사용 클러스터에 대한 파이프라인이 실패했습니다. 이 문제를 해결하기 위해 클러스터 사용자 자격 증명 대신 클러스터 관리자 자격 증명을 사용할 수 있는 확인란을 추가했습니다.

클러스터 관리자 자격 증명 사용 확인란을 보여주는 Helm 차트 패키지 및 배포 스크린샷.

Docker Compose 작업의 인수 입력

와 같은 인수를 추가할 수 있도록 Docker Compose 작업에 새 필드가 --no-cache 도입되었습니다. 빌드와 같은 명령을 실행할 때 인수가 작업에 의해 전달됩니다.

새 인수 텍스트 상자를 보여 Docker Compose 작업의 스크린샷.

GitHub 릴리스 작업 향상

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

작업 버전 및 태그 패턴 섹션이 호출된 GitHub 릴리스 작업을 보여주는 스크린샷.

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

비교 및 변경 로그 유형 섹션이 강조 표시된 GitHub 릴리스 작업을 보여주는 스크린샷.

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

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

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

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

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

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

Powershell 및 Powershell Core가 스크립트 유형 드롭다운 목록의 옵션임을 보여 주는 Azure CLI 작업의 스크린샷.

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

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

서비스 메시 인터페이스 추상화는 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 빌드 서비스 계정 또는 Project 컬렉션 빌드 서비스 계정에 명시적으로 부여할 수 있습니다.

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

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

보안 옵션이 호출된 서비스 연결 페이지의 스크린샷.

단계 대상 지정 및 명령 격리

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 그룹을 통해서만 서비스 연결 보안을 관리해야 했습니다.

이 작업의 일부로 Reader, User, Creator 및 Administrator의 새로운 역할을 도입했습니다. 프로젝트의 서비스 연결 페이지를 통해 이러한 역할을 설정할 수 있으며 개별 연결에서 상속됩니다. 또한 각 서비스 연결에서 상속을 설정하거나 해제하고 서비스 연결 범위의 역할을 재정의할 수 있습니다.

서비스 연결에 대한 역할 기반 액세스를 보여 주는 스크린샷

여기에서서비스 연결 보안에 대해 자세히 알아보세요.

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

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

서비스 연결의 프로젝트 간 공유를 보여 주는 스크린샷

여기에서서비스 연결 공유에 대해 자세히 알아보세요.

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

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

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

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

    파이프라인이 자동으로 트리거된 것을 보여 주는 스크린샷.

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

    현재 파이프라인 섹션의 커밋을 보여주는 스크린샷.

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

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

    파이프라인의 Artifacts 페이지를 보여주는 스크린샷.

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

작업 영역 탭을 보여주는 배포별 섹션의 스크린샷.

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

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

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

로그에 반환된 403 오류를 보여주는 스크린샷.

이 문제를 해결하려면 아웃바운드 요청에 대한 방화벽을 로 업데이트하는 것이 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단계에서 명시적 종속성을 선언해야 합니다.

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

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

에이전트 업데이트 설정 옵션이 켜져 있고 호출된 기본 설정 페이지의 사진

에이전트 진단

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

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

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

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

실행 단계 옵션이 호출된 이 유형의 이벤트 드롭다운 목록에서 트리거를 보여주는 새 서비스 후크 구독 마법사의 스크린샷.

Optimizely 통합

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 릴리스가 연결되면 자동으로 다운로드되고 릴리스 작업에서 사용할 수 있게 됩니다.

GitHub 릴리스 옵션이 선택되고 호출된 아티팩트 추가 대화 상자의 스크린샷.

Azure Pipelines Terraform 통합

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

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

Azure Pipelines Terraform 통합의 스크린샷.

Google Analytics와 통합

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

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

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

Google Analytics 실험 작업을 보여주는 스크린샷.

Azure Pipelines ServiceNow 통합 업데이트

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

VSCode에서 Azure Pipelines 만들기

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

오른쪽 아래 모서리에 다음 경고가 있는 VS Code 스크린샷: 파이프라인이 성공적으로 설정되었습니다.

Flaky 버그 관리 및 해결 방법

감지, 보고 및 해결을 통해 엔드 투 엔드 수명 주기를 지원하는 유연한 테스트 관리를 도입했습니다. 더 향상하기 위해 불균일한 테스트 버그 관리 및 해결 방법을 추가하고 있습니다.

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

버그 보고서가 해결되거나 닫히면 테스트를 명확하게 표시하지 않는 것으로 자동으로 표시되지 않습니다.

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

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

최소 테스트 수가 실행되지 않는 경우 작업 실패 옵션을 보여주는 스크린샷.

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

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

테스트 결과 폴더 텍스트 상자를 보여 주는 스크린샷

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

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

자동화 된 테스트 오류 메시지의 markdown 지원을 보여 주는 스크린샷

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

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

또한 배포 작업을 정의 된 경우 서비스 측 과 함께 컨테이너 작업 으로 실행할 수 있습니다.

Test Plans

새 테스트 계획 페이지

새 Test Plans 페이지 (Test Plans *)는 모든 Azure DevOps 컬렉션에서 사용할 수 있습니다. 새 페이지는 테스트 계획, 작성 또는 실행 시 작업에 집중 하는 데 도움이 되는 효율적인 뷰를 제공 합니다. 또한 불필요 하 고 Azure DevOps 제공의 나머지 부분과 일관 되 게 사용할 수 있습니다.

백 엔드 저장소를 공유 하는 두 개의 identially 이라는 테스트 계획을 보여 주는 스크린샷

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

테스트 계획 개요 페이지

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

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

아래의 새 섹션에 대 한 광범위 한 스트로크 보기를 사용할 수 있습니다.

1. 테스트 계획 헤더

테스트 계획 헤더 페이지

작업

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

  • 테스트 계획을 즐겨찾기로 표시
  • 즐겨찾기에 추가 테스트 계획 표시 해제
  • 선호 하는 테스트 계획 중에서 쉽게 탐색
  • 테스트 계획이 최신 인지 아니면 과거 인지를 명확 하 게 나타내는 테스트 계획의 반복 경로를 확인 합니다.
  • 링크를 사용 하 여 테스트 진행률 보고서의 빠른 요약을 보고 보고서로 이동 합니다.
  • 모든/광산 Test Plans 페이지로 다시 이동 합니다.

상황에 맞는 메뉴 옵션

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

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

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

테스트 계획 복사 페이지

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

2. 테스트 도구 모음 트리

테스트 도구 모음 트리 페이지

작업

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

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

상황에 맞는 메뉴 옵션

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

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

3. [탭 정의]

탭 페이지 정의

정의 탭에서는 테스트 도구 모음에 대 한 테스트 사례를 정렬, 추가 및 관리할 수 있습니다. 반면에 실행 탭은 테스트 요소를 할당 하 고 실행 하는 데 사용할 수 있습니다.

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

작업

정의 탭에서 다음 작업을 수행할 수 있습니다.

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

상황에 맞는 메뉴 옵션

탭 정의 상황에 맞는 메뉴 페이지

정의 탭 내의 테스트 사례 노드에 대 한 상황에 맞는 메뉴에서는 다음 옵션을 제공 합니다.

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

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

탭 복사 테스트 사례 페이지 정의

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

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

[연결 된 항목 보기] 탭 정의 페이지

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

4. 실행 탭

탭 실행 페이지

정의 탭에서는 테스트 도구 모음에 대 한 테스트 사례를 정렬, 추가 및 관리할 수 있습니다. 반면에 실행 탭은 테스트 요소를 할당 하 고 실행 하는 데 사용할 수 있습니다.

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

새 페이지의 주요 이점 중 하나는 주로 테스트 실행/추적을 수행 하는 사용자에 대 한 것입니다 (' 기본 ' 액세스 수준만 있어야 함) .이는 도구 모음 관리의 복잡성으로 인해 부담 되지 않습니다 (정의 탭은 해당 사용자에 대해 숨김).

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

작업

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

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

상황에 맞는 메뉴 옵션

탭 실행 상황에 맞는 메뉴 페이지

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

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

Test Plans 진행률 보고서

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

진행률 보고서 옵션이 강조 표시 된 Test Plans 섹션의 스크린샷

보고서의 세 섹션에는 다음이 포함 됩니다.

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

진행률 보고서의 스크린샷

Artifacts

참고

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

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

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

패키지의 라이선스를 가리키는 빨간색 화살표가 있는 newtonsoft.json NuGet 패키지의 스크린샷

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

MIT 라이선스 텍스트가 dispalying 브라우저 창의 스크린샷

경량 인증 작업

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

경량 인증 태스크의 예 스크린샷

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

피드 페이지 로드 시간에 대 한 향상 된 기능

피드 페이지 로드 시간을 개선 하는 것을 발표 하 게 되어 기쁘게 생각 합니다. 평균적으로 피드 페이지 로드 시간이 10% 감소 했습니다. 가장 큰 피드는 99 번째 백분위 수 피드 페이지 로드 시간 (모든 피드의 가장 높은 99%의 로드 시간)을 75% 감소 하는 것으로 나타났습니다.

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

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

패키지에 대 한 PublicFeed 페이지를 보여 주는 스크린샷

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

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

Python Credential Provider 사용하여 Azure Artifacts 피드로 pip 및 twine 인증

이제 Python Credential Provider(artifacts-keyring)를 설치하고 사용하여 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

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

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

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

Repos 편집 옵션이 호출된 편집 메뉴를 보여주는 스크린샷.

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

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

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

Wiki 페이지에서 작업 항목을 만들고 포함하는 방법을 보여주는 짧은 비디오입니다.

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

Wiki 페이지의 주석

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

Wiki 페이지에 댓글을 추가하는 방법을 보여주는 스크린샷.

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

지금까지 wiki 트리는 wiki 트리에서 점(.)으로 시작하는 모든 폴더와 파일을 표시했습니다. 코드 wiki 시나리오에서는 숨겨야 하는 .vscode와 같은 폴더가 wiki 트리에 표시되었습니다. 이제 점으로 시작하는 모든 파일과 폴더가 wiki 트리에 숨겨져 있으므로 불필요한 혼란을 줄입니다.

이 기능은 이 제안 티켓 에 따라 우선 순위가정해져 있습니다.

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

더 이상 여러 선 URL을 사용하여 Wiki 페이지 링크를 공유할 필요가 없습니다. 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

이는 개발자 Community 이 기능 제안 티켓에 따라 우선 순위가 정해져 있습니다.

Wiki 페이지 편집을 위한 동기 스크롤

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

동기 스크롤 아이콘이 호출되고 그 위에 동기화된 스크롤 토글 사용 안 함 단추가 있는 wiki 도구 모음의 스크린샷.

참고

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

Wiki 페이지에 대한 페이지 방문

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

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

Wiki 페이지에 대한 이전 방문 을 보여주는 스크린샷.

참고

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

보고

파이프라인 실패 및 기간 보고서

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

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

파이프라인 통과율 배지, 테스트 통과 비율 배지 및 파이프라인 기간 배지를 표시하는 분석 탭을 보여주는 스크린샷.

파이프라인 오류 보고서를 보여주는 스크린샷.

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

쿼리 결과 위젯 개선

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

이 업데이트에는 많은 오랫동안 대기한 개선이 포함되었습니다.

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

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

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

지금까지 잠재 고객 및 주기 시간 위젯은 고급 필터 기준을 지원하지 않아 "팀이 우선 순위가 높은 항목을 닫는 데 얼마나 걸리나요?"와 같은 질문을 하지 않았습니다.

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

스윔 레인 섹션이 호출된 구성 대화 상자를 보여주는 스크린샷.

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

필드 조건 섹션이 호출된 구성 대화 상자를 보여주는 스크린샷.

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

스프린트 번다운은 스토리별로 번다운할 수 있습니다. 개발자 Community피드백을 해결합니다.

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

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

스토리 포인트를 사용하는 인라인 스프린트 번다운을 보여주는 스크린샷.

요청한 모든 것이 있는 스프린트 번다운 위젯

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

새 스프린트 번다운 위젯을 보여 줌

사용해보려면 위젯 카탈로그에서 추가하거나 기존 스프린트 번다운 위젯에 대한 구성을 편집하고 지금 새 버전 사용해 보세요 확인란을 선택하면 됩니다.

참고

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

인라인 스프린트 번다운 썸네일

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

인라인 스프린트 번다운 썸네일을 보여주는 스크린샷.

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

팀 없이 대시보드 만들기

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

Project 대시보드 옵션이 선택되고 호출된 대시보드 만들기 대화 상자를 보여주는 스크린샷.

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

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

팀 드롭다운 스크린샷.

참고

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


사용자 의견

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


맨 위로 이동