Azure DevOps Server 2019 릴리스 정보

개발자 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.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라는 폴더에 AzurePowerShellV4.zip 패키지를 추출합니다.

  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 사용자 입력을 sanitize하는지 확인합니다.
  • 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

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

Azure Repos

  • "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

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

Azure Test Plans

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

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용 보안 패치를 릴리스했습니다. 자세한 내용은 블로그 게시물을 참조하세요.


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

참고

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


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

Azure DevOps Server 2019 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 서비스에 롤아웃되었으며 이제 Azure DevOps Server 2019에서 사용할 수 있습니다. 자세한 내용은 블로그를 참조하세요.

새 탐색

Artifacts 및 Release Management 배포 파이프라인 라이선스에 대한 변경 내용

사용자 피드백에 따라 Azure DevOps Server 2019에서 라이선스를 두 가지 주요 변경하고 있습니다. 첫째, 고객은 Artifacts 사용하기 위해 아티팩트 확장을 더 이상 구매할 필요가 없습니다. 이제 Artifacts 라이선스 사용이 기본 라이선스에 포함됩니다. 기본 라이선스가 할당된 모든 사용자는 이제 Artifacts 사용할 수 있습니다. 둘째, 고객은 더 이상 Release Management 배포 Pipelines 구매할 필요가 없습니다. 빌드 Pipelines 마찬가지로 Release Management 배포 Pipelines 이제 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 사용하고 풍부한 프로젝트 관리 기능을 원하는 Teams 이제 리포지토리를 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 코드를 빌드하는 Teams 빌드 요약에 GitHub 커밋에 연결된 작업 항목도 표시됩니다.

새 작업 항목 허브

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

작업 항목 허브

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

작업 항목 허브 목록

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

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

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

Boards 허브

새 쿼리 허브

새 쿼리 허브는 더 최신 모양과 느낌으로 이전 허브의 많은 기존 쿼리 기능을 간소화하고 중요한 쿼리를 쉽게 얻을 수 있는 새로운 기능을 제공합니다. 새 환경의 몇 가지 주요 사항으로는 다음이 포함됩니다.

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

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

작업 항목을 다른 프로젝트로 이동 및 작업 항목 형식 변경

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

스프린트 계획 기능

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

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

스프린트 계획

새 디렉터리 페이지

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

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

디렉터리 페이지

새 보기 옵션 메뉴

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

옵션 보기

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

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

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

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

주석 설정

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

주석 작업 항목

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

주석 빠른 생성

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

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

영역 드롭다운 목록

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

반복 드롭다운 목록

+/- 를 통해 반복 일정에 대한 쿼리 작업 @CurrentIteration

@CurrentIteration팀이 반복 일정에 따라 작업을 추적하는 데 도움이 되는 매크로는 이제 정수 오프셋을 지원합니다. - 1로 닫지 않은 작업에 대한 탭을 쉽게 @CurrentIteration 유지하거나 + 1을 통해 향후 반복을 위해 계획된 작업을 미리 살펴봅니다. @CurrentIteration 자세한 내용은 Microsoft DevOps 블로그의 @CurrentIteration 게시물을 참조하세요. 이 기능은 현재 456표의 투표로 가장 높은 12개 투표 제안을 기반으로 우선 순위가 결정되었습니다.

Team 매개 변수를 통해 쿼리 반복 일정 명확하게 지정 @CurrentIteration

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

팀 매개 변수

새 매크로를 통해 팀의 영역 경로에서 작업 쿼리 @TeamAreas

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

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

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

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

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

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

작업 항목 연결

이전에는 작업 항목 미리 보기 창이 꺼져 있는 경우 검색 결과 페이지에서 작업 항목을 열 수 없었습니다. 이렇게 하면 검색 결과를 자세히 알아보기 어려울 수 있습니다. 이제 작업 항목 제목을 클릭하여 모달 창에서 작업 항목을 열 수 있습니다. 이 기능은 UserVoice에서 우선 순위가 적용되었습니다.

Repos

향상된 분기 선택기

Azure Repos 대부분의 환경을 사용하려면 리포지점과 해당 리포지점의 분기를 선택해야 합니다. 분기 수가 많은 조직에서 이 환경을 개선하기 위해 새 분기 선택기를 출시하고 있습니다. 이제 선택기를 사용하여 즐겨 찾는 분기를 선택하거나 분기를 빠르게 검색할 수 있습니다.

분기 선택기

끌어오기 요청 정책을 무시할 때 알림 받기

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

정책 알림 무시

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

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

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

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

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

참고

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

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

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

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

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

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

PR(끌어오기 요청) 환경을 처음 시작하면 PR을 만들 때 선택한 팀 컨텍스트에 모든 PR을 할당하는 것이 타당하다고 생각합니다. 많은 사람들이 팀 컨텍스트와 PR 할당 간의 연결을 알아차리지 못했으므로 이 동작은 불만의 지점이었습니다. 실제로 이는 주요 UserVoice 제안중 하나입니다.

새 탐색 변경의 일환으로 팀과의 기본 연결을 변경할 기회를 했습니다. 두 가지 변경 내용이 표시됩니다.

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

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

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

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

PR용 템플릿 추가

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

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

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

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

대상 분기 변경

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

이제 기능 분기에 PR이 활성 상태이고 변경 전에 에 병합된 경우 어떻게 되는지 생각해 main 보세요. 이전에는 변경 내용을 중단하고 에 새 PR을 main 만들거나 PR을 에 병합한 다음 에서 로 features/new-feature 다른 PR을 만들어야 features/new-feature main 했습니다. 대상 분기를 업데이트하는 이 새로운 작업을 사용하면 features/new-feature 모든 컨텍스트와 주석을 유지하면서 PR의 대상 분기를 에서 로 변경할 수 main 있습니다. 대상 분기를 변경하면 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에서 관리하는 클라우드 호스팅 인프라에서 실행되는 빌드/릴리스 에이전트입니다.
프라이빗 에이전트 자체 호스팅 에이전트 제공되고 관리되는 컴퓨터에서 실행되는 빌드/릴리스 에이전트입니다.
에이전트 풀 에이전트 풀 빌드 또는 릴리스를 실행할 수 있는 에이전트 컴퓨터의 조직 수준 집합입니다.
에이전트 큐 에이전트 풀 빌드 또는 릴리스를 실행할 수 있는 에이전트 컴퓨터의 프로젝트 수준 집합입니다. 조직 수준 에이전트 풀에 연결됩니다.
빌드 정의 빌드 파이프라인 애플리케이션에 대한 빌드 단계의 엔드 투 엔드 집합입니다.
빌드 빌드 실행 중이거나 실행된 빌드 파이프라인의 인스턴스입니다.
단계 작업 에이전트에서 순차적으로 또는 병렬로 실행되는 일련의 작업입니다. 빌드 또는 릴리스 파이프라인은 하나의 작업 또는 여러 작업의 그래프를 포함할 수 있습니다.
릴리스 정의 릴리스 파이프라인 다양한 단계에서 애플리케이션을 배포하기 위한 엔드 투 엔드 릴리스 단계 집합입니다.
해제 해제 실행 중이거나 실행된 릴리스 파이프라인의 인스턴스입니다.
Environment 단계 릴리스 파이프라인에서 생성된 릴리스를 배포할 위치를 나타내는 논리적이고 독립적인 엔터티입니다.
동시 작업/파이프라인 병렬 작업 병렬 작업을 사용하면 조직에서 한 번에 단일 빌드 또는 릴리스 작업을 실행할 수 있습니다. 더 많은 병렬 작업을 사용할 수 있으면 더 많은 빌드 및 릴리스 작업을 동시에 실행할 수 있습니다.
서비스 엔드포인트 서비스 연결 빌드 또는 릴리스에서 작업을 실행하기 위해 외부 서비스에 연결하는 데 사용되는 자격 증명과 같은 설정 그룹입니다.

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

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

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

릴리스 방문 페이지

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

릴리스 폴더

릴리스 진행률 시각화

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

릴리스 파이프라인 보기

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

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

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

환경이 표시됩니다.

배포 전 및 배포 후

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

릴리스 환경 작업

커밋 및 작업 항목

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

커밋 및 작업 항목 해제

배포 진행률 및 로그

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

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

릴리스 로그 세부 정보

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

테스트 허브 아래의 컴퓨터 그룹은 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

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

이제 다른 빌드가 성공적으로 완료되면 빌드를 트리거할 수 있습니다. 업스트림 빌드에서 생성된 Artifacts 다운로드하여 이후 빌드에서 사용할 수 있으며, 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) 특수 변수를 사용하여 이 작업을 수행할 수 있었습니다. 이제 빌드를 실행할 때마다 자동으로 증가되는 고유한 카운터 변수를 빌드 정의에 정의할 수 있습니다. 정의의 변수 탭에서 이 작업을 수행합니다. 이 새로운 기능은 다음과 같은 방법으로 더 많은 기능을 제공합니다.

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

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

Pipelines에서 준수 및 보안 유효성 검사 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 비트와같은 두 가지 새로운 지원 플랫폼을 도입 하 고 있습니다. 이러한 새 플랫폼을 통해 Raspberry Pi, Linux/ARM 컴퓨터와 같은 더 낮은 공배수를 제공 하 고 중요 하지 않은 플랫폼을 빌드할 수 있습니다.

Pipelines의 테스트 환경 향상

이제 테스트 탭 에는 Pipelines 에 대 한 다양 한 상황에 맞는 테스트 정보를 제공 하는 최신 환경이 있습니다. 새 환경에서는 진행 중인 테스트 뷰, 전체 페이지 디버깅 환경, 컨텍스트 테스트 기록, 중단 된 테스트 실행 보고 및 실행 수준 요약을 제공 합니다.

새 테스트 허브

진행 중인 테스트 실행 보기

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

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

진행 중인 테스트 뷰

위의 In-Progress 테스트 요약을 클릭 하 여 Test Plans 에서 실패 했거나 중단 된 테스트 정보와 함께 자세한 테스트 요약을 볼 수 있습니다. 테스트 요약은 새 결과의 가용성에 따라 요청 시 자세히 보기를 새로 고치는 기능과 함께 정기적으로 새로 고쳐집니다.

자세한 테스트 요약

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

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

전체 페이지 디버깅

컨텍스트에서 테스트 기록 보기

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

상황에 맞는 테스트 기록

중단 된 테스트 보기

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

중단 된 테스트 보기

테스트 기록의 테스트 추적 및 릴리스 환경 지원

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

요약 된 테스트 결과 검토

테스트를 실행 하는 동안 테스트는 전체 결과에 영향을 주는 여러 테스트 인스턴스를 생성할 수 있습니다. 몇 가지 예로는 오류가 발생 한 경우 다시 실행되는 테스트, 다른 테스트 (예: 순서가 지정 된 테스트)의 순서가 지정 된 조합으로 구성 된 테스트 또는 제공 된 입력 매개 변수 (데이터 기반 테스트)를 기반으로 하는 다른 인스턴스가 있는 테스트 등이 있습니다. 이러한 테스트는 서로 관련 되어 있으므로 개별 테스트 결과를 기반으로 하는 전체 결과와 함께 보고 해야 합니다. 이 업데이트를 사용 하면 릴리스의 테스트 탭에 계층으로 제공 되는 향상 된 버전의 테스트 결과가 도입 됩니다. 예제를 살펴보겠습니다.

이전에는 VS 테스트 작업에서 실패 한 테스트를 다시 실행 하는 기능이 도입 되었습니다. 그러나이 기능의 유용성이 약간 제한 된 테스트를 마지막으로 시도한 경우에만 보고 됩니다. 이제이 기능을 확장 하 여 테스트 실행의 각 인스턴스를 시도로 보고 했습니다. 또한 테스트 관리 API는 이제 계층적 테스트 결과를 게시 하 고 쿼리 하는 기능을 지원 합니다. 자세한 내용은 테스트 결과 API 설명서를 참조 하세요.

테스트 요약 디버그

참고

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

Pipelines에서 테스트 분석 보기

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

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

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

테스트 분석

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

여러 에이전트 없는 태스크를 사용 하 여 정의 간소화

에이전트 없는 단계의 태스크는 서버에서 오케스트레이션 실행 됩니다. 에이전트 없는 단계에는 에이전트 또는 대상 컴퓨터가 필요 하지 않습니다. 에이전트 단계와 달리 정의의 에이전트 없는 각 단계에는 태스크를 하나만 추가할 수 있습니다. 이는 프로세스에 에이전트 없는 태스크가 두 개 이상 있는 경우 정의를 많은데 하는 여러 단계를 추가 해야 한다는 것을 의미 합니다. 이 제한을 완화 하 여 에이전트 없는 단계로 여러 작업을 유지할 수 있습니다. 동일한 단계의 태스크는 에이전트 단계와 마찬가지로 순차적으로 실행 됩니다. 자세한 내용은 서버 단계 설명서를 참조 하세요.

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

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

릴리스 게이트 패널

게이트가 지속적으로 성공할 때까지 배포 보류

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

게이트 보류 설정

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

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

배포 그룹

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

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

빌드 태그 트리거

릴리스 시 변수 설정

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

릴리스 변수

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

릴리스의 릴리스 변수

환경 변수를 작업에 전달

CI/CD 태스크 작성자는 작업에 환경 변수를 전달 하기 위해 작업에서 새 속성인 showenvironment 변수를 설정할 수 있습니다. 이렇게 하면 추가 컨트롤이 빌드 편집기의 작업에서 렌더링 됩니다. Powershell, CmdBash 작업에 사용할 수 있습니다.

환경 변수 전달

이렇게 하면 두 가지 시나리오를 사용할 수 있습니다.

  • 태스크에는 변수 이름에 대/소문자를 유지 하는 환경 변수가 필요 합니다. 예를 들어 위의 예제에서 작업으로 전달 되는 환경 변수는 "foo"가 아니라 "foo"가 됩니다.
  • 이를 통해 암호 값을 스크립트에 안전 하 게 전달할 수 있습니다. 에이전트의 운영 체제에서 해당 인수를 포함 하는 프로세스의 호출을 기록할 수 있으므로 암호를 스크립트에 인수로 전달 하는 것이 좋습니다.

변수 그룹 복제

변수 그룹 복제에 대 한 지원이 추가 되었습니다. 변수 그룹을 복제 하 고 몇 가지 변수를 업데이트 하려고 할 때마다 변수를 하나씩 추가 하는 지루한 프로세스를 거칠 필요가 없습니다. 이제 변수 그룹의 복사본을 신속 하 게 만들고, 값을 적절 하 게 업데이트 하 고, 새 변수 그룹으로 저장할 수 있습니다.

변수 그룹 복제

참고

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

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

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

게이트 무시

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

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

릴리스의 PR 트리거

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

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

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

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

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

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

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

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

앱 서버 배포 작업을 사용 하 여 Linux 컨테이너 배포

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

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

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

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

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

Xcode 10

투구를 사용 하 여 Kubernetes에 배포 간소화

투구 는 Kubernetes 응용 프로그램의 설치 및 관리를 간소화 하는 도구입니다. 또한 작년에 많은 인기와 커뮤니티 지원을 받았습니다. 이제 AKS () 또는 다른 Kubernetes 클러스터에 대 한 투구 차트 Azure Container Service를 패키징 및 배포 하는 데 릴리스에 대 한 투구 작업을 사용할 수 있습니다.

이제이 투구 작업을 추가 하 여 컨테이너를 Kubernetes 클러스터로 제공 하기 위해 작성 한 CI/CD 파이프라인을 설정할 수 있습니다. 자세한 내용은 Kubernetes를 사용 하 여 배포 Azure Container Service 설명서를 참조 하세요.

투구 작업

릴리스에서 사용 되는 컨트롤 투구 버전

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

Azure Database for MySQL에 지속적으로 배포

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

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

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

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

Azure 파일 복사 작업 (버전: 2. *): GitHub 문제를 해결 하는 최신 AzCopy (v 7.1.0)를 제공 합니다.

GitHub Enterprise 또는 외부 Git 아티팩트의 필터 분기

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

분기 필터

Go로 작성 된 응용 프로그램 빌드

Go 도구 설치 관리자 작업을 사용 하 여 하나 이상의 go tool 버전을 즉시 설치할 수 있습니다. 이 작업은 프로젝트에 필요한 특정 버전의 Go 도구를 가져와 빌드 에이전트의 경로에 추가 합니다. 대상 이동 도구 버전이 이미 에이전트에 설치 되어 있는 경우이 작업은 다시 다운로드 하 여 설치 하는 프로세스를 건너뜁니다.

Go 태스크는 종속성을 다운로드 하거나 응용 프로그램을 빌드 또는 테스트 하는 데 도움이 됩니다. 이 작업을 사용 하 여 사용자가 선택한 사용자 지정 Go 명령을 실행할 수도 있습니다.

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

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

Xcpretty의 향상 된 Xcode 빌드 및 테스트 출력 활용

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

Test Plans

데스크톱 응용 프로그램에 대 한 수동 테스트를 실행 하는 test Runner (Azure Test Plans) 클라이언트

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

test runner (Azure Test Plans)를 사용 하려면 Runner를 한 번 다운로드 하 여 설치 해야 합니다. 아래와 같이 데스크톱 응용 프로그램에 대해 실행 을 선택 합니다.

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로 게시 됩니다. 또한 분기의 헤드를 wiki에 매핑하여 Git 리포지토리의 변경 내용이 즉시 반영 됩니다.

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

이제 wiki 페이지에서 섹션 제목 옆에 있는 링크 아이콘을 클릭 하 여 해당 섹션에 직접 URL을 생성할 수 있습니다. 그런 다음 해당 URL을 복사 하 고 팀 멤버와 공유 하 여 해당 섹션에 직접 연결할 수 있습니다. 이 기능은 제안에 따라 우선 순위가 지정되었습니다.

Wiki 제목 URL

폴더에 파일 및 이미지 첨부

Wiki 페이지를 오프 라인으로 편집 하는 동안 wiki 페이지와 동일한 디렉터리에 첨부 파일 및 이미지를 추가 하는 것이 더 쉬울 수 있습니다. 이제 wiki의 모든 폴더에 첨부 파일 또는 이미지를 추가 하 고 페이지에 연결할 수 있습니다. 이 기능은 제안에 따라 우선 순위가 지정되었습니다.

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

wiki에 동영상 포함

이제 Microsoft Stream 및 YouTube와 같은 온라인 서비스의 wiki 페이지에 비디오를 포함할 수 있습니다. 다음 구문을 사용 하 여 포함 된 비디오 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에 기억 하기 쉬운 이름을 지정 합니다.

Wiki 이름 바꾸기

새 탭에서 페이지 열기

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

Wiki 새 탭

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

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

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

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

Wiki 끊어진 링크

끊어진 페이지 링크는 모든 설명서 솔루션에서 페이지 품질 저하의 주요 원인 중 하나입니다. 이전에는 Wiki에서 트리 구조 내에서 페이지를 이동하거나 페이지의 이름을 바꾸면 다른 페이지 및 작업 항목에서 페이지 링크가 끊어질 수 있었습니다. 이제 링크를 확인하고 수정한 후 끊어질 수 있습니다.

중요

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

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

페이지 이동 대화 상자

그런 다음 작업을 수행하기 전에 영향을 받는 페이지 링크작업 항목의 목록이 표시됩니다.

페이지 링크 이동

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

경우에 따라 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 마켓플레이스 확장을 사용할 수 있습니다.

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

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

새 빌드 대시보드 위젯을 통해 빌드 기록 조사

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

중요

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


사용자 의견

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


맨 위로 이동