Azure DevOps Server 2019 릴리스 정보

  • 아티클

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

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

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

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

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

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

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

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

Azure DevOps Server 2019.0.1 패치 16 릴리스 날짜: 2023년 11월 14일

Azure DevOps Server 2019 업데이트 1.2에 대한 패치를 릴리스했습니다. 여기에는 다음과 같은 수정 사항이 포함되어 있습니다.

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

참고

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

패치 설치

중요

2023년 9월 12일에 릴리스된 패치 15를 사용하여 Azure Pipelines 에이전트에 대한 업데이트를 릴리스했습니다. 패치 15 릴리스 정보에 설명된 대로 에이전트 업데이트를 설치하지 않은 경우 패치 16을 설치하기 전에 이러한 업데이트를 설치하는 것이 좋습니다. 패치 15를 설치한 후 에이전트의 새 버전은 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 2019.0.1 패치 15 릴리스 날짜: 2023년 9월 12일

다음을 수정하는 Azure DevOps Server 2019.0.1용 패치를 릴리스했습니다.

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

중요

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

참고

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

패치 설치

  1. Azure DevOps Server 2019.0.1 패치 15를 다운로드하여 설치합니다.

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 2019.0.1 패치 14 릴리스 날짜: 2022년 8월 8일

다음을 수정하는 Azure DevOps Server 2019.0.1용 패치를 릴리스했습니다.

Azure DevOps Server 2019.0.1 패치 13 릴리스 날짜: 2022년 5월 17일

다음을 수정하는 Azure DevOps Server 2019.0.1용 패치를 릴리스했습니다.

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

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

다음을 수정하는 Azure DevOps Server 2019.0.1용 패치를 릴리스했습니다.

  • log4j 이진 파일에서 jndilookup 클래스를 제거하여 Elasticsearch 취약성을 해결했습니다.

설치 단계

  1. 패치 12를 사용하여 서버를 업그레이드합니다.
  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. 패치 12를 사용하여 서버를 업그레이드합니다.
  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 해시: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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

다음을 수정하는 Azure DevOps Server 2019.0.1용 패치를 릴리스했습니다.

  • 빌드 정의 UI 오류를 수정합니다.

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

다음을 수정하는 Azure DevOps Server 2019.0.1용 패치를 릴리스했습니다.

패치 10을 적용하려면 작업을 설치 AzureResourceGroupDeploymentV2 해야 합니다.

AzureResourceGroupDeploymentV2 작업 설치

참고

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

설치

  1. 컴퓨터의 새 폴더에 AzureResourceGroupDeploymentV2.zip 패키지를 추출합니다. 예: 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>*

Azure DevOps Server 2019.0.1 패치 9 릴리스 날짜: 2020년 12월 8일

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

  • CVE-2020-1325: Azure DevOps Server 스푸핑 취약성
  • CVE-2020-17135: Azure DevOps Server 스푸핑 취약성
  • CVE-2020-17145 : Azure DevOps Server 및 Team Foundation Server 스푸핑 취약성
  • 모든 결과를 처리하지 않는 TFVC 문제 해결

중요

이 패치를 설치하기 전에 아래에 제공된 전체 지침을 읽어보세요.

일반 패치 설치

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

설치 확인

  • 옵션 1: 를 실행 devops2019.0.1patch9.exe CheckInstall합니다. devops2019.0.1patch9.exe 위의 링크에서 다운로드한 파일입니다. 명령의 출력에 패치가 설치되었거나 설치되지 않은 것으로 표시됩니다.

  • 옵션 2: 파일의 버전을 확인합니다 [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019는 기본적으로 에 설치됩니다c:\Program Files\Azure DevOps Server 2019. Azure DevOps Server 2019.0.1 패치 9를 설치한 후 버전은 17.143.30723.4가 됩니다.

AzurePowerShellV4 작업 설치

참고

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

사전 요구 사항

  1. 프라이빗 에이전트 컴퓨터에 Azure PowerShell Az 모듈 Azure Powershell을 설치합니다.

  2. AzurePowerShellV4 작업을 사용하여 파이프라인을 만듭니다. 작업에 는 표준 오류에 실패가 하나만 표시됩니다.

설치

  1. AzurePowerShellV4.zip 패키지를 AzurePowerShellV4라는 폴더로 추출합니다.

  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. 다음 명령을 실행하여 서버에 작업을 업로드합니다. 추출된 패키지의 경로는 D:\tasks (1)\AzurePowerShellv4입니다.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 패치 8 릴리스 날짜: 2020년 9월 8일

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

  • DTS 1713492 - 보안 권한에 AD 그룹을 추가하는 동안 예기치 않은 동작입니다.

Azure DevOps Server 2019.0.1 패치 7 릴리스 날짜: 2020년 7월 14일

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

  • CVE-2020-1326: 사이트 간 스크립팅 취약성
  • 빌드 파이프라인은 다른 Git 원본을 선택할 때 권한이 없는 사용자에 대한 잘못된 연결을 표시합니다.
  • XAML 빌드 정의에서 상속을 켜기 또는 끄기로 변경할 때 발생하는 오류를 수정합니다.

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

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

  • CVE-2020-1327: Azure DevOps Server 사용자 입력을 삭제하는지 확인합니다.
  • Azure DevOps의 SSH에서 SHA2에 대한 지원 추가

Azure DevOps Server 2019.0.1 패치 5 릴리스 날짜: 2020년 3월 10일

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

Azure DevOps Server 2019.0.1 패치 3 릴리스 날짜: 2019년 9월 10일

Azure DevOps Server 2019.0.1에서 다음 버그를 해결하는 보안 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

Azure DevOps Server 2019.0.1 패치 2 릴리스 날짜: 2019년 8월 13일

Azure DevOps Server 2019.0.1에서 다음 버그를 해결하는 보안 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

  • 기본적으로 모든 파이프라인에 대해 권한이 부여되었음을 명확히 하기 위해 서비스 연결에 정보를 추가했습니다.

Azure DevOps Server 2019.0.1 패치 1 릴리스 날짜: 2019년 7월 9일

Azure DevOps Server 2019.0.1에서 다음 버그를 해결하는 보안 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

  • CVE-2019-1072 : 작업 항목 추적의 원격 코드 실행 취약성
  • CVE-2019-1076 : 끌어오기 요청의 XSS(사이트 간 스크립팅) 취약성

Azure DevOps Server 2019.0.1 릴리스 날짜: 2019년 5월 21일

Azure DevOps Server 2019.0.1은 버그 수정 롤업입니다. 여기에는 이전에 릴리스된 Azure DevOps Server 2019 패치의 모든 수정 사항이 포함됩니다. Azure DevOps Server 2019.0.1을 직접 설치하거나 Azure DevOps Server 2019 또는 Team Foundation Server 2012 이상에서 업그레이드할 수 있습니다.

참고

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

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

Azure Boards

  • 계획을 구성할 때 "이 계획의 필드 조건에 오류가 있습니다." Developer Community 통해 보고되었습니다.
  • apiwitcontroller.executequery는 쿼리에 동일한 열이 여러 번 있는 경우 예외를 throw합니다.
  • vso.work_full oauth scope 사용하는 클라이언트 개체 모델에서 WorkItemServer.DownloadFile()이 실패합니다.
  • 작업 항목 필드에서 다른 프로젝트의 다른 작업 항목 필드로 포함된 이미지를 복사하면 손상된 이미지가 만들어질 수 있습니다.

Azure Repos

  • "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

  • 테스트 분석 탭에는 미리 보기 기능이 없는 경우에도 미리 보기를 나타내는 star(*)가 있습니다.
  • 이제 릴리스 탭에서 권한을 변경할 수 있는지 여부에 관계없이 모든 사용자에게 보안을 관리하는 작업이 표시됩니다.
  • 릴리스 방문 페이지에서 초안 릴리스 시작 작업이 새 릴리스를 만들고 있었지만 이제 초안 릴리스를 시작합니다.

Azure Test Plans

  • TestRuns 및 TestResults CompletedDate의 1시간 필터가 너무 세분화되어 있습니다.
  • 테스트 사례 작업 항목 형식에서는 "테스트 사례" 형식을 지역화하면 안 됩니다.
  • 테스트 사례는 MTM 또는 브라우저에 표시되지 않습니다.
  • 테스트 계획에서 자동화된 테스트를 실행할 때 "유효성 검사 단계: 연결된 릴리스 파이프라인에서 릴리스를 트리거할 수 있는 권한이 없습니다." 오류입니다. Developer Community 통해 보고되었습니다.
  • 삭제 테스트 사례 API를 사용하여 다른 프로젝트에서 테스트 사례를 삭제할 수 있습니다. Developer Community 통해 보고되었습니다.
  • 테스트 실행기에서 작업 항목 링크를 클릭하면 기본 브라우저 대신 테스트 실행기 내에서 작업 항목 URL이 열립니다.
  • 테스트 실행기에서 로그아웃하는 사용자에 대해 테스트 사례 상태 업데이트되지 않습니다.
  • 사용자 이름 및 전자 메일 주소는 테스트 실행기의 사용자 드롭다운에 표시되지 않습니다.

Azure Artifacts

  • 위로 이동 및 아래로 이동 은 업스트림에서 지역화되지 않습니다.

분석

  • 분석 보고서는 모델이 실제로 완료되기 전에 "준비됨"으로 표시되므로 불완전한 데이터를 표시할 수 있습니다.
  • 속도, 번다운 및 번업 위젯은 서로 다른 표준 시간대의 사용자에 대해 계획된 다른 작업을 표시합니다.
  • 부실 보고서를 발생시킬 수 있는 유지 관리를 수행하는 동안 분석 데이터 수집에 보류가 있을 수 있습니다.

일반

  • 공간이 부족하면 왼쪽 탐색 항목이 IE에서 압착됩니다.

관리

  • 문제를 디버그하는 데 도움이 되도록 컬렉션 업그레이드에 추가된 추가 로깅입니다.
  • TfsConfig offlineDetach가 실패하면 오류 메시지를 수행할 수 없습니다.
  • TfsJobAgent 서비스가 충돌합니다.
  • 구성이 완료된 후에는 검색 확장이 설치되지 않습니다.
  • 구성 DB가 손상되면 관리 콘솔이 응답하지 않습니다.
  • 서비스 후크가 알림을 올바르게 처리하지 못할 수 있습니다.
  • 코드 검색 인덱싱은 검색을 구성한 후에 시작되지 않습니다.
  • 검색 페이지 결과에는 할당되지 않은 문자열이 있습니다.

이 릴리스에는 다음 업데이트가 포함됩니다.

Visual Studio 테스트 작업의 Visual Studio 2019(VS2019) 지원

파이프라인의 Visual Studio 테스트 작업에 Visual Studio 2019에 대한 지원을 추가했습니다. Visual Studio 2019용 테스트 플랫폼을 사용하여 테스트를 실행하려면 테스트 플랫폼 버전 드롭다운에서 최신 또는 Visual Studio 2019 옵션을 선택합니다.

최신 Visual Studio 2019 옵션이 선택된 테스트 플랫폼 버전 드롭다운 목록을 보여 주는 실행 옵션 섹션의 스크린샷.

Azure DevOps Server 2019 패치 2 릴리스 날짜: 2019년 5월 14일

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

  • CVE-2019-0872 : Test Plans의 XSS(사이트 간 스크립팅) 취약성
  • CVE-2019-0971 : Repos API의 정보 공개 취약성
  • CVE-2019-0979 : 사용자 허브의 XSS(사이트 간 스크립팅) 취약성

Azure DevOps Server 2019 패치 1 릴리스 날짜: 2019년 4월 9일

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

  • CVE-2019-0857: Wiki의 스푸핑 취약성
  • CVE-2019-0866 : 파이프라인의 원격 코드 실행 취약성
  • CVE-2019-0867 : 파이프라인의 XSS(사이트 간 스크립팅) 취약성
  • CVE-2019-0868 : 파이프라인의 XSS(사이트 간 스크립팅) 취약성
  • CVE-2019-0869: 파이프라인의 HTML 삽입 취약성
  • CVE-2019-0870 : 파이프라인의 XSS(사이트 간 스크립팅) 취약성
  • CVE-2019-0871 : 파이프라인의 XSS(사이트 간 스크립팅) 취약성
  • CVE-2019-0874: 파이프라인의 XSS(사이트 간 스크립팅) 취약성
  • CVE-2019-0875: Boards의 권한 상승 취약성

Azure DevOps Server 2019 릴리스 날짜: 2019년 3월 5일

참고

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

RC2 릴리스 날짜: 2019년 1월 22일

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

RC2에 다음 기능을 추가했습니다.

RC1 릴리스 날짜: 2018년 11월 19일

Azure DevOps Server 2019 RC1의 새로운 기능 요약

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

개별 섹션으로 이동하여 새 기능을 확인할 수도 있습니다.

일반

Azure DevOps Server 발표

9월 10일에 Visual Studio Team Services 및 Team Foundation Server의 진화로 Azure DevOps를 발표했습니다. Azure DevOps Server 2019는 이 새로운 브랜드의 첫 번째 온-프레미스 릴리스입니다. 자세한 내용은 블로그 게시물에서 확인할 수 있습니다.

새 탐색 환경

사용자 환경을 현대화하기 위한 새로운 탐색을 도입하고 있습니다. 이 새로운 탐색은 Azure DevOps 서비스에 출시되었으며 이제 2019년 Azure DevOps Server 사용할 수 있습니다. 자세한 내용은 블로그를 참조 하세요 .

새 탐색

아티팩트 및 Release Management 배포 파이프라인 라이선스 변경

사용자 피드백에 따라 2019년 Azure DevOps Server 사용하여 라이선스를 두 가지 주요 변경합니다. 먼저 고객은 아티팩트 확장을 더 이상 구매할 필요가 없습니다. 이제 아티팩트 라이선스 사용이 기본 라이선스에 포함됩니다. 기본 라이선스가 할당된 모든 사용자는 이제 아티팩트 를 사용할 수 있습니다. 둘째, 고객은 더 이상 Release Management 배포 파이프라인을 구매할 필요가 없습니다. 빌드 파이프라인과 마찬가지로 Release Management 배포 파이프라인은 이제 Azure DevOps Server 2019에 포함됩니다.

Azure SQL Database 지원

Azure에서 Azure DevOps 2019를 실행하는 환경을 간소화하기 위해 Azure SQL Database(범용 S3 이상)에 대한 지원을 사용하도록 설정했습니다. 이렇게 하면 광범위한 백업 기능 및 크기 조정 옵션을 활용하여 요구 사항에 맞게 조정하는 동시에 서비스 실행의 관리 오버헤드를 줄일 수 있습니다. 대기 시간을 낮게 유지하려면 호스트 VM이 데이터베이스와 동일한 Azure 지역에 있어야 합니다. 자세한 내용은 문서 를 참조하세요.

작업 항목 & 이후 버전에서 클라이언트 개체 모델 SOAP API 테스트

Azure DevOps Server 2019는 SOAP API 및 클라이언트 개체 모델을 추적하는 작업 항목을 계속 지원합니다. 그러나 이후 버전의 Azure DevOps Server 사용되지 않는 것으로 표시됩니다. 자세한 내용은 설명서에서 확인할 수 있습니다.

새 컬렉션에서 상속 처리

이제 프로세스 상속을 새 컬렉션에서 사용할 수 있습니다. 사용자는 새 컬렉션을 만들 때 프로세스 모델에 대해 양심적인 결정을 내려야 합니다. 상속 모델이 무엇이며 XML과 어떻게 다른지에 대한 설명서를 참조하세요.

프로세스 상속

검색의 중요성을 이해하고 제품 헤더의 확장된 검색 상자를 다시 가져옵니다. 또한 이제 Azure DevOps의 모든 서비스 페이지에서 "/"를 클릭하여 검색 상자를 호출할 수 있습니다.

기본 검색 상자는 다음과 같습니다.

기본 검색 상자

"/"를 입력하면 확장된 검색 상자가 표시됩니다.

확장된 검색 상자

내 작업 플라이아웃

소개하게 되어 매우 기쁩니다. 제품의 한 부분에 있고 다른 부분에서 일부 정보를 원할 때 컨텍스트를 잃고 싶지 않는다는 피드백을 들었습니다. 이 새로운 기능을 사용하면 제품 내 어디에서나 이 플라이아웃에 액세스할 수 있으며 작업 항목, 끌어오기 요청 및 모든 즐겨찾기를 비롯한 중요한 정보를 한눈에 볼 수 있습니다. 이 새 플라이아웃을 사용하면 Repos에 있는 경우 코드에서 아래로 향하지만 다음에 작업해야 하는 작업 항목을 빠르게 검사 하려는 경우 플라이아웃을 클릭하고 할당된 작업 항목을 보고 다음 항목을 선택할 수 있습니다.

아래에서 나에게 할당된 작업 항목을 보여 주는 내 작업 플라이아웃을 볼 수 있습니다.

내 작업 플라이아웃

여기서는 나에게 할당된 PR을 보여주는 두 번째 피벗을 볼 수 있습니다. 플라이아웃에서는 클릭 한 번으로 더 많은 끌어오기 요청을 볼 수 있습니다.

내 작업 플라이아웃 PR

여기에서 즐겨찾기한 모든 항목인 마지막 피벗을 볼 수 있습니다. 여기에는 즐겨 찾는 팀, 대시보드, 보드, 백로그, 쿼리 및 리포지토리가 포함됩니다.

내 작업 플라이아웃 즐겨찾기

Boards

코드에 GitHub Enterprise를 사용하고 풍부한 프로젝트 관리 기능을 원하는 팀은 이제 리포지토리를 Azure Boards 통합할 수 있습니다. GitHub와 Azure Boards 연결하면 백로그, 보드, 스프린트 계획 도구, 여러 작업 항목 유형과 같은 모든 기능을 얻을 수 있으며 GitHub의 개발자 워크플로와 통합되는 워크플로를 계속 사용할 수 있습니다.

커밋 및 끌어오기 요청을 작업 항목에 쉽게 연결할 수 있습니다. 다음 구문을 사용하여 작업 항목을 언급합니다.

AB#{work item ID}

커밋 메시지, 끌어오기 요청 제목 또는 끌어오기 요청 설명에서 작업 항목을 언급하면 Azure Boards 해당 아티팩트 링크를 만듭니다. 예를 들어 다음과 같은 커밋 메시지 고려합니다.

Adds support for deleting connections. Fixes AB#20.

그러면 작업 항목 #20에서 GitHub의 커밋에 대한 링크가 만들어지며, 이 링크는 작업 항목의 개발 섹션에 표시됩니다. ​

개발 섹션이 호출된 Azure DevOps의 스크린샷

위와 같이 "fix", "fixes" 또는 "fixed"라는 단어가 작업 항목 멘션 앞에 오면 커밋이 기본 분기 병합될 때 작업 항목이 완료된 상태로 이동됩니다.

Azure Pipelines를 사용하여 GitHub에서 코드를 빌드하는 팀은 빌드 요약에서 GitHub 커밋에 연결된 작업 항목도 볼 수 있습니다.

새 작업 항목 허브

작업 항목 허브는 작업 항목의 홈 역할을 하는 새로운 허브입니다. 여기에 범위가 지정된 작업 항목의 다양한 목록 보기가 있습니다. 나에게 할당됨을 확인하여 사용자에게 할당된 모든 작업 또는 최근에 업데이트된 모든 작업을 빠르게 확인할 수 있습니다. 그러면 가장 최근에 업데이트된 프로젝트의 모든 작업 항목이 표시됩니다. 모든 목록 옵션은 아래에서 확인할 수 있습니다.

작업 항목 허브

목록을 더 scope 경우 유형, 할당 대상, 상태, 영역, 태그 및 키워드(keyword) 필터링할 수 있습니다. 원하는 목록 보기가 있으면 열의 머리글을 클릭하기만 하면 작업 항목을 정렬할 수 있습니다. 하나의 열이 너무 좁아서 열의 전체 내용을 볼 수 없는 경우 머리글 영역의 열 크기를 쉽게 조정할 수 있습니다. 이러한 환경은 아래에서 확인할 수 있습니다.

작업 항목 허브 목록

새 보드, 백로그 및 스프린트 허브

백로그 허브는 사용자 환경을 개선하기 위해 세 개의 고유한 허브로 분할되었습니다. 강력하지만 이전 백로그 허브에는 너무 많은 기능이 있었습니다. 이로 인해 사용자가 찾고 있던 기능이나 기능을 찾기가 어려워지는 경우가 많습니다. 이 문제를 해결하기 위해 백로그 허브를 다음으로 분할했습니다.

  • 이제 백로그 허브에는 프로젝트의 백로그만 있습니다. 백로그는 팀의 우선 순위가 지정된 작업 목록입니다. 백로그는 작업 항목 계층 구조, 예측 및 새로운 스프린트 계획 환경과 같은 계획 도구를 제공합니다.
  • 새 Boards 허브에는 프로젝트의 모든 Kanban Boards가 있습니다. 보드는 상태 흐름과 통신하는 데 사용됩니다. 카드(작업 항목)는 팀에서 정의한 열을 통해 보드에서 왼쪽에서 오른쪽으로 이동합니다.
  • 새로운 스프린트 허브에는 작업 증분을 계획하고 실행하는 데 사용되는 기능이 있습니다. 각 스프린트에는 스프린트 백로그, 작업 보드 및 팀의 용량을 관리하고 설정하는 보기가 포함됩니다.

Boards 허브

새 쿼리 허브

새 쿼리 허브는 이전 허브의 많은 기존 쿼리 기능을 보다 현대적인 모양과 느낌으로 간소화하고 중요한 쿼리에 쉽게 연결할 수 있는 새로운 기능을 제공합니다. 새로운 환경의 몇 가지 주요 사항은 다음과 같습니다.

  • 정보 및 쿼리를 검색할 수 있는 기능으로 마지막으로 수정된 디렉터리 페이지
  • 폴더에 대한 고유한 URL을 사용하여 중요한 쿼리 그룹을 책갈피로 지정하는 이동 경로
  • 결과 페이지에서 즐겨 찾는 쿼리에 빠르게 액세스

DevOps 블로그에서 이러한 흥미로운 업데이트에 대해 자세히 알아보세요.

작업 항목을 다른 프로젝트로 이동하고 작업 항목 유형 변경

이제 작업 항목 유형을 변경 하거나 프로젝트 컬렉션 내의 다른 프로젝트로 작업 항목을 이동할 수 있습니다. 이러한 기능을 사용하려면 데이터 웨어하우스를 사용하지 않도록 설정해야 합니다. 데이터 웨어하우스를 사용하지 않도록 설정하면 Analytics Service를 사용하여 보고 요구 사항을 지원할 수 있습니다. 데이터 웨어하우스를 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 데이터 웨어하우스 및 큐브 사용 안 함을 참조하세요.

스프린트 계획 기능

새로운 스프린트 계획 기능은 스프린트 계획 환경을 신속하게 처리하고 개선하는 데 도움이 됩니다.

  • 다음 스프린트를 만들거나 Sprints 허브에서 직접 기존 스프린트 일정을 구독합니다.
  • 백로그의 새 계획 창을 사용하여 작업 항목을 향후 스프린트로 끌어서 놓습니다. 계획 창에는 스프린트 날짜, 작업 항목 수 및 계획된 작업이 포함됩니다.
  • 작업 보드의 맨 위에 요구 사항을 추가하거나 빠른 만들기를 사용하여 스프린트 백로그에서 선택한 위쪽, 아래쪽 또는 행에 추가합니다.
  • 담당자, 작업 항목 유형, 상태 및 태그에 대한 필터를 사용하여 필요에 맞게 보기를 조정합니다.

스프린트 계획

새 디렉터리 페이지

백로그, 보드 및 스프린트를 포함한 모든 새 허브에는 이제 다음 섹션으로 구성된 새 디렉터리 페이지가 있습니다.

  • 중단한 위치 계속 이 새 섹션에서는 마지막에 대한 빠른 링크를 직접 제공합니다(보드 | 백로그 | 스프린트) 당신은에 있었다.
  • 즐겨찾기 모든 팀에서 즐겨찾는 보드, 스프린트 및 백로그.
  • 내 소속 팀에 대한 모든 보드, 백로그 및 스프린트.
  • 모든 모든 보드, 백로그 및 스프린트의 전체 목록입니다.

디렉터리 페이지

새 보기 옵션 메뉴

백로그, 보드 및 스프린트를 비롯한 새 허브에는 새 보기 옵션 메뉴가 있습니다. 레이아웃 및 페이지 콘텐츠를 사용자 지정하는 모든 작업을 위한 새 홈입니다. 보기 옵션을 사용하여 백로그에서 계층 구조를 표시하거나 태스크보드에서 그룹화 기준 옵션을 변경하는 등의 추가 보기를 사용하도록 설정하거나, 스프린트 매핑 및 계획용 측면 패널을 켜거나, 작업 세부 정보 차트를 탐색할 수 있습니다.

옵션 보기

DevOps 블로그에서 이러한 흥미로운 업데이트, 새 팀 프로필 창 및 즐겨찾기에 대해 자세히 알아보세요.

카드 주석에는 버그 및 사용자 지정 작업 항목 유형이 포함됩니다.

카드 주석은 직관적인 검사 목록 보기 및 상호 작용으로 사랑받고 있습니다. 이전에는 카드 주석이 기본 백로그 수준 형식으로 제한되었으며 버그 또는 사용자 지정 형식을 지원하지 않았습니다. 새 릴리스에서는 작업 항목 유형에 대한 제한을 제거하고 버그 및 사용자 지정 작업 항목 유형을 카드 주석으로 표시하는 기능을 추가했습니다.

해당 백로그 수준에서 사용할 수 있는 모든 작업 항목 유형을 포함하도록 카드 주석에 대한 보드 설정이 확장되었습니다.

주석 설정

작업 항목에 대한 주석을 사용하도록 설정하면 해당 작업 항목 유형의 개수가 별도의 검사 목록으로 카드 포함됩니다.

주석 작업 항목

사용 가능한 작업 항목 유형의 빠른 생성은 카드 상황에 맞는 메뉴를 통해서도 사용할 수 있습니다.

주석 빠른 만들기

제안된 영역 및 반복을 사용하여 작업 이동

작업 항목을 이동할 때 동일한 영역 또는 반복에서 작업하고 계층 구조를 반복적으로 탐색하는 것이 일반적일 수 있습니다. 영역 및 반복 경로 컨트롤은 이제 최근에 사용한 값 목록을 제안으로 포함하므로 설정하고 이동할 수 있는 빠른 액세스 권한을 제공합니다.

영역 드롭다운 목록

또한 작업 항목을 배달해야 하는 시기를 신속하게 판단할 수 있도록 반복 날짜가 이름 오른쪽에 포함됩니다.

반복 드롭다운 목록

+/- 를 사용하여 반복 일정에서 작업 쿼리 @CurrentIteration

팀이 반복 일정에 따라 작업을 추적하는 데 도움이 되는 매크로는 @CurrentIteration 이제 정수 오프셋을 지원합니다. 닫 @CurrentIteration 혀 있지 않은 작업을 쉽게 감시하거나 + 1을 사용하여 향후 반복을 위해 계획된 작업을 미리 살펴봅니다 @CurrentIteration . 자세한 내용은 Microsoft DevOps 블로그의 @CurrentIteration 게시물을 참조하세요.

Team 매개 변수를 사용하여 @CurrentIteration 쿼리 반복 일정 명확히 지정

과거에 쿼리에서 매크로를 @CurrentIteration 사용한 경우 팀 컨텍스트가 반복 일정이 다른 Teams 간에 변경되면 결과가 달라질 수 있습니다. 이제 매크로를 사용하여 쿼리를 만들거나 수정할 때 쿼리와 @CurrentIteration 관련된 반복 일정이 있는 팀도 선택해야 합니다. Team 매개 변수를 사용하면 동일한 쿼리에서 매크로를 @CurrentIteration 사용할 수 있지만 팀 전체에서 사용할 수 있습니다. 한 가지 예는 서로 다른 반복 이름과 일정을 사용하는 두 개의 서로 다른 팀 프로젝트의 작업 항목에 대한 쿼리일 수 있습니다. 즉, 스프린트가 변경되면 더 이상 쿼리를 업데이트할 필요가 없습니다. 자세한 내용은 Microsoft DevOps 블로그의 @CurrentIteration 게시물을 참조하세요.

팀 매개 변수

새 @TeamAreas 매크로를 사용하여 팀의 영역 경로에서 쿼리 작업

팀의 설정에서 하나 이상의 영역 경로를 연결할 수 있습니다. 이를 통해 백로그, 보드, 계획, 대시보드를 해당 팀의 작업에만 집중할 수 있습니다. 하지만 팀에 대한 쿼리를 작성하려는 경우 쿼리 절에 해당 팀의 특정 영역 경로를 나열해야 했습니다. 이제 지정된 팀에 대해 소유한 영역 경로를 쉽게 참조할 수 있는 새 @TeamAreas 매크로를 사용할 수 있습니다.

쿼리 편집기에서 팀 영역 매크로

빈 서식 있는 텍스트 필드 쿼리

새 IsEmpty 쿼리 연산자를 사용하여 설명과 같이 빈 서식 있는 텍스트 필드가 있는 작업 항목을 찾습니다.

연결 및 멘션 환경에서 기존 작업 항목을 쉽게 찾을 수 있습니다.

두 개의 기존 작업 항목을 함께 연결하려는 경우 이제 새 작업 항목 검색 컨트롤을 사용하여 중요한 항목을 쉽게 찾을 수 있습니다. 쿼리 선택기는 최근에 액세스한 작업 항목을 기반으로 하는 인라인 제안과 ID 또는 제목으로 특정 작업 항목을 검색하는 진입점으로 대체되었습니다.

작업 항목 연결

이전에는 작업 항목 미리 보기 창이 꺼져 있는 경우 검색 결과 페이지에서 작업 항목을 열 수 없었습니다. 이렇게 하면 검색 결과를 파헤치기가 어려워집니다. 이제 작업 항목 제목을 클릭하여 모달 창에서 작업 항목을 열 수 있습니다.

Repos

향상된 분기 선택기

Azure Repos 대부분의 환경에서는 리포지토리를 선택한 다음 해당 리포지토리에서 분기를 선택해야 합니다. 분기 수가 많은 조직에서 이러한 환경을 개선하기 위해 새 분기 선택기를 배포하고 있습니다. 이제 선택기를 사용하여 즐겨 찾는 분기를 선택하거나 신속하게 분기를 검색할 수 있습니다.

분기 선택기

끌어오기 요청 정책을 바이패스할 때 알림 받기

PR(끌어오기 요청) 및 분기 정책을 사용하는 팀의 경우 한밤중에 프로덕션 문제에 핫픽스를 배포하는 경우와 같이 사용자가 해당 정책을 재정의하고 바이패스해야 하는 경우가 있을 수 있습니다. 개발자가 옳은 일을 하고 재정의 기능을 아끼는 것을 신뢰하는 것이 합리적입니다. 동시에 팀은 이러한 정책 재정의가 올바른 상황에서 사용되고 있는지 확인하는 방법이 필요합니다. 이를 지원하기 위해 정책을 무시할 때마다 사용자와 팀이 전자 메일 경고를 받을 수 있도록 새 알림 필터를 추가했습니다. 끌어오기 요청이 만들어지거나 업데이트된 템플릿으로 시작하고 필터 목록에서 정책 바이패스를 선택합니다. 정책을 값으로 무시하면 PR이 완료되고 정책이 무시될 때마다 알림이 표시됩니다.

정책 알림 무시

푸시 보호를 포기하지 않고 분기 정책 무시 허용

빌드 중단을 발생시킨 변경 내용 되돌리기, 한밤중에 핫픽스 적용 등 분기 정책을 무시해야 하는 여러 시나리오가 있습니다. 이전에는 팀이 끌어오기 요청을 완료할 때 분기 정책을 무시할 수 있는 권한을 부여받은 사용자를 관리하는 데 도움이 되는 권한("정책 적용에서 제외")을 제공했습니다. 그러나 해당 권한은 PR 프로세스를 완전히 우회하여 분기에 직접 푸시할 수 있는 기능도 부여했습니다.

이 환경을 개선하기 위해 이전 사용 권한을 분할하여 바이패스 권한을 부여하는 팀에 더 많은 제어를 제공합니다. 이전 권한을 대체할 수 있는 두 가지 새로운 권한이 있습니다.

  1. 끌어오기 요청을 완료할 때 정책을 무시합니다. 이 권한이 있는 사용자는 끌어오기 요청에 "재정의" 환경을 사용할 수 있습니다.
  2. 푸시할 때 정책을 무시합니다. 이 권한이 있는 사용자는 필요한 정책을 구성한 분기에 직접 푸시할 수 있습니다.

첫 번째 권한을 부여하고 두 번째 권한을 거부하면 사용자는 필요한 경우 바이패스 옵션을 사용할 수 있지만 정책을 사용하여 실수로 분기로 푸시하지 않도록 보호합니다.

참고

이 변경은 동작 변경을 도입하지 않습니다. 이전에 "정책 적용에서 제외"에 대한 허용 을 부여받은 사용자에게는 두 가지 새 권한 모두에 대해 허용 이 부여되므로 PR에 대한 완료를 재정의하고 정책을 사용하여 분기로 직접 푸시할 수 있습니다.

자세한 내용은 분기 권한 설정 설명서를 참조하세요.

커밋 메시지를 사용하여 끌어오기 요청 빠르게 설명

설명이 포함된 커밋 메시지를 작성하면 Git 리포지토리의 기록에 값이 추가됩니다. 품질 커밋 메시지를 장려하기 위해 여러 커밋이 있는 새 PR(끌어오기 요청)을 사용하려면 기여자가 수동으로 타이틀을 입력해야 합니다.

끌어오기 요청 설명은 기본적으로 계속 비어 있지만 새 기능을 사용하면 PR 커밋의 커밋 메시지를 PR 설명에 더 쉽게 통합할 수 있습니다. 커밋 메시지를 추가하려면 커밋 메시지 추가 를 클릭하여 PR 설명 텍스트의 끝에 커밋 메시지를 추가하기만 하면 됩니다.

검토자로 기본 팀 없이 끌어오기 요청 만들기

PR(끌어오기 요청) 환경을 처음 시작했을 때 PR을 만들 때 선택한 팀 컨텍스트에 모든 PR을 할당하는 것이 합리적이라고 생각했습니다. 많은 사람들이 팀 컨텍스트와 PR 할당 간의 연결을 알아채지 못했기 때문에 이 동작은 좌절의 지점이었습니다.

새 탐색 변경의 일환으로 팀과의 기본 연결을 변경할 수 있는 기회를 얻었습니다. 다음과 같은 두 가지 변경 내용이 표시됩니다.

  1. PR을 만들 때 검토자는 기본적으로 추가되지 않습니다. 검토자 목록에는 최근에 PR에 추가된 개인 및 그룹을 더 쉽게 추가할 수 있는 기능이 있습니다. 필요한 검토자 정책은 특정 검토자가 코드를 검토하기 위해 추가되도록 하려는 팀에도 도움이 될 수 있습니다.
  2. 끌어오기 요청 허브에는 사용자 지정 가능한 새 섹션이 있습니다. 기본적으로 이 섹션에는 이전 섹션과 동일한 기능을 제공하는 "내 팀에 할당된" PR이 표시됩니다. 그러나 여러 팀에 속한 경우 이 섹션에서는 모든 팀에 할당된 PR을 표시합니다. 섹션을 사용자 지정할 수도 있습니다. 섹션 헤더 근처에서 "이 보기 사용자 지정" 작업을 클릭하기만 하면 됩니다.

템플릿을 사용하여 끌어오기 요청 설명 표준화

좋은 끌어오기 요청 설명을 작성하는 것은 검토자가 코드를 검토할 때 예상되는 사항을 알 수 있도록 도와주는 좋은 방법입니다. 또한 테스트, 단위 테스트 추가 및 설명서 업데이트와 같이 모든 변경에 대해 수행해야 하는 작업을 추적하는 데 도움이 되는 좋은 방법입니다. 많은 사용자가 팀이 훌륭한 설명을 더 쉽게 작성할 수 있도록 끌어오기 요청 템플릿을 추가하도록 요청했으며, 이제 해당 기능을 추가했습니다.

팀은 기본 PR 설명 템플릿을 지원하는 것 외에도 PR 만들기 페이지의 메뉴에서 제공되는 여러 템플릿을 추가할 수 있습니다. 템플릿 추가 단추를 클릭하여 리포지토리의 템플릿 중에서 선택하여 PR 설명에 추가하기만 하면 됩니다.

PR용 템플릿 추가

PR에 대해 다른 템플릿을 특정 분기 또는 분기 폴더에 적용하려는 경우에도 분기별 템플릿이 지원됩니다. 예를 들어 "핫픽스/"로 시작하는 모든 분기와 관련된 템플릿을 사용하려는 경우 모든 PR에 사용할 템플릿을 해당 분기에 추가할 수 있습니다.

템플릿을 만들고 사용하는 방법에 대한 자세한 내용은 끌어오기 요청 템플릿 설명서를 참조하세요.

끌어오기 요청의 대상 분기 변경

대부분의 팀에서 거의 모든 끌어오기 요청은 또는 develop와 같은 main 동일한 분기를 대상으로 합니다. 그러나 다른 분기를 대상으로 지정해야 하는 경우 대상 분기를 기본 분기에서 변경하는 것을 잊기 쉽습니다. 활성 끌어오기 요청의 대상 분기를 변경하는 새로운 기능을 사용하면 이제 간단한 작업입니다. 끌어오기 요청 헤더의 대상 분기 이름 근처에 있는 연필 아이콘을 클릭하기만 하면 됩니다.

대상 분기 변경

실수를 수정하는 것 외에도 대상 분기를 변경하는 기능을 사용하면 대상 분기가 병합되거나 삭제되었을 때 끌어오기 요청의 대상을 쉽게 "다시 지정"할 수 있습니다. 변경 내용에 따라 달라지는 몇 가지 기능이 포함된 기능 분기 대상으로 하는 PR이 있는 시나리오를 고려해 보세요. 기능 분기 다른 변경 내용과 격리된 종속 변경 내용을 검토하여 처음에 를 대상으로 지정features/new-feature하려고 합니다. 그런 다음 검토자는 변경 내용만 보고 적절한 설명을 남길 수 있습니다.

이제 기능 분기 PR도 활성화되어 있고 변경 전에 에 병합된 main 경우 어떻게 될까요? 이전에는 변경 내용을 포기하고 에 새 PR main을 만들거나 PR을 에 features/new-feature병합한 다음 에서 로 features/new-feature 다른 PR을 main만들어야 했습니다. 대상 분기를 업데이트하는 이 새로운 작업을 사용하면 PR의 대상 분기를 에서 로 features/new-featuremain변경하여 모든 컨텍스트와 주석을 보존할 수 있습니다. 대상 분기를 변경하면 PR에 대한 새 업데이트가 생성되므로 대상 분기가 변경되기 전에 이전 diff를 쉽게 되돌아볼 수 있습니다.

대상 분기 업데이트

확장 작성자는 현재 리포지토리에 대한 컨텍스트를 쿼리할 수 있습니다.

버전 제어 확장 작성자의 과제 중 하나는 이름, ID 및 URL과 같이 사용자에게 표시되는 리포지토리의 컨텍스트를 가져오는 것입니다. 이를 돕기 위해 VersionControlRepositoryService를 확장 액세스 가능한 서비스로 추가했습니다. 이를 사용하여 확장 작성자가 웹 UI 내에서 현재 Git 리포지토리 컨텍스트에 대한 정보를 쿼리할 수 있습니다. 현재 getCurrentGitRepository() 메서드가 하나 있습니다.

  • Git 리포지토리를 선택하면 리포지토리(이름, ID 및 URL)에 대한 기본 데이터와 함께 GitRepository 개체가 반환됩니다.
  • TFVC 리포지토리를 선택하거나 Azure Repos 페이지 외부에서 서비스에 액세스하는 경우 null이 반환됩니다.

다음은 이 서비스를 사용하는 샘플 확장 입니다.

Pipelines

새 빌드 페이지를 사용하여 빌드 파이프라인 관리

몇 가지 개선 사항을 적용하고 새 버전의 빌드 페이지를 배포 하고 있습니다 . 이 새 버전은 프로젝트의 빌드를 빠르게 탐색하여 해당 상태 확인할 수 있도록 모든 빌드 파이프라인의 디렉터리와 현재 빌드 목록을 결합합니다. 또한 선택한 파이프라인에 대한 테스트 분석 미리 보기도 포함되어 있습니다.

새 빌드 페이지

향상된 서식을 사용하여 빌드 및 배포 완료 전자 메일을 더 잘 관리

빌드 및 배포 완료 이메일이 전자 메일 규칙에 따라 더 필터링 가능하도록 업데이트되었습니다. 이제 제목 줄에 더 관련성이 있는 정보가 한눈에 포함되고, 본문에 자세한 정보가 포함되어 있으며, 최신 브랜드로 스타일링이 새로 고쳐졌습니다.

새 형식의 요소는 다음과 같습니다.

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

다음은 몇 가지 예입니다.

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

새 통합 Azure Pipelines 용어를 따릅니다.

빌드 및 릴리스 전체에서 유사한 개념에 대해 역사적으로 서로 다른 용어가 사용되었습니다. 다른 경우에는 용어의 의미가 모호했습니다. 예를 들어 에이전트 풀과 에이전트큐 간의 차이를 나타냅니다.

용어는 개념을 명확히 하기 위해 Azure Pipelines에서 통합되었습니다. 이제 다음과 같은 통합 용어가 표시됩니다.

이전 용어 통합 용어 의미
호스트된 에이전트 Microsoft 호스팅 에이전트 Microsoft에서 관리하는 클라우드 호스팅 인프라에서 실행되는 빌드/릴리스 에이전트입니다.
프라이빗 에이전트 자체 호스팅 에이전트 사용자가 제공하고 관리하는 컴퓨터에서 실행되는 빌드/릴리스 에이전트입니다.
에이전트 풀 에이전트 풀 빌드 또는 릴리스를 실행할 수 있는 에이전트 컴퓨터의 organization 수준 집합입니다.
에이전트 큐 에이전트 풀 빌드 또는 릴리스를 실행할 수 있는 에이전트 컴퓨터의 프로젝트 수준 집합입니다. organization 수준 에이전트 풀에 연결됩니다.
빌드 정의 빌드 파이프라인 애플리케이션에 대한 엔드 투 엔드 빌드 단계 집합입니다.
빌드 빌드 실행 중이거나 실행된 빌드 파이프라인의 instance.
단계 작업 에이전트에서 순차적으로 또는 병렬로 실행되는 일련의 작업입니다. 빌드 또는 릴리스 파이프라인에는 하나의 작업 또는 여러 작업의 그래프가 포함될 수 있습니다.
릴리스 정의 릴리스 파이프라인 애플리케이션을 다양한 스테이지에 배포하기 위한 엔드 투 엔드 릴리스 단계 집합입니다.
Release Release 실행 중이거나 실행된 릴리스 파이프라인의 instance.
Environment 단계 릴리스 파이프라인에서 생성된 릴리스를 배포할 위치를 나타내는 논리적이고 독립적인 엔터티입니다.
동시 작업/파이프라인 병렬 작업 병렬 작업을 사용하면 organization 한 번에 단일 빌드 또는 릴리스 작업을 실행할 수 있습니다. 더 많은 병렬 작업을 사용할 수 있으므로 더 많은 빌드 및 릴리스 작업을 동시에 실행할 수 있습니다.
서비스 엔드포인트 서비스 연결 빌드 또는 릴리스에서 작업을 실행하기 위해 외부 서비스에 연결하는 데 사용되는 자격 증명과 같은 설정 그룹입니다.

자세한 내용은 개념 설명서를 참조하세요.

새 릴리스 페이지를 사용하여 릴리스 파이프라인 관리

완전히 새롭게 디자인된 사용자 환경은 릴리스 방문 페이지에 사용할 수 있습니다. 왼쪽에서 자주 릴리스하는 릴리스 파이프라인 목록을 참조하세요. 파이프라인을 검색하고 즐겨찾기할 수도 있습니다.

릴리스 방문 페이지

폴더 보기로 변경하여 organization 및 보안을 위한 폴더를 만듭니다. 보안은 폴더 수준에서 설정할 수 있습니다.

릴리스 폴더

릴리스 진행률 시각화

새 릴리스 진행률 보기는 배포 진행률에 대한 실시간 업데이트와 추가 세부 정보에 대한 원클릭 액세스를 제공합니다. 새 보기는 릴리스 파이프라인을 시각화하여 무슨 일이 일어나고 있는지 더 쉽게 이해하고 릴리스의 여러 단계에서 적절한 세부 정보 및 작업을 표시합니다.

릴리스 파이프라인 보기

파이프라인, 릴리스 세부 정보 및 환경

파이프라인 보기는 릴리스의 아티팩트와 배포할 환경을 보여 줍니다. 릴리스 영역에서는 릴리스 트리거, 아티팩트 버전 및 태그와 같은 릴리스 세부 정보를 제공합니다.

환경은 자세한 진행 상황과 함께 상태 이해하는 데 도움이 되는 방식으로 모델링됩니다. 언제든지 환경 내의 상태 링크를 클릭하여 로그에 연결할 수 있습니다.

환경

배포 전 및 배포 후

환경에 대해 배포 전 또는 배포 후 조건이 설정된 경우 승인 및 게이트가 있는 환경에 표시됩니다. 승인 및 게이트의 진행률도 환경의 상태 표시됩니다. 환경의 오른쪽 또는 왼쪽에 있는 환경의 조건 아이콘을 클릭하여 작업을 수행하거나 추가 세부 정보를 볼 수 있습니다.

릴리스 환경 작업

커밋 및 작업 항목

새 릴리스마다 환경을 클릭하여 각 환경에 대한 연결된 커밋 및 작업 항목 목록을 개별적으로 볼 수 있습니다. 목록이 긴 경우 필터를 사용하여 관심 있는 커밋 또는 작업 항목을 찾습니다.

커밋 및 작업 항목 해제

배포 진행률 및 로그

환경에는 완료된 단계 및 작업 수와 실행 시간을 포함하여 진행 중인 배포에 대한 라이브 업데이트가 표시됩니다. 환경 상태 클릭하면 로그가 포함된 보기가 열리고 현재 활성 상태인 항목에 중점을 둡니다.

로그를 클릭하여 포커스가 있는 보기를 입력할 수 있습니다.

릴리스 로그 세부 정보

Azure DevOps Server 2019로 업그레이드하면 작업에 미치는 영향: 대상 컴퓨터의 Windows 컴퓨터 파일 복사 및 PoweShell

테스트 허브의 컴퓨터 그룹은 TFS 2017 RTM에서 더 이상 사용되지 않습니다 . Azure DevOps Server 2019에서는 컴퓨터 그룹 서비스를 더 이상 사용할 수 없습니다. 이는 'Windows 컴퓨터 파일 복사' 작업 버전 1.* 및 '대상 컴퓨터의 PowerShell' 작업 버전 1.*의 사용자에게 영향을 줍니다. 파이프라인이 계속 작동하려면

  • 'Windows 컴퓨터 파일 복사' 작업 버전 2.*로 전환하고 컴퓨터 이름 대신 대상 컴퓨터에 대한 전체 fqdn을 제공해야 합니다.
  • 그리고 '대상 컴퓨터의 Powershell' 작업 버전 2.* 이상으로 전환하고 컴퓨터 또는 컴퓨터 이름의 전체 fqdn과 Windows 원격 관리 포트(http/https)를 제공합니다. 예를 들어 targetMachine:5985 또는 targetMachine:5986

테스트 결과 및 확장성

테스트 실행의 결과도 각 환경에 대해 표시됩니다. 테스트 결과를 클릭하면 프로세스에 기여하는 다른 확장의 결과를 포함하여 테스트 세부 정보가 포함된 보기가 열립니다.

릴리스 테스트 결과

기존 확장은 이 새로운 보기에서 작동하며 확장 개발이 환경에 대한 더 많은 정보를 표시할 수 있도록 하는 새로운 확장점이 있습니다. 자세한 내용은 기여 및 확장 설명서를 참조하세요.

YAML을 사용하여 빌드 구성

YAML 기반 빌드 파이프라인은 Azure DevOps Server 사용할 수 있습니다. 리포지토리에 체크 인된 YAML 파일을 사용하여 연속 통합 파이프라인을 자동화합니다. YAML 스키마에 대한 전체 참조는 여기에서 찾을 수 있습니다.

YAML 기반 빌드 파이프라인을 보다 원활하게 지원하기 위해 사용자가 만든 모든 새 리소스(예: 서비스 연결, 변수 그룹, 에이전트 풀 및 보안 파일)에 대한 기본 동작을 해당 프로젝트의 모든 파이프라인에서 사용할 수 있도록 변경했습니다. 리소스를 보다 엄격하게 제어하려면 기본 권한 부여 모델을 사용하지 않도록 설정할 수 있습니다(아래 그림 참조). 이렇게 하면 리소스를 사용할 수 있는 권한이 있는 사용자가 YAML 파일에 리소스 참조를 추가한 후 웹 편집기에서 파이프라인을 명시적으로 저장해야 합니다.

YAML

대형 제품에는 서로 종속된 여러 구성 요소가 있습니다. 이러한 구성 요소는 종종 독립적으로 빌드됩니다. 업스트림 구성 요소(예: 라이브러리)가 변경되면 다운스트림 종속성을 다시 빌드하고 유효성을 다시 검사해야 합니다. 팀은 일반적으로 이러한 종속성을 수동으로 관리합니다.

이제 다른 빌드를 성공적으로 완료하면 빌드를 트리거할 수 있습니다. 업스트림 빌드에서 생성된 아티팩트를 다운로드하여 이후 빌드에서 사용할 수 있으며, Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName 변수에서 데이터를 가져올 수도 있습니다. 자세한 내용은 빌드 트리거 설명서를 참조하세요.

빌드 체인 설정

경우에 따라 단일 다단계 빌드 가 요구 사항을 충족할 수 있습니다. 그러나 빌드 완료 트리거는 요구 사항에 종속 프로세스를 소유하는 다른 구성 설정, 옵션 또는 다른 팀이 포함된 경우에 유용합니다.

에이전트 로컬 업데이트

갤러리에서 설치하는 작업에는 파이프라인 에이전트의 최신 버전이 필요한 경우가 있습니다. Azure DevOps Server 인터넷에 연결할 수 있는 경우 최신 버전이 자동으로 다운로드됩니다. 그렇지 않은 경우 각 에이전트를 수동으로 업그레이드해야 합니다. 이 릴리스부터 인터넷이 아닌 로컬 디스크에서 에이전트 패키지 파일을 찾도록 Azure DevOps Server 구성할 수 있습니다. 이렇게 하면 인터넷에 Azure DevOps Server 노출하지 않고도 사용할 수 있는 에이전트 버전을 유연하게 제어할 수 있습니다.

새 빌드 상태 배지 URL

리포지토리의 홈페이지에 포함된 빌드 배지는 리포지토리의 상태를 표시하는 일반적인 방법입니다. 지금까지 빌드 배지가 있었지만 몇 가지 문제가 있었습니다.

  • URL이 직관적이지 않음
  • 배지가 분기에만 해당되지 않았습니다.
  • 사용자가 배지를 클릭하여 사용자를 해당 정의의 최신 빌드로 데려갈 방법이 없었습니다.

이제 이러한 문제를 해결하는 빌드 배지에 대한 새 API를 배포하고 있습니다. 새 API를 사용하면 사용자가 분기별 상태 게시할 수 있으며 사용자를 선택한 분기의 최신 빌드로 가져올 수 있습니다. 새 빌드 페이지에서상태 배지 메뉴 작업을 선택하여 새 상태 배지 URL에 대한 Markdown을 가져올 수 있습니다.

이전 버전과의 호환성을 위해 이전 빌드 배지 URL도 계속 적용합니다.

빌드에 사용자 지정 빌드 카운터 추가

빌드 카운터는 빌드의 번호를 고유하게 지정하고 레이블을 지정하는 방법을 제공합니다. 이전에는 $(rev:r) 특수 변수를 사용하여 이 작업을 수행할 수 있습니다. 이제 빌드를 실행할 때마다 자동 증가되는 자체 카운터 변수를 빌드 정의에 정의할 수 있습니다. 정의의 변수 탭에서 이 작업을 수행합니다. 이 새로운 기능은 다음과 같은 방법으로 더 많은 기능을 제공합니다.

  • 사용자 지정 카운터를 정의하고 해당 초기값을 설정할 수 있습니다. instance 카운터는 100에서 시작할 수 있습니다. $(rev:r)은 항상 0부터 시작합니다.
  • 사용자 고유의 사용자 지정 논리를 사용하여 카운터를 다시 설정할 수 있습니다. $(rev:r)는 빌드 번호 생성에 연결되며 빌드 번호에 새 접두사가 있을 때마다 자동으로 다시 설정됩니다.
  • 정의당 여러 카운터를 정의할 수 있습니다.
  • 빌드 외부의 카운터 값을 쿼리할 수 있습니다. instance 경우 카운터를 사용하여 마지막 재설정 이후 실행된 빌드 수를 계산할 수 있습니다.

빌드 카운터에 대한 자세한 내용은 사용자 정의 변수 에 대한 설명서를 참조하세요.

파이프라인에서 규정 준수 및 보안 유효성 검사 Azure Policy

개발 프로세스 초기에 소프트웨어의 안정성과 보안을 보장하면서 개발, 보안 및 운영을 통합하고자 합니다. 이를 위해 Azure Policy 대한 지원을 추가했습니다.

Azure Policy를 통해 리소스에 대한 규칙 및 효과를 적용하는 정책 정의를 사용하여 IT 문제를 관리하고 방지할 수 있습니다. Azure Policy 사용하는 경우 리소스는 회사 표준 및 서비스 수준 계약을 준수합니다.

릴리스 프로세스의 일부로 규정 준수 및 보안 지침을 준수하기 위해 Azure 리소스 그룹 배포 환경을 개선했습니다. 이제 ARM 템플릿을 배포하는 동안 위반이 발생하는 경우 관련 정책 관련 오류로 Azure 리소스 그룹 배포 작업이 실패합니다.

Azure Policy

또한 릴리스 정의 템플릿을 Azure Policy 추가했습니다. 이렇게 하면 사용자가 Azure 정책을 만들고 릴리스 정의 자체에서 리소스, 구독 또는 관리 그룹에 이러한 정책을 할당할 수 있습니다.

Azure Policy 템플릿

Linux/ARM 및 Windows 32비트 플랫폼에서 빌드

Azure Pipelines 오픈 소스 플랫폼 간 에이전트는 항상 64비트(x64) Windows, macOS 및 Linux에서 지원됩니다. 이 릴리스에서는 지원되는 두 가지 플랫폼인 Linux/ARM 및 Windows/32비트 플랫폼이 도입되었습니다. 이러한 새로운 플랫폼은 Linux/ARM 머신인 Raspberry Pi와 같은 덜 일반적이지만 덜 중요한 플랫폼을 기반으로 빌드할 수 있는 기능을 제공합니다.

파이프라인의 테스트 환경 개선

이제 테스트 탭에는 파이프라인에 대한 풍부한 컨텍스트 내 테스트 정보를 제공하는 최신 환경이 있습니다. 새 환경은 진행 중인 테스트 보기, 전체 페이지 디버깅 환경, 컨텍스트 테스트 기록, 중단된 테스트 실행 보고 및 실행 수준 요약을 제공합니다.

새 테스트 허브

진행 중인 테스트 실행 보기

통합 및 기능 테스트와 같은 테스트는 오랫동안 실행할 수 있으므로 지정된 시간에 테스트 실행을 확인하는 것이 중요합니다. In-Progress 테스트 뷰를 사용하면 더 이상 테스트 실행이 완료되어 테스트 결과를 알 수 있을 때까지 기다릴 필요가 없습니다. 결과가 실행되면 거의 실시간으로 사용할 수 있으므로 작업을 더 빠르게 수행할 수 있습니다. 오류를 디버그하거나 중단하거나, 버그를 제출하거나, 파이프라인을 중단할 수 있습니다. 이 기능은 현재 다중 에이전트 단계에서 VS 테스트 태스크 를 사용하거나, 테스트 결과 게시 태스크 를 사용하거나, API를 사용하여 테스트 결과를 게시하는 빌드 및 릴리스 파이프라인 모두에 사용할 수 있습니다. 나중에 단일 에이전트를 사용하여 테스트 실행을 위해 이 환경을 확장할 계획입니다.

아래 보기에서는 새 릴리스 진행률 보기의 In-Progress 테스트 요약을 보여 줍니다. 지정된 시점에 총 테스트 수 및 테스트 실패 횟수를 보고합니다.

진행 중인 테스트 뷰

위의 In-Progress 테스트 요약을 클릭하면 Test Plans 실패한 테스트 또는 중단된 테스트 정보와 함께 자세한 테스트 요약을 볼 수 있습니다. 테스트 요약은 새 결과의 가용성에 따라 요청 시 세부 정보 보기를 새로 고칠 수 있는 기능을 사용하여 주기적인 간격으로 새로 고칩니다.

자세한 테스트 요약

전체 페이지에서 테스트 실행 디버깅 세부 정보 보기

오류 메시지 및 스택 추적은 본질적으로 길며 디버깅 중에 세부 정보를 볼 수 있는 충분한 부동산이 필요합니다. 몰입형 디버깅 환경을 사용하려면 이제 테스트 또는 테스트 실행 보기를 전체 페이지 보기로 확장하면서 현재 테스트 결과에 대한 버그 만들기 또는 요구 사항 연결과 같은 컨텍스트 작업에서 필요한 작업을 수행할 수 있습니다.

전체 페이지 디버깅

컨텍스트 내 테스트 기록 보기

지금까지 팀은 실행 허브로 이동하여 테스트 결과의 기록을 확인해야 했습니다. 새로운 환경을 통해 빌드 및 릴리스를 위해 Test Plans 탭 내에서 컨텍스트에서 테스트 기록을 바로 가져옵니다. 테스트 기록 정보는 선택한 테스트에 대한 현재 빌드 정의 또는 환경부터 시작하여 빌드 및 릴리스에 대한 다른 분기 및 환경으로 점진적으로 제공됩니다.

컨텍스트 내 테스트 기록

중단된 테스트 보기

잘못된 테스트 코드, 테스트 중인 소스 및 환경 문제와 같은 여러 가지 이유로 인해 테스트 실행을 중단할 수 있습니다. 중단 이유에 관계없이 동작을 진단하고 근본 원인을 식별하는 것이 중요합니다. 이제 Test Plans 완료된 실행과 함께 중단된 테스트 및 테스트 실행을 볼 수 있습니다. 이 기능은 현재 다중 에이전트 단계에서 VS 테스트 태스크 를 사용하거나 API를 사용하여 테스트 결과를 게시하는 빌드 및 릴리스 파이프라인 모두에 사용할 수 있습니다. 나중에 단일 에이전트를 사용하여 테스트 실행을 위해 이 환경을 확장할 계획입니다.

중단된 테스트 보기

테스트 기록에서 추적 가능성 및 릴리스 환경 지원 테스트

테스트를 실행하는 다양한 릴리스 환경별로 그룹화된 자동화된 테스트의 기록을 보기 위한 지원을 추가하고 있습니다. 릴리스 환경을 릴리스 파이프라인 또는 테스트 환경으로 모델링하고 이러한 환경에서 테스트를 실행하는 경우 테스트가 개발 환경에서 통과하지만 통합 환경에서 실패하는지 확인할 수 있습니다. 영어 로캘을 전달하는지 확인할 수 있지만 터키 로캘이 있는 환경에서는 실패합니다. 각 환경에 대해 최신 테스트 결과의 상태 찾을 수 있으며, 해당 환경에서 테스트가 실패한 경우 테스트가 실패한 릴리스도 찾을 수 있습니다.

요약된 테스트 결과 검토

테스트 실행 중에 테스트는 전체 결과에 기여하는 여러 테스트 인스턴스를 생성할 수 있습니다. 몇 가지 예로는 오류로 인해 다시 실행되는 테스트, 정렬된 다른 테스트 조합으로 구성된 테스트(예: 순서가 지정된 테스트) 또는 제공된 입력 매개 변수(데이터 기반 테스트)에 따라 다른 인스턴스가 있는 테스트가 있습니다. 이러한 테스트는 관련이 있으므로 개별 테스트 결과에 따라 파생된 전체 결과와 함께 보고해야 합니다. 이 업데이트를 통해 릴리스의 테스트 탭에서 계층 구조로 제공되는 향상된 버전의 테스트 결과를 소개합니다. 예제를 살펴보겠습니다.

앞서 VS 테스트 작업에서 실패한 테스트를 다시 실행할 수 있는 기능을 도입했습니다. 그러나 이 기능의 유용성을 다소 제한한 테스트의 마지막 시도에 대해서만 보고했습니다. 이제 테스트 실행의 각 instance 시도로 보고하도록 이 기능을 확장했습니다. 또한 이제 테스트 관리 API는 계층적 테스트 결과를 게시하고 쿼리하는 기능을 지원합니다. 자세한 내용은 테스트 결과 API 설명서를 참조하세요.

테스트 요약 디버그

참고

테스트 요약 섹션의 메트릭(예: 총 테스트, 통과 등)은 테스트의 개별 반복이 아닌 계층의 루트 수준을 사용하여 계산됩니다.

파이프라인에서 테스트 분석 보기

시간이 지남에 따라 테스트 품질을 추적하고 테스트 담보를 개선하는 것이 정상 파이프라인을 유지하는 데 핵심입니다. 테스트 분석 기능은 빌드 및 릴리스 파이프라인에 대한 테스트 데이터에 대한 거의 실시간 가시성을 제공합니다. 반복적이고 영향력이 높은 품질 문제를 식별하여 파이프라인의 효율성을 개선하는 데 도움이 됩니다.

테스트 결과를 다양한 요소별로 그룹화하거나, 분기 또는 테스트 파일에 대한 주요 테스트를 식별하거나, 특정 테스트로 드릴다운하여 추세를 보고 flakiness와 같은 품질 문제를 이해할 수 있습니다.

빌드 및 릴리스에 대한 테스트 분석 보기, 아래 미리 보기:

테스트 분석

자세한 내용은 이 설명서를 참조하세요.

여러 에이전트 없는 작업을 사용하여 정의 간소화

에이전트 없는 단계의 작업은 서버에서 오케스트레이션되고 실행됩니다. 에이전트 없는 단계에는 에이전트 또는 대상 컴퓨터가 필요하지 않습니다. 에이전트 단계와 달리 정의의 각 에이전트 없는 단계에 하나의 작업만 추가할 수 있습니다. 즉, 프로세스에 에이전트 없는 작업이 두 개 이상 있을 때 여러 단계를 추가해야 하므로 정의가 부피가 큽니다. 에이전트 없는 단계에서 여러 작업을 유지할 수 있도록 이 제한을 완화했습니다. 동일한 단계의 작업은 에이전트 단계에서와 마찬가지로 순차적으로 실행됩니다. 자세한 내용은 서버 단계 설명서를 참조하세요.

릴리스 게이트를 사용하여 점진적으로 배포 및 단계별 배포

릴리스 게이트를 사용하여 릴리스가 다음 환경으로 승격되기 전에 충족해야 하는 애플리케이션 상태 조건을 지정할 수 있습니다. 지정된 모든 게이트는 모두 성공할 때까지 배포 전후에 주기적으로 평가됩니다. 4가지 유형의 게이트를 기본으로 사용할 수 있으며 Marketplace에서 더 많은 게이트를 추가할 수 있습니다. 배포에 필요한 모든 기준이 충족되었는지 감사할 수 있습니다. 자세한 내용은 릴리스 게이트 설명서를 참조하세요.

릴리스 게이트 패널

게이트가 일관되게 성공할 때까지 배포 보류

릴리스 게이트를 사용하면 릴리스가 다음 환경으로 승격되기 전에 상태 조건을 자동으로 평가할 수 있습니다. 기본적으로 모든 게이트에 대한 하나의 성공적인 샘플을 받은 후 릴리스가 진행됩니다. 게이트가 불규칙하고 성공적인 샘플이 노이즈인 경우에도 릴리스가 진행됩니다. 이러한 유형의 문제를 방지하려면 이제 진행하기 전에 최소 기간 동안 상태의 일관성을 확인하도록 릴리스를 구성할 수 있습니다. 런타임에 릴리스는 승격을 허용하기 전에 게이트에 대한 연속 평가가 성공하도록 보장합니다. 평가의 총 시간은 "재평가 사이의 시간"에 따라 달라지고 일반적으로 구성된 최소 기간보다 큽니다. 자세한 내용은 게이트를 사용한 릴리스 배포 제어 설명서를 참조하세요.

게이트 보류 설정

배포 그룹의 새 대상에 자동으로 배포

이전에는 새 대상이 배포 그룹에 추가되었을 때 모든 대상의 릴리스가 동일한지 확인하기 위해 수동 배포가 필요했습니다. 이제 마지막으로 성공한 릴리스를 새 대상에 자동으로 배포하도록 환경을 구성할 수 있습니다. 자세한 내용은 배포 그룹 설명서를 참조하세요.

배포 그룹

빌드 후 처리로 태그가 지정된 빌드를 지속적으로 배포

지속적인 배포 트리거는 빌드 완료 시 릴리스를 만듭니다. 그러나 경우에 따라 빌드가 사후 처리되고 해당 처리가 완료된 후에만 빌드를 릴리스해야 합니다. 이제 릴리스의 트리거 필터에서 사후 처리 중에 할당되는 빌드 태그를 활용할 수 있습니다.

빌드 태그 트리거

릴리스 시 변수 설정

릴리스 정의에서 이제 릴리스를 만들 때 설정할 변수를 선택할 수 있습니다.

릴리스 변수

릴리스를 만들 때 변수에 제공된 값은 해당 릴리스에만 사용됩니다. 이 기능은 초안 만들기에 대한 여러 단계를 방지하고, 초안에서 변수를 업데이트하고, 변수를 사용하여 릴리스를 트리거하는 데 도움이 됩니다.

릴리스의 릴리스 변수

작업으로 환경 변수 전달

CI/CD 태스크 작성자는 task.json에서 새 속성 showEnvironmentVariables를 설정하여 작업으로 환경 변수를 전달할 수 있습니다. 이렇게 하면 추가 컨트롤이 빌드 편집기에서 작업에 렌더링됩니다. Powershell, Cmd 및 Bash 작업에 사용할 수 있습니다.

환경 변수 전달

이렇게 하면 다음 두 가지 시나리오가 가능합니다.

  • 작업에는 변수 이름에 대/소문자가 유지되는 환경 변수가 필요합니다. instance 위의 예제에서 작업에 전달된 환경 변수는 "FOO"가 아닌 "foo"입니다.
  • 이를 통해 비밀 값을 안전한 방식으로 스크립트에 전달할 수 있습니다. 에이전트의 운영 체제가 인수를 포함한 프로세스 호출을 기록할 수 있으므로 비밀을 인수로 스크립트에 전달하는 것이 좋습니다.

변수 그룹 복제

변수 그룹 복제에 대한 지원이 추가되었습니다. 변수 그룹을 복제하고 일부 변수만 업데이트하려는 경우 변수를 하나씩 추가하는 지루한 프로세스를 거치지 않아도 됩니다. 이제 변수 그룹의 복사본을 빠르게 만들고, 값을 적절하게 업데이트하고, 새 변수 그룹으로 저장할 수 있습니다.

변수 그룹 복제

참고

비밀 변수 값은 변수 그룹을 복제할 때 복사되지 않습니다. 암호화된 변수를 업데이트한 다음 복제된 변수 그룹을 저장해야 합니다.

배포에 대한 릴리스 게이트 무시

릴리스 게이트를 사용하면 릴리스가 다음 환경으로 승격되기 전에 상태 조건을 자동으로 평가할 수 있습니다. 기본적으로 릴리스 파이프라인은 모든 게이트가 동시에 정상 상태인 경우에만 진행됩니다. 릴리스를 신속하게 처리하거나 수동으로 상태를 확인한 후와 같은 특정 상황에서 승인자는 게이트를 무시하고 해당 게이트가 아직 정상으로 평가되지 않은 경우에도 릴리스가 진행되도록 허용할 수 있습니다. 자세한 내용은 릴리스 게이트 설명서를 참조하세요.

게이트 무시

끌어오기 요청 릴리스 트리거를 사용하여 추가 테스트 수행

PR(끌어오기 요청)을 기반으로 빌드를 트리거하고 잠시 동안 병합하기 전에 빠른 피드백을 얻을 수 있었습니다. 이제 릴리스에 대한 PR 트리거도 구성할 수 있습니다. 릴리스의 상태 코드 리포지토리에 다시 게시되며 PR 페이지에서 직접 볼 수 있습니다. 이는 PR 워크플로의 일부로 추가 기능 또는 수동 테스트를 수행하려는 경우에 유용합니다.

릴리스의 PR 트리거

인증서로 인증하는 서비스 주체를 사용하여 Azure 서비스 연결 만들기

이제 인증을 위해 서비스 주체 및 인증서를 사용하여 Azure 서비스 연결을 정의할 수 있습니다. 이제 Azure 서비스 연결에서 인증서로 인증하는 서비스 주체를 지원하므로 이제 AD FS로 구성된 Azure Stack에 배포할 수 있습니다. 인증서 인증을 사용하여 서비스 주체를 만들려면 인증서로 인증하는 서비스 주체를 만드는 방법에 대한 문서를 참조하세요.

서비스 주체를 사용하여 연결

Azure App Service 배포에서 지원되는 패키지에서 실행

Azure App Service 배포 작업(4.*) 버전은 이제 RunFromPackage(이전에 RunFromZip이라고 함)를 지원합니다.

App Service msdeploy(WebDeploy), git, ARM 등과 같은 파일을 배포하는 다양한 기술을 지원합니다. 그러나 이러한 모든 기술에는 제한이 있습니다. 파일은 wwwroot 폴더(특히 d:\home\site\wwwroot) 아래에 배포되고 런타임은 해당 위치에서 파일을 실행합니다.

패키지에서 실행을 사용하면 개별 파일을 wwwroot에 복사하는 배포 단계가 더 이상 없습니다. 대신 zip 파일을 가리키면 zip이 wwwroot에 읽기 전용 파일 시스템으로 탑재됩니다. 여기에는 여러 가지 이점이 있습니다.

  • 파일 복사 잠금 문제의 위험을 줄여줍니다.
  • (다시 시작으로) 프로덕션 앱에 배포될 수 있습니다.
  • 앱에서 실행되는 파일을 확인할 수 있습니다.
  • Azure App Service 배포의 성능을 향상시킵니다.
  • 특히 대규모 npm 패키지 트리가 있는 JavaScript 함수의 경우 콜드 부팅 시간을 줄일 수 있습니다.

App Server 배포 작업을 사용하여 Linux 컨테이너 배포

4.* 버전의 Azure App Service 배포 작업은 이제 Linux에서 Azure Functions 사용자 지정 컨테이너 배포를 지원합니다.

Azure Functions Linux 호스팅 모델은 앱 특정 종속성을 패키징하고 활용하는 측면에서 더 큰 유연성을 제공하는 Docker 컨테이너를 기반으로 합니다. Linux의 함수는 다음과 같은 2가지 모드로 호스트할 수 있습니다.

  1. 기본 제공 컨테이너 이미지: 함수 앱 코드를 가져오고 Azure는 컨테이너(기본 제공 이미지 모드)를 제공하고 관리하므로 특정 Docker 관련 지식이 필요하지 않습니다. 이는 기존 버전의 App Service 배포 작업에서 지원됩니다.
  2. 사용자 지정 컨테이너 이미지: Linux에서 Azure Functions 사용자 지정 컨테이너 이미지 배포를 지원하도록 App Service 배포 작업을 개선했습니다. 함수에 특정 언어 버전이 필요하거나 기본 제공 이미지 내에 제공되지 않은 특정 종속성 또는 구성이 필요한 경우 Azure Pipelines를 사용하여 사용자 지정 이미지를 빌드하고 Linux의 Azure Function에 배포할 수 있습니다.

Xcode 작업은 새로 릴리스된 Xcode 10을 지원합니다.

Apple의 Xcode 10 릴리스와 일치하여 이제 프로젝트를 빌드하거나 Xcode 10으로 특별히 테스트하도록 설정할 수 있습니다. 파이프라인은 Xcode 버전 행렬 과 병렬로 작업을 실행할 수도 있습니다. Microsoft에서 호스팅하는 macOS 에이전트 풀을 사용하여 이러한 빌드를 실행할 수 있습니다. Azure Pipelines에서 Xcode를 사용하기 위한 지침을 참조하세요.

Xcode 10

Helm을 사용하여 Kubernetes에 배포 간소화

Helm 은 Kubernetes 애플리케이션 설치 및 관리를 간소화하는 도구입니다. 또한 작년에 많은 인기와 지역 사회 지원을 얻었습니다. 릴리스 의 Helm 작업은 이제 AKS(Azure Container Service) 또는 다른 Kubernetes 클러스터에 Helm 차트를 패키징하고 배포하는 데 사용할 수 있습니다.

이 Helm 태스크가 추가되면 이제 컨테이너를 Kubernetes 클러스터로 배달하기 위한 Helm 기반 CI/CD 파이프라인을 설정할 수 있습니다. 자세한 내용은 Azure Container Service에 Kubernetes를 사용하여 배포 설명서를 참조하세요.

helm 작업

릴리스에서 사용되는 Control Helm 버전

Helm 도구 설치 관리자 작업은 인터넷 또는 도구 캐시에서 특정 버전의 Helm을 획득하고 에이전트의 PATH(호스트 또는 프라이빗)에 추가합니다. 이 작업을 사용하여 .NET Core cli 작업과 같은 후속 작업에 사용되는 Helm 버전을 변경합니다. 빌드 또는 릴리스 정의에서 Helm 배포 작업 전에 이 작업을 추가하면 올바른 Helm 버전으로 앱을 패키징하고 배포할 수 있습니다. 이 작업은 Helm이 작동하기 위한 필수 구성 요소인 kubectl 도구를 선택적으로 설치하는 데도 도움이 됩니다.

Azure Database for MySQL 지속적으로 배포

이제 azure의 MySQL 데이터베이스를 서비스로 Azure Database for MySQL 지속적으로 배포할 수 있습니다. 버전 제어에서 MySQL 스크립트 파일을 관리하고 PowerShell 스크립트가 아닌 네이티브 작업을 사용하여 릴리스 파이프라인의 일부로 지속적으로 배포합니다.

향상된 Windows 원격 PowerShell 기반 작업 사용

새롭고 향상된 Windows 원격 PowerShell 기반 작업을 사용할 수 있습니다. 이러한 향상된 기능에는 몇 가지 성능 수정이 포함되며 Write-Host 및 쓰기 출력과 같은 라이브 로그 및 콘솔 출력 명령을 지원합니다.

대상 작업의 PowerShell(버전: 3.*): 인라인 스크립트를 추가하고, PSSession 옵션을 수정하고, "ErrorActionPreference"를 제어하고, 표준 오류 발생 시 실패할 수 있습니다.

Azure 파일 복사 작업(버전: 2.*): GitHub 문제를 해결하는 최신 AzCopy(v7.1.0)와 함께 제공됩니다.

GitHub Enterprise 또는 외부 Git 아티팩트에 대한 분기 필터링

이제 GitHub Enterprise 또는 외부 Git 리포지토리에서 릴리스할 때 릴리스될 특정 분기를 구성할 수 있습니다. 예를 들어 특정 분기에서 프로덕션으로 들어오는 빌드만 배포할 수 있습니다.

분기 필터

Go로 작성된 애플리케이션 빌드

Go 도구 설치 관리자 작업을 사용하여 하나 이상의 Go Tool 버전을 즉시 설치합니다. 이 작업은 프로젝트에 필요한 특정 버전의 Go Tool을 획득하고 빌드 에이전트의 PATH에 추가합니다. 대상 Go Tool 버전이 에이전트에 이미 설치된 경우 이 작업은 다운로드하여 다시 설치하는 프로세스를 건너뜁니다.

Go 작업은 종속성을 다운로드하거나, 애플리케이션을 빌드하거나, 테스트하는 데 도움이 됩니다. 이 작업을 사용하여 원하는 사용자 지정 Go 명령을 실행할 수도 있습니다.

파이프라인에서 인라인 또는 파일 기반 Python 스크립트 실행

새 Python 스크립트 작업은 파이프라인에서 Python 스크립트 실행을 간소화합니다. 작업은 리포지토리의 Python 파일(.py)에서 스크립트를 실행하거나 태스크 설정에 스크립트를 수동으로 입력하여 파이프라인의 일부로 저장할 수 있습니다. 작업은 경로에서 Python 버전을 사용하거나 사용할 Python 인터프리터의 절대 경로를 지정할 수 있습니다.

xcpretty에서 향상된 Xcode 빌드 및 테스트 출력 활용

xcpretty 는 xcodebuild 출력의 가독성을 향상시키고 JUnit 형식으로 테스트 결과를 생성합니다. 이제 Xcode 빌드 작업은 호스트된 macOS 에이전트에 있는 것처럼 에이전트 컴퓨터에서 사용할 수 있는 경우 xcpretty를 자동으로 사용합니다. xcpretty 출력은 xcodebuild 출력과 다르고 자세한 정보가 적을 수 있지만 각 빌드에서 전체 xcodebuild 로그를 사용할 수 있도록 합니다.

Test Plans

데스크톱 애플리케이션에 대한 수동 테스트를 실행하는 테스트 실행기(Azure Test Plans) 클라이언트

이제 테스트 실행기(Azure Test Plans) 클라이언트를 사용하여 데스크톱 애플리케이션에 대한 수동 테스트를 실행할 수 있습니다. 이렇게 하면 Microsoft Test Manager에서 Azure Test Plans 이동하는 데 도움이 됩니다. 여기에서 지침을 참조하세요. Test Runner 클라이언트를 사용하여 수동 테스트를 실행하고 각 테스트 단계에 대한 테스트 결과를 기록할 수 있습니다. 스크린샷, 이미지 작업 로그 및 오디오 비디오 녹화와 같은 데이터 수집 기능도 있습니다. 테스트할 때 문제가 발견되면 테스트 실행기를 사용하여 버그에 자동으로 포함된 테스트 단계, 스크린샷 및 주석이 포함된 버그를 만듭니다.

테스트 실행기(Azure Test Plans)에는 실행기를 일회성 다운로드 및 설치해야 합니다. 아래와 같이 데스크톱 애플리케이션에 대해 실행을 선택합니다.

Azure Test Runner

Azure Test Runner 설치

Artifacts

업스트림 소스

Azure DevOps Server 2019는 Azure Artifacts 피드에서 사용할 수 있는 업스트림 원본에 대한 상당한 업데이트를 제공합니다.

  • 이전 TFS 릴리스에서 만든 기존 피드에 nuget.org 업스트림 원본을 추가할 수 있습니다. 업그레이드하기 전에 알고 있어야 하는 동작 변경을 포함하여 자세한 내용은 피드 패키지 위의 배너를 찾습니다.
  • 다른 Azure DevOps Server 피드를 피드에 업스트림 원본으로 추가할 수 있습니다. 즉, 피드를 통해 해당 피드의 NuGet 및 npm 패키지를 사용할 수 있습니다.

또한 Azure Artifacts에서 새로운 역할인 "협력자"를 도입했습니다. 협력자는 업스트림 원본에서 패키지를 저장할 수 있지만 패키지 패키지를 피드에 직접 게시할 수 없습니다(예: nuget 게시 사용). 이렇게 하면 엔지니어가 업스트림 원본의 새 패키지를 사용할 수 있도록 허용하면서 신뢰할 수 있는 사용자 또는 빌드 시스템으로 패키지 게시를 제한할 수 있습니다.

패키지 팔로우

모든 패키지에서 직접 새 팔로우 단추를 사용하여 알림을 더욱 쉽게 설정할 수 있습니다. 팔로우 단추는 릴리스 보기와도 호환됩니다. 보기를 통해 패키지를 보는 동안 패키지를 따르는 경우 해당 보기로 승격된 새 버전에 대한 업데이트만 받게 됩니다.

수동으로 저장할 필요 없이 피드 설정 변경

피드 설정 페이지의 몇 가지 상호 작용이 개선되었습니다. 이제 업스트림 또는 사용 권한 추가와 같은 변경 내용이 즉시 저장됩니다. 즉, 설정 피벗 간에 전환할 때 변경 내용 손실에 대해 걱정할 필요가 없습니다.

새로운 플랫폼 간 NuGet용 자격 증명 공급자를 사용하여 인증 간소화

인증된 NuGet 피드와 상호 작용하는 것이 훨씬 향상되었습니다. 새 .NET Core 기반 Azure Artifacts 자격 증명 공급자 는 Windows, macOS 및 Linux의 msbuild, dotnet 및 nuget(.exe)에서 작동합니다. Azure Artifacts 피드에서 패키지를 사용하려는 경우 자격 증명 공급자는 사용 중인 NuGet 클라이언트를 대신하여 토큰을 자동으로 획득하고 저장합니다. 더 이상 구성 파일에서 토큰을 수동으로 저장하고 관리할 필요가 없습니다.

새 공급자를 가져오려면 GitHub 로 이동하여 클라이언트 및 플랫폼에 대한 지침을 따릅니다.

파일 공유에 게시할 때 기호 압축

기호가 파일 공유에 게시될 때 압축 기호를 지원하도록 인덱스 & 기호 게시 작업을 업데이트했습니다.

기호 압축

Wiki

Git 리포지토리에서 Markdown 파일을 Wiki로 게시

개발자는 코드 리포지토리에서 "API", "SDK" 및 "코드 설명 도움말 문서"에 대한 설명서를 만듭니다. 그런 다음 읽기 권한자는 올바른 설명서를 찾기 위해 코드를 검색해야 합니다. 이제 코드 리포지토리에서 markdown 파일을 게시하고 Wiki에서 호스트할 수 있습니다.

wiki 작업으로 퍼블릭 코드

Wiki 내에서 먼저 코드 게시를 wiki로 클릭합니다. 다음으로, 승격해야 하는 Git 리포지토리에 폴더를 지정할 수 있습니다.

페이지 게시 대화 상자

게시를 클릭하면 선택한 폴더 아래의 모든 markdown 파일이 wiki로 게시됩니다. 또한 Git 리포지토리에 대한 변경 내용이 즉시 반영되도록 분기의 헤드를 wiki에 매핑합니다.

자세한 내용은 제품 설명서 블로그 게시물을 참조하세요.

페이지 내의 제목에 연결

이제 위키 페이지의 섹션 머리글 옆에 있는 링크 아이콘을 클릭하여 해당 섹션에 대한 URL을 직접 생성할 수 있습니다. 그런 다음 해당 URL을 복사하고 팀 구성원과 공유하여 해당 섹션에 직접 연결할 수 있습니다.

Wiki 제목 URL

폴더에 파일 및 이미지 첨부

위키 페이지를 오프라인으로 편집하는 동안 위키 페이지와 동일한 디렉터리에 파일 첨부 파일 및 이미지를 더 쉽게 추가할 수 있습니다. 이제 위키의 모든 폴더에 첨부 파일 또는 이미지를 추가하고 페이지에 연결할 수 있습니다.

Git 리포지토리 폴더의 Wiki 이미지

wiki에 동영상 포함

이제 Microsoft Stream 및 YouTube와 같은 온라인 서비스 위키 페이지에 비디오를 포함할 수 있습니다. 다음 구문을 사용하여 포함된 비디오 URL을 추가할 수 있습니다.

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Wiki에 비디오 포함

wiki 이름 바꾸기

이제 wiki 사용자 인터페이스 및 REST API를 사용하여 wiki의 이름을 바꿀 수 있습니다. 자세히 메뉴에서 wiki 이름 바꾸기를 클릭하여 위키에 기억에 남는 이름을 지정합니다.

wiki 이름 바꾸기

새 탭에서 페이지 열기

이제 위키 페이지를 마우스 오른쪽 단추로 클릭하고 새 탭에서 열거나 Ctrl 키를 누르거나 위키 페이지를 마우스 왼쪽 단추로 클릭하여 새 탭에서 열 수 있습니다.

Wiki 새 탭

Wiki 페이지 제목에 특수 문자 유지

이제 와 같은 : < > * ? | -특수 문자를 사용하여 위키 페이지를 만들 수 있습니다. 이제 "FAQ"와 같은 제목이 있는 페이지가 표시됩니다. 또는 "설정 가이드"는 Wiki에서 만들 수 있습니다. 다음 문자는 UTF-8로 인코딩된 문자열로 변환됩니다.

문자 인코딩된 문자열
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

제대로 연결되지 않은 Wiki의 모든 링크는 고유한 빨간색 및 끊어진 링크 아이콘으로 표시되어 위키 페이지의 모든 끊어진 링크에 대한 시각적 단서를 제공합니다.

위키 끊어진 링크

손상된 페이지 링크는 모든 설명서 솔루션에서 페이지 품질 저하의 주요 원인 중 하나입니다. 이전에 Wiki에서 트리 구조 내에서 페이지를 이동하거나 페이지 이름을 변경한 경우 다른 페이지 및 작업 항목에서 페이지에 대한 링크를 끊을 수 있습니다. 이제 연결이 끊기기 전에 링크를 검사 수정할 수 있습니다.

중요

위키가 []() 잠재적으로 끊어질 수 있는 링크를 찾아 수정할 수 있도록 페이지의 링크에 markdown 구문을 사용하고 작업 항목의 Wiki페이지 링크 형식을 사용해야 합니다. 작업 항목의 일반 텍스트 URL 및 하이퍼링크는 이 기능을 통해 선택되지 않습니다.

페이지의 이름을 바꾸거나 이동하면 영향을 받는 절대 링크 또는 상대 링크를 검사 메시지가 표시됩니다.

페이지 이동 대화 상자

그러면 조치를 취하기 전에 영향을 받는 페이지 링크 및 작업 항목 목록이 표시됩니다.

페이지 링크 이동

wiki 페이지에 대한 목차 만들기

경우에 따라 위키 페이지가 길어질 수 있으며 콘텐츠가 여러 제목으로 구성됩니다. 이제 구문을 사용하여 제목이 하나 이상 있는 페이지에 목차를 [[_TOC_]] 추가할 수 있습니다.

Wiki 목차

페이지를 편집할 때 서식 창에서 적절한 단추를 클릭하여 목차를 삽입할 수도 있습니다.

wiki TOC 삽입

Azure DevOps에서 markdown 을 사용하는 방법에 대한 자세한 내용은 markdown 지침 설명서를 참조하세요.

YAML 태그를 사용하여 Wiki 페이지 및 코드 미리 보기에 대한 Surface 메타데이터

설명서에 메타데이터를 추가하면 판독기 및 검색 인덱스가 의미 있는 콘텐츠를 선택하고 노출하는 데 도움이 될 수 있습니다. 이 업데이트에서는 파일 시작 부분에 YAML 블록이 포함된 모든 파일이 헤드 1개와 행 1개의 메타데이터 테이블로 변환됩니다. YAML 블록은 삼중 파선 사이에 설정된 유효한 YAML 형식을 사용해야 합니다. 모든 기본 데이터 형식, 목록, 개체를 값으로 지원합니다. 구문은 Wiki 및 코드 파일 미리 보기에서 지원됩니다.

YAML 태그 예제:

---
tag: post
title: Hello world
---

YAML 테이블

목록이 있는 YAML 태그 예제:

---
tags:
- post
- code
- web
title: Hello world
---

목록이 있는 YAML 테이블

참가 권한을 사용하여 코드를 wiki로 게시

이전에는 git 리포지토리에 대한 리포지토리 만들기 권한이 있는 사용자만 코드를 wiki로 게시할 수 있었습니다. 이로 인해 리포지토리 관리자 또는 작성자는 git 리포지토리에 호스트된 markdown 파일을 wiki로 게시하라는 요청에 병목 현상이 발생했습니다. 이제 코드 리포지토리에 대한 기여 권한이 있는 경우 코드를 wiki로 게시할 수 있습니다.

보고

이제 보고를 위한 Analytics Marketplace 확장을 사용할 수 있습니다.

이제 Analytics Marketplace 확장을 Azure DevOps Server 사용할 수 있습니다. 분석은 Azure DevOps 및 Azure DevOps Server 대한 보고의 미래입니다. Analytics 확장을 설치하면 고급 위젯, Power BI 통합 및 OData 액세스가 제공됩니다.

자세한 내용은 분석이란? 및 보고 로드맵을 검사. 분석은 공개 미리 보기로 제공됩니다. 현재 파이프라인을 통한 Boards 및 자동화된 테스트 결과에 대한 데이터가 포함되어 있습니다. Analytics Service에서 사용할 수 있는 데이터를 참조하세요.

새 빌드 dashboard 위젯을 통해 빌드 기록 조사

대시보드에 추가할 수 있는 새롭고 향상된 빌드 기록 위젯이 있습니다. 이 위젯을 사용하면 이제 dashboard 특정 분기에서 빌드 기록을 보고 익명 방문자를 위한 공용 프로젝트에서 구성할 수 있습니다.

중요

XAML 빌드에 대한 인사이트를 찾고 있는 경우 이전 위젯을 계속 사용하고 XAML 빌드에서 새 빌드로 마이그레이션하는 방법에 대해 읽어보세요. 그렇지 않으면 최신 위젯으로 이동하는 것이 좋습니다.

사용자 의견

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

맨 위로 이동