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 온-프레미스 설치 및 구성을 참조하세요.

---

Azure DevOps Server 2019에서 Azure DevOps Server 2020으로 안전하게 업그레이드

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

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

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

Azure DevOps Server 2020 업데이트 0.2 패치 6 릴리스 날짜: 2023년 11월 14일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020 업데이트 0.2에 대한 패치를 릴리스했습니다.

• 셸 작업 사용 인수 매개 변수 유효성 검사에 대해 PowerShell 작업 허용 문자 목록을 확장했습니다.

참고

이 패치에 대한 수정 사항을 구현하려면 여러 단계에 따라 작업을 수동으로 업데이트해야 합니다.

패치 설치

중요

2023년 9월 12일에 패치 4가 릴리스된 Azure Pipelines 에이전트에 대한 업데이트를 릴리스했습니다. 패치 4 릴리스 정보에 설명된 대로 에이전트 업데이트를 설치하지 않은 경우 패치 6을 설치하기 전에 이러한 업데이트를 설치하는 것이 좋습니다. 패치 4를 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

TFX 구성

1. 프로젝트 컬렉션에 작업 업로드 설명서의 단계에 따라 tfx-cli를 설치하고 로그인합니다.

TFX를 사용하여 작업 업데이트

파일	SHA-256 해시
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Tasks20231103.zip다운로드하고 추출합니다.
2. 디렉터리를 추출된 파일로 변경합니다.
3. 다음 명령을 실행하여 작업을 업로드합니다.

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

파이프라인 요구 사항

새 동작을 사용하려면 영향을 받는 작업을 사용하는 파이프라인에서 변수 AZP_75787_ENABLE_NEW_LOGIC = true 를 설정해야 합니다.

• 클래식에서:

  파이프라인의 변수 탭에서 변수를 정의합니다.

• YAML 예제:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 업데이트 0.2 패치 5 릴리스 날짜: 2023년 10월 10일

중요

2023년 9월 12일에 패치 4가 릴리스된 Azure Pipelines 에이전트에 대한 업데이트를 릴리스했습니다. 패치 4 릴리스 정보에 설명된 대로 에이전트 업데이트를 설치하지 않은 경우 패치 5를 설치하기 전에 이러한 업데이트를 설치하는 것이 좋습니다. 패치 4를 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020 업데이트 0.2에 대한 패치를 릴리스했습니다.

• 패치 업그레이드 컴퓨터에서 "분석 소유자" ID가 비활성 ID로 표시되는 버그가 수정되었습니다.

Azure DevOps Server 2020 업데이트 0.2 패치 4 릴리스 날짜: 2023년 9월 12일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020 업데이트 0.2에 대한 패치를 릴리스했습니다.

• CVE-2023-33136: 원격 코드 실행 취약성을 Azure DevOps Server.
• CVE-2023-38155: Azure DevOps Server 및 Team Foundation Server 권한 상승 취약성.

중요

테스트 환경에 패치를 배포하고 프로덕션에 수정 사항을 적용하기 전에 환경의 파이프라인이 예상대로 작동하는지 확인하세요.

참고

이 패치에 대한 수정 사항을 구현하려면 여러 단계에 따라 에이전트 및 작업을 수동으로 업데이트해야 합니다.

패치 설치

1. Azure DevOps Server 2020 업데이트 0.2 패치 4를 다운로드하여 설치합니다.

Azure Pipelines 에이전트 업데이트

1. 에서 에이전트 다운로드: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. 자체 호스팅 Windows 에이전트 설명서에 설명된 단계를 사용하여 에이전트를 배포합니다.  

참고

에이전트가 다운그레이드되지 않도록 하려면 AZP_AGENT_DOWNGRADE_DISABLED "true"로 설정해야 합니다. Windows에서는 관리 명령 프롬프트에서 다음 명령을 사용하고 다시 부팅할 수 있습니다. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX 구성

1. 프로젝트 컬렉션에 작업 업로드 설명서의 단계에 따라 tfx-cli를 설치하고 로그인합니다.

TFX를 사용하여 작업 업데이트

1. Tasks_20230825.zip다운로드하고 추출합니다.
2. 디렉터리를 추출된 파일로 변경합니다.
3. 다음 명령을 실행하여 작업을 업로드합니다.

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

파이프라인 요구 사항

새 동작을 사용하려면 영향을 받는 작업을 사용하는 파이프라인에서 변수 AZP_75787_ENABLE_NEW_LOGIC = true 를 설정해야 합니다.

• 클래식에서:

  파이프라인의 변수 탭에서 변수를 정의합니다.

• YAML 예제:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 업데이트 0.2 패치 3 릴리스 날짜: 2023년 8월 8일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020 업데이트 0.2에 대한 패치를 릴리스했습니다.

• 2018년 이전 버전에서 업그레이드할 때 패키지 푸시를 방해하는 버그가 수정되었습니다.

Azure DevOps Server 2020 업데이트 0.2 패치 2 릴리스 날짜: 2023년 6월 13일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020 업데이트 0.2에 대한 패치를 릴리스했습니다.

• 2018년 이전 버전에서 업그레이드할 때 패키지 푸시를 방해하는 버그가 수정되었습니다.

Azure DevOps Server 2020 업데이트 0.2 패치 1 릴리스 날짜: 2022년 10월 18일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020 업데이트 0.2에 대한 패치를 릴리스했습니다.

• 새로 추가된 AD ID가 보안 대화 상자 ID 선택기에서 표시되지 않는 문제를 해결합니다.
• 웹 후크 설정에서 그룹 구성원이 요청한 필터 문제를 해결합니다.
• 파이프라인에 대한 조직 설정에서 작업 권한 부여 scope 비-릴리스 파이프라인에 대한 현재 프로젝트로 작업 권한 부여 scope 제한으로 구성된 경우 제어된 검사 빌드 오류를 수정합니다.

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에 대한 패치를 릴리스했습니다.

• 작업 항목에서 컨트롤을 사용할 때 Email 알림이 @mention 전송되지 않았습니다.
• 계정을 전환할 때 TF400813 오류를 수정합니다. 이 오류는 TFS 2018에서 Azure DevOps Server 2020.0.1로 업그레이드할 때 발생했습니다.
• 프로젝트 개요 요약 페이지가 로드에 실패하는 문제를 해결합니다.
• 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 Server에 대한 연결만 만들 수 있었습니다. 이 패치를 사용하면 프로젝트 관리자가 GitHub.com Azure DevOps Server 리포지토리 간에 연결을 만들 수 있습니다. 이 설정은 GitHub 연결 페이지의 프로젝트 설정에서 찾을 수 있습니다.
• 테스트 계획 위젯 문제를 해결합니다. 테스트 실행 보고서에 잘못된 사용자가 결과에 표시되었습니다.
• 프로젝트 개요 요약 페이지가 로드에 실패하는 문제를 해결합니다.
• 제품 업그레이드를 확인하기 위해 전자 메일이 전송되지 않는 문제를 해결합니다.

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

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

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

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에 대한 패치를 릴리스했습니다.

• CVE-2021-27067 : 정보 공개
• CVE-2021-28459: 권한 상승

이 패치에 대한 수정 사항을 구현하려면 일반 패치 설치, 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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. 다음 명령을 실행하여 서버에 작업을 업로드합니다. 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

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

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

~$ tfx login
Copyright Microsoft Corporation

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

6. 다음 명령을 실행하여 서버에 작업을 업로드합니다. 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에 대한 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

• 이 Developer Community 피드백 티켓에 보고된 문제 해결| 새 테스트 사례 단추가 작동하지 않음
• Azure DevOps Server 2020 패치 2에서 릴리스된 수정 사항을 포함합니다.

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

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

• 이 Developer Community 피드백 티켓에 보고된 문제 해결| 새 테스트 사례 단추가 작동하지 않음

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>\Application Tier\TFSJobAgent 및 <Install Dir>\Tools 폴더에서 <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 2020 RC2 릴리스 날짜: 2020년 8월 11일

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

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

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

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

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

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

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

• 다단계 파이프라인
• YAML에서 지속적인 배포
• Boards 백로그에서 롤업을 사용하여 부모 항목의 진행률 추적
• 작업 보드에 "부모 작업 항목" 필터 추가 및 스프린트 백로그
• Azure Repos 방문 페이지에 대한 새 웹 UI
• 교차 리포지토리 분기 정책 관리
• 새 테스트 계획 페이지
• 코드 위키 페이지에 대한 풍부한 편집
• 파이프라인 오류 및 기간 보고서

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

• 일반
• Boards
• Repos
• 파이프라인
• Test Plans
• 아티팩트
• Wiki
• 보고

---

일반

Azure DevOps CLI 일반 공급

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

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

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

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

Boards

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

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

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

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

작업 항목 라이브 다시 로드

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

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

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

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

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

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

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

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

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

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

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

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

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

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

참고

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

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

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

  

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

  

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

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

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

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

작업표 열 사용자 지정

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

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

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

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

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

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

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

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

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

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

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

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

새 작업 항목 URL 매개 변수

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

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

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

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

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

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

토론 댓글에 대한 반응

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

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

Azure Boards 보고서를 dashboard 고정

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

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

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

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

태스크보드 라이브 업데이트

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

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

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

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

   

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

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

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

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

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

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

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

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

배포에 작업 항목 연결

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

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

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

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

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

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

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

Repos

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

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

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

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

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

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

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

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

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

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

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

자동 검토자를 위한 세분성

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

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

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

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

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

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

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

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

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

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

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

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

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

참고

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

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

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

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

웹

모바일

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

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

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

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

웹 환경:

모바일 환경:

Kotlin 언어 지원

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

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

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

향상된 PR 실행 가능성

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

Pipelines

다단계 파이프라인

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

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

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

YAML에서 지속적인 배포

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

• 다단계 YAML 파이프라인(CI 및 CD용)
• 리소스에 대한 승인 및 확인
• 환경 및배포 전략
• 환경의 Kubernetes 및 Virtual Machine 리소스
• 공동 작업을 위한 앱 검토
• 서비스 연결에 대해 새로 고친 UX
• YAML 파이프라인의 리소스

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

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

YAML 편집기에서 파이프라인 변수를 관리하기 위한 환경을 업데이트했습니다. 더 이상 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를 사용하여 할 수 있었던 것보다 일정을 정의하는 데 더 많은 표현력이 있습니다. instance 경우 매시간 실행을 시작하는 단일 일정을 지정하는 것이 더 쉽습니다.
3. 업계 표준: 많은 개발자와 관리자는 이미 cron 구문에 익숙합니다.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

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

서비스 연결 UI에 업데이트

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

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

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

참고

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

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

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

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

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

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

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

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

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

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

az Azure Pipelines에 대한 CLI 개선 사항

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

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

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

PR을 만들 때 변경 내용이 대상 분기에서 파이프라인 실행을 중단시킬 수 있는지 확인하기 어려울 수 있습니다. 그러나 파이프라인 실행을 트리거하거나 PR 분기에 대한 빌드를 큐에 대기하는 기능을 사용하면 이제 대상 파이프라인에 대해 실행하여 변경 내용의 유효성을 검사하고 시각화할 수 있습니다. 자세한 내용은 az pipelines run 및 az 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 - 종료하기 전에 '취소된 작업이라도 항상 실행'을 제공할 시간
• condition - 조건부로 작업 실행
• 변수 - 하드 코딩된 값을 직접 추가하거나 변수 그룹, Azure Key Vault에서 백업하는 변수 그룹을 참조하거나 파일에 정의된 변수 집합을 참조할 수 있습니다.
• continueOnError - 이 배포 작업이 실패하더라도 향후 작업이 실행되어야 하는 경우 기본값은 'false'입니다.

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

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

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

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

최근에 GitHub의 NuGet 및 npm 패키지를 YAML 파이프라인의 리소스로 사용하는 지원을 추가하는 패키지라는 새로운 리소스 유형을 도입했습니다. 이 리소스의 일부로 이제 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

Kubernetes 환경 리소스 뷰의 클러스터 링크 Azure Kubernetes Service

해당 클러스터의 Azure 블레이드로 이동할 수 있도록 Kubernetes 환경의 리소스 보기에 대한 링크를 추가했습니다. 이는 Azure Kubernetes Service 클러스터의 네임스페이스에 매핑되는 환경에 적용됩니다.

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

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

다단계 YAML 파이프라인을 사용하여 작업 항목 연결

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

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

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

실패한 스테이지 다시 시도

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

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

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

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

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

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

파이프라인이 개발 단계에 배포를 실행하면 단계가 시작될 때 승인을 위해 중지됩니다.

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

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

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

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

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 작업은 다음과 같은 새로운 작업을 통해 이 다단계 교환을 지원합니다.

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

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

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

YAML 파이프라인의 승인 향상

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

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

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

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

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

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

테스트 데이터 및 요약

릴리스 파이프라인용 파이프라인 데코레이터

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

빌드 및 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 기반 애플리케이션 소유자는 배포 요청자가 자체 배포를 승인하지 못하도록 제한하는 것이 일반적입니다.

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

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

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

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

배포 작업의 출력 변수 지원

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

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

• 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 템플릿 배포 작업에서 서비스 연결을 필터링하지 않았습니다. 이로 인해 더 낮은 scope 서비스 연결을 선택하여 광범위한 scope ARM 템플릿 배포를 수행하는 경우 배포가 실패할 수 있습니다. 이제 선택한 배포 scope 따라 범위가 낮은 서비스 연결을 필터링하기 위해 서비스 연결 필터링을 추가했습니다.

환경의 ReviewApp

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

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

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

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

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

환경을 사용하여 VM 배포

환경에서 가장 많이 요청된 기능 중 하나는 VM 배포였습니다. 이 업데이트를 통해 환경에서 Virtual Machine 리소스를 사용하도록 설정합니다. 이제 여러 컴퓨터에서 배포를 오케스트레이션하고 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 템플릿을 확장하는지 확인합니다.

승인 알림

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

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

Azure Portal 배포 전략 구성

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

자세한 내용은 배포 전략 구성에 대한 설명서를 검사.

런타임 매개 변수

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

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

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

파이프라인에서 확장 키워드(keyword) 사용

현재 파이프라인을 템플릿으로 축소하여 재사용을 촉진하고 상용구 수를 줄일 수 있습니다. 파이프라인의 전체 구조는 여전히 루트 YAML 파일에 의해 정의되었습니다. 이 업데이트를 통해 파이프라인 템플릿을 사용하는 보다 구조화된 방법을 추가했습니다. 루트 YAML 파일은 이제 키워드(keyword) 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 - 배포 작업의 대상이 되는 환경의 리소스 이름입니다.

여러 리포지토리 체크 아웃

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

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

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

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

세 번째 단계에서는 원본 디렉터리에 MyCode 및 Tools 디렉터리 두 개를 표시합니다.

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

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

파이프라인이 실행될 때 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은 모두 체크 아웃됩니다.

중요

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

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

파이프라인에서 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은 그대로 유지됩니다. kubernetesManifest 작업의 배포 작업에서 사용되는 매니페스트 파일을 생성하는 데 kustomization.yaml 파일이 포함된 폴더를 사용할 수 있도록 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 지원 클러스터에 대한 대화형 로그인 프롬프트 및 실패한 파이프라인이 발생했습니다. 이 문제를 해결하기 위해 클러스터 사용자 자격 증명 대신 클러스터 관리자 자격 증명을 사용할 수 있는 확인란을 추가했습니다.

Docker Compose 작업의 인수 입력

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

GitHub 릴리스 작업 향상

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

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

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

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

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

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

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

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

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

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

서비스 메시 인터페이스 추상화는 링커드 및 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에서 사용할 수 없습니다. 이러한 개체는 다음과 같습니다.

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

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

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

액세스 토큰의 scope 제한하여 파이프라인 보안 개선

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

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

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

  참고

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

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

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

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

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

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

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

서비스 연결에 대한 프로젝트 수준 보안

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

단계 대상 지정 및 명령 격리

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의 새로운 역할을 소개했습니다. 프로젝트의 서비스 연결 페이지를 통해 이러한 역할을 설정할 수 있으며 개별 연결에서 상속됩니다. 또한 각 서비스 연결에서 상속을 켜거나 끄고 서비스 연결의 scope 역할을 재정의할 수 있습니다.

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

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

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

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

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

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

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

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

  

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

  

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

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

  

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

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

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

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

이 문제를 해결하려면 아웃바운드 요청에 대한 방화벽을 로 업데이트하는 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 파일에서 바로 앞에 있는 단계에 따라 달라집니다. 따라서 각 단계에서는 이전 단계의 출력 변수를 사용할 수 있습니다. 종속성 그래프 변경할 수 있습니다. 그러면 사용 가능한 출력 변수도 변경됩니다. instance 경우 3단계에 1단계의 변수가 필요한 경우 1단계에서 명시적 종속성을 선언해야 합니다.

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

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

에이전트 진단

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

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

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

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

최적화 통합

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

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

여기에서 Azure DevOps Optimizely 확장에 대해 자세히 알아봅니 다.

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 확장에 대한 자세한 내용은 여기 설명서를 참조 하세요.

Google Analytics와 통합

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

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

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

Azure Pipelines와 ServiceNow 통합 업데이트됨

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

VSCode에서 Azure Pipelines Create

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

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

탐지, 보고 및 해결을 통해 엔드 투 엔드 수명 주기를 지원하기 위해 벗겨진 테스트 관리를 도입했습니다. 더 향상하기 위해 벗겨진 테스트 버그 관리 및 해결 방법을 추가합니다.

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

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

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

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

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

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

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

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

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

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

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

Test Plans

새 테스트 계획 페이지

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

새 페이지를 이해하는 데 도움이 되도록 도와주세요.

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

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

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

1. 계획 헤더 테스트

작업

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

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

상황에 맞는 메뉴 옵션

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

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

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

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

2. 테스트 도구 모음 트리

작업

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

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

상황에 맞는 메뉴 옵션

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

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

3. 탭 정의

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

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

작업

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

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

상황에 맞는 메뉴 옵션

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

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

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

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

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

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

4. 실행 탭

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

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

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

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

작업

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

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

상황에 맞는 메뉴 옵션

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

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

Test Plans 진행률 보고서

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

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

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

Artifacts

참고

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

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

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

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

간단한 인증 작업

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

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

피드 페이지 로드 시간 개선

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

퍼블릭 피드와 공개적으로 패키지 공유

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

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

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

Python 자격 증명 공급자를 사용하여 Azure Artifacts 피드를 사용하여 pip 및 twine 인증

이제 Python 자격 증명 공급자(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의 피드에서 패키지를 푸시하고 끌어오도록 클라이언트 및 리포지토리를 구성하는 방법에 대한 정보가 포함되어 있습니다. 자세한 설정 정보를 추가하도록 대화 상자를 업데이트하고 지침을 제공하는 도구를 확장했습니다.

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

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

포털에서 프로젝트 범위 피드 Create

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

npm 성능 향상

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

내게 필요한 옵션 기능 향

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

• Create 피드 환경
• 전역 피드 설정 환경
• 피드 환경에 연결

Wiki

코드 위키 페이지에 대한 풍부한 편집

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

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

위키 페이지에서 작업 항목 Create 및 포함

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

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

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

위키 페이지의 주석

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

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

지금까지 위키 트리에는 위키 트리의 점(.)으로 시작하는 모든 폴더와 파일이 표시되었습니다. 코드 위키 시나리오에서는 숨겨야 하는 .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 이 기능 제안 티켓에 따라 우선 순위가 지정되었습니다.

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

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

참고

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

위키 페이지의 페이지 방문

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

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

참고

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

보고

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

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

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

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

쿼리 결과 위젯 개선

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

이 업데이트에는 대망의 많은 개선 사항이 포함되어 있습니다.

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

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

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

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

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

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

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

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

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

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

요구한 모든 항목이 포함된 스프린트 번다운 위젯

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

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

참고

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

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

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

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

팀이 없는 dashboard Create

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

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

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

참고

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

---

사용자 의견

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

---

맨 위로 이동