Azure DevOps Server 2019 업데이트 1 릴리스 정보

개발자 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 업데이트 1.1 패치 11 릴리스 날짜: 2021 년 9 월 14 일

Azure DevOps Server 2019 용 패치 11 업데이트 1.1에는 다음에 대 한 수정 사항이 포함 되어 있습니다.

Azure DevOps Server 2019 업데이트 1.1 패치 10 릴리스 날짜: 8 월 10 2021 일

Azure DevOps Server 2019 용 패치 10 업데이트 1.1에는 다음에 대 한 수정 사항이 포함 되어 있습니다.

  • 일부 작업 항목 형식에 대 한 전자 메일 배달 작업 문제를 해결 합니다.

Azure DevOps Server 2019 업데이트 1.1 패치 9 릴리스 날짜: June 15, 2021

Azure DevOps Server 2019 업데이트 1.1 용 패치 9 에는 다음에 대 한 수정 사항이 포함 되어 있습니다.

  • 데이터 가져오기 문제를 해결 합니다. 오래 된 테스트 사례가 많은 고객에 게는 데이터 가져오기 시간이 오래 걸리고 있습니다. 이는 테이블의 크기를 늘리는 참조로 인 한 것입니다 tbl_testCaseReferences . 이 패치를 사용 하 여 오래 된 테스트 사례에 대 한 참조를 제거 하 여 데이터 가져오기 프로세스의 속도를 향상 시킬 수 있습니다.

Azure DevOps Server 2019 업데이트 1.1 패치 8 릴리스 날짜: 4 월 13 2021 일

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다.

이 패치에 대 한 픽스를 구현 하려면 일반 패치 설치AzureResourceGroupDeploymentV2 작업 설치에 대해 아래에 나열 된 단계를 수행 해야 합니다.

일반 패치 설치

2019 업데이트 1.1 Azure DevOps Server 경우 2019 업데이트 1.1 패치 8 Azure DevOps Server설치 해야 합니다.

설치 확인

  • 옵션 1: 실행 devops2019.1.1patch8.exe CheckInstall , devops2019.1.1patch8.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.1.1 Patch 8을 설치한 후 버전은 17.153.31129.2가 됩니다.

AzureResourceGroupDeploymentV2 작업 설치

참고

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

설치

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

  2. Node.js 14.15.1 and 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 업데이트 1.1 패치 7 릴리스 날짜: 1 월 12 일 2021

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

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

Azure DevOps Server 2019 업데이트 1.1 패치 6 릴리스 날짜: 12 월 8 2020 일

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

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

중요

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

일반 패치 설치

2019 업데이트 1.1 Azure DevOps Server 있는 경우 2019 업데이트 1.1 Patch 6 Azure DevOps Server설치 해야 합니다.

설치 확인

  • 옵션 1: 실행 devops2019.1.1patch6.exe CheckInstall , devops2019.1.1patch6.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 . 2019.1.1 Patch 6 Azure DevOps Server를 설치한 후 버전은 17.153.30723.5가 됩니다.

AzurePowerShellV4 작업 설치

참고

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

필수 조건

  1. 개인 에이전트 컴퓨터에 Azure PowerShell Az module 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\azurepowershellv4 입니다.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019 업데이트 1.1 패치 5 릴리스 날짜: 9 월 8 일, 2020

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

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

Azure DevOps Server 2019 업데이트 1.1 패치 4 릴리스 날짜: 2020 년 7 월 14 일

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

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

Azure DevOps Server 2019 업데이트 1.1 패치 3 릴리스 날짜: June 9, 2020

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

  • CVE-2020-1327: Azure DevOps 서버에서 사용자 입력을 정화 확인 합니다.

Azure DevOps Server 2019 업데이트 1.1 패치 2 릴리스 날짜: 2020 년 4 월 14 일

다음을 수정 하는 Azure DevOps Server 2019 업데이트 1.1에 대 한 패치 를 출시 했습니다. 자세한 내용은 블로그 게시물을 참조하세요.

  • SVN 커밋이 파이프라인을 트리거하지 않음

  • Azure DevOps SSH에서 SHA2에 대한 지원 추가

Azure DevOps Server 2019 업데이트 1.1 패치 1 릴리스 날짜: 2020년 3월 10일

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


Azure DevOps Server 2019 업데이트 1.1 RTW 릴리스 날짜: 2019년 12월 10일

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

참고

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

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

Azure Boards

  • 제품 백로그에서 새 작업 항목을 만들 때 제목 필드는 프로세스 템플릿의 기본값으로 초기화되지 않습니다.
  • Azure Boards 사용하는 경우 속도 저하 및 시간 제한
  • 작업 항목 링크에서 수정 기준 값이 잘못되었습니다.

Azure Pipelines

Azure Test Plans

  • Test Plans 필드를 편집하는 속도가 느립니다.
  • 테스트 사례에서 Test Plans 아닌 Boards 열 때 공유 단계 세부 정보가 열리지 않습니다.

일반

관리

  • 메모리 사용량이 높습니다.
  • 부하 분산기 구성이 있는 서버는 AllowedOrigins 레지스트리 항목에 해당 공용 원본을 명시적으로 추가해야 했습니다.
  • SQL Azure 설치하는 고객에게는 평가판 완료 대화 상자가 표시되지 않습니다.
  • 확장을 설치하면 "오류 메시지 기여 누락(ms.vss-dashboards-web.widget-sdk-version-2)" 오류가 발생합니다.
  • Elastic Search를 설정하는 경우 "사용자가 권한이 없습니다."라는 오류가 발생합니다.
  • TFS 2018 업데이트 2 이상에서 업그레이드할 때 Elastic Search의 인덱싱 및 쿼리 실패
  • Azure DevOps Server 구성할 때 "웨어하우스 만들기" 단계가 실패합니다.

이 릴리스에는 다음 업데이트가 포함되어 있습니다.

  • SQL Server 2019에 대한 지원

Azure DevOps Server 2019 업데이트 1 패치 1 릴리스 날짜: 2019년 9월 10일

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


Azure DevOps Server 2019 업데이트 1 릴리스 날짜: 2019년 8월 20일

참고

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


RC2 릴리스 날짜: 2019년 7월 23일

RC2는 RC1 이후 몇 가지 버그 수정을 포함하며 마지막으로 계획된 사전판입니다.


RC1 릴리스 날짜: 2019년 7월 2일

Azure DevOps Server 2019 업데이트 1의 새로운 내용 요약

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

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


일반

어두운 테마

어두운 테마는 Azure DevOps Services 많이 사용되었으며 이제 Azure DevOps Server 사용할 수 있습니다. 모든 페이지의 오른쪽 위에 있는 아바타 아래 메뉴에서 테마를 선택하여 어두운 테마를 설정할 수 있습니다.

어두운 테마

Boards

새 기본 프로세스

지금까지 Agile은 다양한 프로젝트 배달 방법에 적합한 강력하고 유연한 작업 항목 형식 및 상태 집합을 제공하는 새 프로젝트의 기본 프로세스였습니다. 다른 도구에 더 익숙하거나 더 강력한 도구 집합을 채택하려는 일부 팀의 경우 더 친숙한 용어를 사용하여 빠르게 시작하려고 합니다.

새로운 기본 프로세스는 작업을 계획하고 추적하기 위한 세 가지 작업 항목 유형(에픽, 문제 및 작업)을 제공합니다. 에픽을 사용하여 문제를 더 큰 작업 단위로 그룹화하면서 문제를 사용하여 사용자 스토리, 버그 및 기능과 같은 작업을 추적하는 것이 좋습니다. 작업을 진행하면서 To Do, 수행 및 완료의 간단한 상태 워크플로를 따라 항목을 이동합니다.

기본 프로세스

새 프로젝트를 시작하는 데 도움이 되는 문제 및 작업 추적 설명서를 참조하세요.

작업 항목 양식의 상태 값 순서

이전에는 작업 항목 폼의 상태 값이 사전순으로 정렬되었습니다. 이 업데이트를 통해 프로세스 설정의 워크플로 순서와 일치하도록 상태 값이 정렬되는 방식이 변경되었습니다. 상태 사용자 지정 설정에서 각 범주의 상태 순서를 변경할 수도 있습니다.

상태 순서

기능 사용 기능을 더 이상 사용할 수 없음

고객은 컬렉션을 업그레이드한 후 새 기능을 사용하도록 설정하기 위해 각 프로젝트에 대한 XML을 수동으로 업데이트해야 합니다.

기능 사용

특정 기능을 사용하도록 설정하는 방법을 알아보려면 설명서를 참조하세요.

더 다양한 작업 항목 첨부 파일로 참조 자료 구성

작업 항목에 파일을 첨부 하면 사용자와 팀이 필요할 때 항상 가까이 있도록 참조 자료를 중앙 집중화할 수 있습니다. 이제 작업 항목 폼 어디에서 나 파일을 끌어서 놓는 방법으로 새 첨부 파일을 쉽게 추가할 수 있습니다. 첨부 파일을 목록으로 계속 보거나 그리드 보기로 전환 하 여 축소판 그림 미리 보기를 표시할 수 있습니다. 파일을 두 번 클릭 하 여 미리 보기를 열고 필요한 정보를 신속 하 게 찾을 수 있도록 주기를 전환 합니다.

작업 항목 첨부 파일

배지를 사용 하 여 팀 보드 공유

리포지토리의 추가 정보는 종종 프로젝트 팀에서 솔루션에 참여 하 고 사용 하는 방법에 대 한 정보를 제공 하는 홈입니다. 이제 Azure Pipelines의 빌드 또는 배포 상태와 마찬가지로 Azure Boards에서 팀 보드에 대 한 추가 정보 배지에 추가할 수 있습니다. 진행 중인 열 또는 모든 열만 표시 하도록 배지를 구성 하 고 프로젝트가 오픈 소스인 경우 배지를 공개적으로 표시 하도록 할 수 있습니다.

배지를 사용 하 여 팀 보드를 공유 하는 방법을 보여 주는 짧은 비디오입니다.

추가 정보가 Markdown을 기반으로 하는 경우 상태 배지 설정 페이지에서 샘플 Markdown를 복사 하 여 파일에 붙여 넣을 수 있습니다.

GitHub의 추가 정보에 배지를 표시 하는 스크린샷

일, 주, 월 또는 연도의 시작을 기준으로 하는 작업을 쿼리 합니다.

팀이 다음에 발생 하거나 스 프린트 반복을 기반으로 하는 컨텍스트 내에서 작업에 집중 하는 경우가 종종 있지만, 지난 달 또는 해당 연도의 첫 번째 분기에 발생 한 모든 작업에 대해 보고 하기 위해 달력의 렌즈를 통해 작업을 다시 살펴보는 것이 흥미롭습니다. 이제 @StartOf 날짜 기반 필드와 함께 다음과 같은 새 매크로 집합을 사용 하 여 일, 주, 월 또는 연도의 시작을 기준으로 쿼리할 수 있습니다.

  • @StartOfYear
  • @StartOfMonth
  • @StartOfWeek
  • @StartOfDay

이러한 각 매크로는 서로 다른 날짜 단위로 데이터를 이동할 수 있도록 하는 새로운 한정자 문자열도 허용 합니다. 예를 들어 상태 변경 날짜 >= @StartOfYear 및 상태 변경 날짜 <= @StartOfYear ("+ 3M")을 쿼리하여 올해의 첫 번째 분기에 완료 된 모든 작업 항목을 찾는 쿼리를 작성할 수 있습니다. 자세한 내용은 쿼리 매크로 설명서를 참조 하세요.

일, 주, 월 또는 년의 시작을 기준으로 하는 쿼리 작업을 보여 주는 스크린샷

토론 설명 편집 및 삭제

Azure Boards에서 작업 항목의 토론에서 의견을 Community, 편집 및 삭제 하는 데 매우 투표 된 개발자 의 가용성을 발표 하 게 되어 기쁘게 생각 합니다. 의견을 편집 하기 위해 소유 하 고 있는 모든 주석을 마우스로 가리키면 두 개의 새 단추가 표시 됩니다. 연필 아이콘을 클릭 하면 편집 모드로 전환 되며 편집을 간단히 수행 하 고 "업데이트" 단추를 눌러 편집 내용을 저장할 수 있습니다.

토론 설명을 보여 주는 스크린샷

오버플로 메뉴를 클릭 하면 주석을 삭제 하는 옵션이 표시 됩니다. 이를 클릭 하면이 메모를 삭제할 것인지 묻는 메시지가 다시 표시 되 고 주석이 삭제 됩니다.

토론 설명을 삭제 하는 방법을 보여 주는 스크린샷

작업 항목 폼의 기록 탭에서 모든 편집 및 삭제 된 메모에 대 한 전체 추적을 갖게 됩니다. 또한 더 현대적인 대화형으로 보이도록 토론 환경의 UI를 업데이트 했다는 것을 알 수 있습니다. 개별 주석의 시작 및 종료 위치를 명확 하 게 설명 하는 거품을 추가 했습니다.

CSV 파일로 쿼리 결과 내보내기

이제 쿼리 결과를 웹에서 CSV 서식 파일로 직접 내보낼 수 있습니다.

쿼리 결과를 내보내는 방법을 보여 주는 짧은 비디오입니다.

이제 구문을 사용 하 여 문제 주석 내에서 작업 항목을 요청 하거나 끌어오기 요청을 GitHub 하거나 커밋을 수행할 때 AB#{work item ID} 이러한 멘 션은 언급 된 작업 항목으로 직접 이동 하기 위해 클릭할 수 있는 하이퍼링크가 됩니다.

이렇게 하면 관련 된 모든 대화에 대 한 Azure Boards의 작업 항목을 불필요 하는 정식 링크를 만들 수 없습니다. 대신 팀에서 코드 또는 고객이 보고 한 문제를 논의 하는 동안 작업 항목에 대해 좀 더 자세한 정보를 제공 하는 방법을 제공 합니다. 자세한 내용은 Azure Boards GitHub 통합 설명서를 참조 하세요.

GitHub에 대 한 끌어오기 요청을 보여 주는 스크린샷

Azure Boards를 계획 하는 동안 GitHub의 문제를 수락 하 고 실행 합니다.

이제 Azure Boards의 작업 항목을 GitHub의 관련 문제와 연결할 수 있습니다. 이 새로운 유형의 링크를 사용 하면 다른 몇 가지 시나리오를 사용할 수 있습니다. 팀에서 GitHub 내의 문제로 인해 사용자 로부터 버그 보고서를 계속 수락 하려고 하지만 Azure Boards 전반적으로 팀의 작업을 연결 하 고 구성 하는 작업은 이제 가능 합니다.

Azure Boards의 작업 항목을 GitHub의 관련 문제와 연결할 수 있음을 보여 주는 스크린샷

팀에서 커밋 및 끌어오기 요청에 대해 사용 하는 것과 동일한 언급 구문을 적용 합니다. 물론, 문제 URL을 사용 하 여 Azure Boards에서 수동으로 연결할 수 있습니다. 자세한 내용은 GitHub & Azure Boards 설명서를 참조 하세요.

GitHub 문제 URL을 사용 하 여 Azure Boards에서 수동으로 연결 하는 방법을 보여 주는 스크린샷

간판 보드에서 연결 된 GitHub 활동 빠르게 보기

사용자가 간판 보드를 직접 또는 팀으로 검토할 때 "이 항목의 개발이 아직 시작 되었습니까?"와 같은 질문이 있는 경우가 종종 있습니다. 또는 "이 항목을 검토 하지만 이제 간판 보드의 새 GitHub 주석을 사용 하 여 항목의 위치를 빠르게 파악 하 고 GitHub 커밋, 끌어오기 요청 또는 문제에 대 한 정보를 직접 탐색할 수 있습니다. 이에 대 한 자세한 내용 및 작업 및 테스트에 대 한 다른 주석은 카드 사용자 지정 설명서를 참조 하세요.

간판 보드에서 연결 된 GitHub 작업을 보는 방법을 보여 주는 스크린샷

Repos

초안 끌어오기 요청

끌어오기 요청이 준비 되기 전에 완료 되는 것을 방지 하 고, 모든 사용자에 게 관여 하지 않을 수 있는 진행 중인 작업을 쉽게 만들 수 있도록 하기 위해 이제 끌어오기 요청 초안을 지원 합니다.

끌어오기 요청을 만들 때 만들기 단추 드롭다운에서 초안으로 만들기 를 선택 하 여 끌어오기 끌어오기 요청을 만들 수 있습니다.

PR 초안 만들기

초안 끌어오기 요청을 만들면 제목 옆의 상태를 나타내는 배지가 표시 됩니다.

초안 임을 보여 주는 끌어오기 요청의 스크린샷

초안 끌어오기 요청에는 검토자가 포함 되지 않으며 기본적으로 빌드를 실행 하지만 검토자를 수동으로 추가 하 고 빌드를 실행할 수 있습니다. 끌어오기 요청을 일반 끌어오기 요청으로 승격 하려면 끌어오기 요청 세부 정보 페이지에서 게시 단추를 클릭 하면 됩니다.

자동 완성 끌어오기 요청에 대해 만료 된 빌드 다시 실행

Azure Repos는 이제 끌어오기 요청 정책에 의해 트리거된 만료 된 빌드를 자동으로 큐에 대기 시킵니다. 이는 다른 모든 정책을 통과 하 고 자동 완성으로 설정 된 끌어오기 요청에 적용 됩니다.

이전에는 끌어오기 요청에 필수 검토자와 같은 정책이 있는 경우 승인 프로세스가 너무 오래 걸리고, 검토자가 끌어오기 요청을 승인 하기 전에 연결 된 빌드가 만료 될 수 있습니다. 끌어오기 요청이 자동 완성으로 설정 된 경우 사용자가 만료 된 빌드를 수동으로 큐에 대기 시킬 때까지 차단 된 상태로 유지 됩니다. 이 변경 내용으로 빌드는 성공한 빌드 후 끌어오기 요청이 자동으로 완료 될 수 있도록 자동으로 큐에 대기 됩니다.

참고

이 자동화는 끌어오기 요청당 최대 5 개의 만료 된 빌드를 큐에 대기 시키고 각 빌드를 한 번만 다시 큐에 대기 하려고 합니다.

끌어오기 요청에서 왼쪽 또는 오른쪽 파일만 보기

현재 끌어오기 요청에서 파일 변경 내용을 볼 때 병렬 diff 또는 인라인 diff 모드를 사용할 수 있습니다. 원본 파일 또는 변경 된 파일을 비교 하지 않고 확인 하는 것이 많은 사용자 의견을 받았습니다. 따라서 왼쪽 파일이 나 오른쪽 파일을 개별적으로 볼 수 있는 새로운 옵션이 추가 되었습니다.

수정 된 콘텐츠 표시를 커서로 가리키는 커서와 함께 병렬 diff 옵션의 스크린샷

끌어오기 요청을 완료 하기 위한 새 병합 유형

이제 끌어오기 요청에서 대상 분기로 변경 내용을 병합할 때 추가 옵션을 사용할 수 있습니다. 개발자 Community에서 가장 많이 요청 되는 기능 중 두 가지에 대 한 지원이 추가 되었습니다. 빠른 전방 병합 및 반 선형 병합 ("주소 다시 지정 및 병합"이 라고도 함).

이제 끌어오기 요청 완료 대화 상자에서 다음과 같은 새 옵션을 사용할 수 있습니다.

끌어오기 요청을 완료 하기 위한 새 병합 형식을 보여 주는 스크린샷

관리자는 업데이트 된 정책 관리 페이지를 사용 하 여 분기 또는 분기 폴더에서 허용 되는 병합 전략을 제어할 수 있습니다.

병합 유형 제한 섹션의 스크린샷

참고

기존 정책은 여전히 적용 됩니다. 예를 들어 현재 분기에 "squash merge only" 정책이 적용 된 경우 새 병합 전략을 사용 하려면 해당 정책을 편집 해야 합니다.

끌어오기 요청을 완료 하는 동안의 기준 주소를 사용할 수 없는 몇 가지 경우가 있습니다.

  • 대상 분기의 정책에서 기준 주소 다시 지정 전략을 사용 하지 못하도록 설정 하는 경우 "분기 정책 재정의" 권한이 필요 합니다.
  • 끌어오기 요청의 소스 분기에 정책이 있는 경우이를 기준으로 다시 지정할 수 없습니다. 의 기준 주소는 정책 승인 프로세스를 거치지 않고 소스 분기를 수정 합니다.
  • 병합 충돌 확장 을 사용 하 여 병합 충돌을 해결 한 경우 3 방향 병합에 적용 되는 충돌 해결은 끌어오기 요청의 모든 커밋을 한 번에 하나씩의 기준 주소 때 거의 성공 하거나 유효 하지 않습니다.

이러한 모든 경우에는 분기를 로컬로의 기준 주소 서버에 푸시할 수도 있고, 끌어오기 요청을 완료할 때 변경 내용을 squash로 병합할 수도 있습니다.

끌어오기 요청에서 대상 분기로 필터링 (Pr)

끌어오기 요청을 통해 팀에서 코드를 검토 하 고 변경 내용에 대 한 피드백을 제공 하 여 주 분기에 병합할 수 있습니다. 제안 된 변경 내용을 단계별로 실행 하 고, 주석을 두고, 코드 변경을 승인 또는 거부 하도록 투표를 수행할 수 있기 때문에 많은 팀의 워크플로에서 중요 한 부분이 됩니다.

끌어오기 요청을 더 쉽게 찾을 수 있도록 대상 분기를 사용 하 여 Pr를 검색할 수 있는 필터링 옵션을 추가 했습니다.

끌어오기 요청 필터링 옵션 Azure Pipelines의 스크린샷

또한 대상 분기 필터링을 사용 하 여 광산 탭에서 끌어오기 요청 보기를 사용자 지정할 수 있습니다.

광산에서 끌어오기 요청 사용자 지정 탭의 스크린샷

확장을 사용 하 여 구문 강조 표시 및 자동 완성 추가

현재는 모나코 편집기에서 지 원하는 언어의 하위 집합에 대 한 구문 강조 표시를 게시 합니다. 그러나 지원 하지 않는 언어에 대 한 고유한 구문 강조 표시를 만들려고 합니다.

이 업데이트를 사용 하면 확장을 통해 파일 탐색기 및 끌어오기 요청 뷰에 구문 강조 표시와 자동 완성 기능을 추가할 수 있는 확장 지점을 추가 했습니다.

여기에서이 기능을 보여 주는 확장의 예제를 찾을 수 있습니다.

또한 Kusto 언어 구문 강조 표시에 대 한 지원이 추가 되었습니다.

리포지토리 생성 확장 지점

리포지토리 선택기에 새 항목을 추가할 수 있도록 하는 확장 지점을 추가 했습니다. 이 확장 지점을 사용 하면 대체 리포지토리 생성 시나리오와 같은 흐름을 사용 하도록 설정 하 여 사용자 지정 작업 (리디렉션, 팝업 등)을 리포지토리 선택기 메뉴에 추가할 수 있습니다.

리포지토리 생성 확장을 보여 주는 스크린샷

향상 된 인코딩 지원

이전에는 웹에서 파일을 편집 하 고 저장 하는 것은 UTF-8 인코딩으로만 저장 되며 파일 인코딩이 변경 될 때 메시지를 표시 하지 않았습니다. 이제는 utf encoding을 지 원하는 웹을 통해 UTF로 인코딩되지 않은 파일을 저장 하려고 할 때 경고를 제공 합니다. 또한 웹 푸시 끝점을 통해 UTF-16 및 u t f-32 인코딩에 대 한 지원을 추가 했습니다. 즉, 인코딩 형식을 그대로 유지 하므로 u t f-8로 다시 작성할 필요가 없습니다.

다음 스크린샷에서는 웹 푸시에의 한 인코딩 변경을 도입할 때 표시 되는 대화 상자의 예를 보여 줍니다.

ASCII가 아닌 문자가 추가 되었음을 알리는 경고 mesaage를 보여 주는 스크린샷. 커밋 하면이 파일이 유니코드로 인코딩됩니다.

Go get command support in Azure Repos

Go는 Golang 라고도 하는 오픈 소스 프로그래밍 언어입니다. Go에서 get 명령을 사용 하 여 패키지 및 종속성을 다운로드 하 고 설치할 수 있습니다. 이 업데이트를 사용 하면 Azure DevOps 리포지토리 내에에 대 한 지원이 추가 되었습니다 go get . go get를 사용 하면 가져오기 경로에 의해 이름이 지정 된 패키지를 다운로드할 수 있습니다. 키 단어를 사용 import 하 여 가져오기 경로를 지정할 수 있습니다.

Pipelines

YAML 파이프라인을 위한 IntelliSense를 사용 하는 웹 편집기

YAML을 사용 하 여 파이프라인을 정의 하는 경우 이제이 릴리스에 도입 된 새로운 편집기 기능을 활용할 수 있습니다. 새 YAML 파이프라인을 만들거나 기존 YAML 파이프라인을 편집 하는 경우에는 파이프라인 웹 편집기 내에서 YAML 파일을 편집할 수 있습니다. YAML 파일을 편집할 때 IntelliSense 지원에 Ctrl + Space를 사용 합니다. 구문 오류를 강조 표시 하 고 이러한 오류를 수정 하는 방법에 대 한 도움말을 볼 수 있습니다.

강조 표시 된 구문 오류를 보여 주는 스크린샷

YAML 파일 편집용 작업 도우미

파이프라인에 대 한 YAML 파일을 보다 쉽게 편집할 수 있도록 하는 많은 피드백을 계속 받게 되므로, 작업 길잡이를 YAML 편집기에 추가 합니다. 이를 통해 클래식 편집기에서와 같이 YAML 파일에 새 작업을 추가 하는 것과 동일한 친숙 한 환경을 사용할 수 있습니다. 이 새 길잡이는 선택 목록 및 서비스 연결과 같은 대부분의 일반적인 작업 입력 형식을 지원 합니다. 새 작업 길잡이를 사용 하려면 YAML 기반 파이프라인에서 편집 을 선택한 다음 작업 도우미 를 선택 합니다.

작업 도우미를 사용 하 여 YAML 파일을 편집 하는 방법을 보여 주는 짧은 비디오입니다.

태그를 사용 하 여 YAML 파이프라인 트리거

커밋에 태그를 추가할 때 YAML 파이프라인을 트리거할 수 있습니다. 이는 워크플로가 태그를 포함 하는 팀에 게 유용 합니다. 예를 들어 커밋에 "마지막으로 알려진 양호" 태그가 지정 된 경우 프로세스를 시작할 수 있습니다.

포함 하거나 제외할 태그를 지정할 수 있습니다. 예:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

컨테이너 리소스 인라인 선언

이전에는 YAML 파이프라인에서 컨테이너 리소스를 선언한 다음 이름으로 참조 해야 했습니다. 이제 컨테이너를 여러 번 참조 하지 않는 경우 인라인 구문을 제공 합니다.

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

끌어오기 요청이 업데이트 될 때 기존 파이프라인을 자동으로 취소 하도록 설정

새 커밋이 동일한 PR으로 푸시되는 경우 기본적으로 끌어오기 요청 (Pr)에 의해 트리거되는 파이프라인이 취소 됩니다. 이는 일반적으로 오래 된 코드에서 파이프라인을 계속 실행 하지 않으려는 경우에 적합 합니다. 이 동작을 원하지 않는 경우 PR 트리거에 Autocancel: false 를 추가할 수 있습니다.

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

YAML 파이프라인에서 체크 아웃 된 코드의 디렉터리를 선택 합니다.

이전에는 s $ (Agent. builddirectory)의 디렉터리에 리포지토리를 체크 아웃 했습니다. 이제 YAML 파이프라인에서 사용할 Git 리포지토리를 체크 아웃할 디렉터리를 선택할 수 있습니다.

에서 키워드를 사용 하 여 path checkout 폴더 구조를 제어할 수 있습니다. 다음은 디렉터리를 지정 하는 데 사용할 수 있는 YAML 코드의 예입니다.

steps:
- checkout: self
  path: my-great-repo

이 예제에서 코드는 my-great-repo 에이전트의 작업 영역에 있는 디렉터리에 체크 아웃 됩니다. 경로를 지정 하지 않으면 리포지토리는 이라는 디렉터리로 계속 체크 아웃 됩니다 s .

YAML에 최적화 된 새로운 Azure App Service 작업

이제 최신 개발자에 게 Azure 앱 서비스를 쉽게 배포할 수 있는 강력한 방법을 제공 하는 네 가지 새로운 작업을 지원 합니다. 이러한 작업에는 최적화 된 yaml 구문이 포함 되어 있으며,이를 통해 웹 앱, functionapps, 컨테이너 용 웹 앱 및 Windows 및 Linux 플랫폼의 컨테이너에 대 한 functionapps을 비롯 한 Azure appservices에 대 한 배포를 간단 하 고 직관적으로 만들 수 있습니다.

또한 XML 및 JSON 형식의 파일 변환과 변수 대체에 대 한 새 유틸리티 작업을 지원 합니다.

새 프로젝트에 대 한 기본 사용 권한 변경

지금까지 "빌드 정의 만들기" 권한을 명시적으로 지정 하지 않으면 프로젝트 참가자가 파이프라인을 만들 수 없습니다. 새 프로젝트의 경우 팀 멤버가 파이프라인을 쉽게 만들고 업데이트할 수 있습니다. 이렇게 변경 하면 Azure Pipelines에 등록 중인 새 고객의 충돌이 줄어듭니다. 항상 Contributors 그룹에 대 한 기본 사용 권한을 업데이트 하 고 해당 액세스를 제한할 수 있습니다.

파이프라인을 사용 하 여 GitHub 릴리스 관리

GitHub 릴리스는 소프트웨어를 패키지 하 고 사용자에 게 제공 하는 좋은 방법입니다. 이제 Azure Pipelines에서 GitHub 릴리스 작업을 사용 하 여 자동화할 수 있음을 발표 하 게 되어 기쁘게 생각 합니다. 작업을 사용 하 여 새 릴리스를 만들거나, 기존 초안/게시 된 릴리스를 수정 하거나, 이전 버전을 삭제할 수 있습니다. 여러 자산 업로드, 릴리스를 시험판으로 표시, 릴리스를 초안으로 저장 등의 기능을 지원 합니다. 이 작업은 릴리스 정보를 만드는 데도 도움이 됩니다. 또한이 릴리스에서 만든 변경 내용 (커밋 및 관련 문제)을 자동으로 계산 하 고 사용자에 게 친숙 한 형식으로 릴리스 정보에 추가할 수 있습니다.

다음은 작업에 대 한 간단한 YAML입니다.

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

GitHub 릴리스 (미리 보기) 대화 상자의 스크린샷

이 작업을 사용 하 여 만든 샘플 GitHub 릴리스입니다.

이 작업을 사용 하 여 만든 샘플 GitHub 릴리스의 스크린샷

이제 빌드 로그의 특정 줄에 대 한 링크를 공유할 수 있습니다. 이렇게 하면 빌드 실패를 진단할 때 다른 팀 멤버와 공동 작업 하는 데 도움이 됩니다. 결과 뷰에서 로그의 줄을 선택 하 여 링크 아이콘을 가져옵니다.

로그의 줄이 강조 표시 되 고이 선택 옵션에 대 한 복사 링크를 호출한 빌드 솔루션 디렉터리의 스크린샷

리소스 권한 부여 향상

YAML 파일에서 참조 하는 경우 보호 된 리소스 (예: 서비스 연결, 변수 그룹, 에이전트 풀, 보안 파일)에 대 한 보안을 제공 해야 합니다. 동시에 비프로덕션 시나리오에 대해 이러한 유형의 리소스를 사용 하는 파이프라인을 보다 쉽게 설정 하 고 사용할 수 있도록 하려고 했습니다. 이전에는 리소스를 ' 모든 파이프라인에서 사용할 수 있는 권한 '으로 표시 하는 설정을 추가 했습니다.

이 업데이트를 사용 하면 리소스를 이와 같이 표시 하지 않은 경우에도 리소스 권한 부여 문제를 더 쉽게 해결할 수 있습니다. 새 환경에서 리소스 권한 부여 오류로 인해 빌드가 실패 하는 경우 파이프라인에서 해당 리소스의 사용을 명시적으로 부여 하는 옵션이 표시 된 후 계속 진행 됩니다. 리소스 권한을 부여할 수 있는 권한이 있는 팀 멤버는 실패 한 빌드에서 바로이 작업을 완료할 수 있습니다.

권한 부여 오류가 있는 파이프라인 요약을 보여 주는 스크린샷

Pipelines 테스트 탭의 새로운 확장 기여 점수

Pipelines의 테스트 결과 탭에서 두 개의 새 기여 점수를 추가 하 여 확장 프레임 워크를 더욱 강력 하 게 만들었습니다. 이를 통해 Marketplace 확장 을 사용 하 여 더 많은 맞춤형 보고 환경을 제공 하 고 상호 작용을 더 추가할 수 있습니다.

두 가지 기여 지점은 다음과 같습니다.

  1. 도구 모음의 사용자 지정 작업 단추

    경우에 따라 테스트 결과에서 메타 데이터를 사용 하 여 API 데이터를 업데이트 하거나 사용자 지정 도구를 실행 하는 등의 작업을 수행 하는 것이 좋습니다. 이 기여 지점을 사용 하 여 선택한 테스트 결과의 즉각적인 컨텍스트를 사용 하 여 사용자 지정 작업을 * 사용자 지정 작업단추에 추가 하는 확장을 만들 수 있습니다.

    사용자 지정 동작 옵션의 스크린샷

  2. 세부 정보 창의 사용자 지정 세부 정보 탭

    다양 한 테스트 보고서 사용 워크플로가 있을 수 있으며, 디버깅 및 분석에 대해 실패 한 테스트에 대해 다른 데이터 요소를 확인 하는 것이 좋습니다. 팀에서는이 기여 지점을 사용 하 여 데이터 표에서 임의의 테스트 결과 행을 선택할 때 표시 되는 세부 정보 창에 새 탭을 추가할 수 있습니다. 이 새 탭은 정적 콘텐츠 또는 내부 또는 외부 Api를 사용 하 여 가져온 동적 데이터를 포함 하는 뷰를 표시할 수 있습니다.

한 번 실행 에이전트

Azure Container Instances와 같은 인프라를 사용 하 여 탄력적 개인 에이전트를 실행 하는 경우 각 에이전트는 한 작업을 수행 하기 전에 하나의 작업만 수락 하도록 하려고 합니다. 지금 까지는 에이전트를 종료 하거나 (오류가 보고 될 수 있음) 에이전트가 다른 작업을 수신할 수 있는 위험을 허용 하기 때문에이 작업을 수행할 수 없습니다. 이 업데이트에서는 --once 플래그를 에이전트 구성에 추가했습니다. 이러한 방식으로 에이전트를 구성하면 에이전트는 하나의 작업만 수락한 다음, 자체 작업을 종료합니다.

에이전트 풀 사용자 인터페이스 업데이트

프로젝트 설정의 에이전트 풀 관리 페이지가 새 사용자 인터페이스로 업데이트되었습니다. 이제 풀에서 실행 중인 모든 작업을 쉽게 볼 수 있습니다. 또한 작업이 실행되지 않는 이유를 알아볼 수 있습니다.

에이전트 풀 UX(사용자 환경) 업데이트를 보여주는 스크린샷

배포 그룹에서 실패한 대상에 배포

기본적으로 Azure Pipelines 이전에 실패한 실행을 다시 배포할 때 모든 작업을 다시 실행하는 데 사용됩니다. 이제 배포할 때 배포 옵션을 구성하여 이 동작을 재정의할 수 있습니다. 배포 그룹에서 모든 작업 및 실패한 대상으로 제한 옵션을 선택하면 다시 실행하면 모든 작업이 실행되고 배포가 이미 최신인 대상으로 건너뜁니다.

선택한 배포 옵션, 테스트 실패 및 배포 옵션 섹션이 호출된 스크린샷

실패할 때 자동으로 다시 배포

스테이지에 대한 배포가 실패하면 이제 Azure Pipelines 마지막으로 성공한 배포를 자동으로 다시 배포할 수 있습니다. 배포 후 조건에서 자동 다시 배포 트리거를 구성하여 마지막으로 성공한 릴리스를 자동으로 배포하도록 스테이지를 구성할 수 있습니다. 향후 스프린트에서 트리거된 이벤트 및 작업을 자동 다시 배포 구성에 추가할 계획입니다. 자세한 내용은 배포 그룹 설명서를 참조하세요.

자동 다시 배포 트리거 섹션이 호출된 배포 후 조건 대화 상자를 보여주는 스크린샷.

Grafana 주석 서비스 후크

이제 Grafana 대시보드에 배포 완료 이벤트에 대한 Grafana 주석을 추가할 수 있는 새 서비스 후크를 지원합니다. 이렇게 하면 Grafana 대시보드에서 시각화되는 애플리케이션 또는 인프라 메트릭의 변경 내용과 배포의 상관 관계를 파악할 수 있습니다.

메트릭의 변경 내용을 보여주는 Grafana 대시보드의 스크린샷.

쿼리 Azure Monitor 경고 작업

이전 버전의 Azure Monitors 쿼리 태스크는 클래식 모니터링 환경의 경고 쿼리만 지원했습니다. 이 새 버전의 작업을 사용하면 Azure Monitor 최근에 도입된 통합 모니터링 환경의 경고를 쿼리할 수 있습니다.

쿼리 Azure Monitor 경고 미리 보기를 보여주는 스크린샷

Kubernetes에 배포 작업에서 사양 파일의 인라인 입력

이전에는 Kubernetes 배포 작업에서 구성에 대한 파일 경로를 제공해야 했습니다. 이제 구성 인라인도 추가할 수 있습니다.

인라인 구성 기능을 보여주는 스크린샷.

Docker CLI 설치 관리자 작업

이 작업을 통해 사용자가 지정한 대로 에이전트에 모든 버전의 Docker CLI를 설치할 수 있습니다.

설치된 DockerCLI를 보여주는 스크린샷.

삭제된 릴리스 파이프라인 복원

사용되지 않는 릴리스 파이프라인을 삭제하면 릴리스 파이프라인 목록을 정리하는 데 도움이 되지만 실수로 항목을 삭제하는 경우도 있습니다. 이 업데이트를 통해 지난 30일 이내에 삭제된 릴리스 파이프라인을 복원할 수 있습니다. 릴리스 페이지의 왼쪽 패널에 삭제된 릴리스 파이프라인 목록을 표시하는 새 탭을 추가했습니다. 이 보기에서 목록에서 파이프라인을 선택하고 복원 단추를 클릭하여 삭제된 릴리스 파이프라인을 복원할 수 있습니다.

파이프라인에 대한 복원 옵션을 보여주는 스크린샷.

릴리스 만들기 요청 실패 시 알림

빌드, 코드 베이스 및 기타 작업이 변경되면 이메일을 받도록 알림을 설정할 수 있습니다. 예를 들어 작업 항목이 할당될 때 알림을 받도록 경고를 설정할 수 있습니다.

이 업데이트를 통해 릴리스 범주에 새 알림 구독을 추가했습니다. 이 알림은 릴리스 만들기에 대한 요청이 실패할 때 전자 메일을 보냅니다. 이 기능이 유용할 수 있는 예제 시나리오는 아티팩트 버전을 사용할 수 없으므로 릴리스 만들기 요청이 실패하는 경우입니다. 알림을 관리하는 방법을 알아보려면 여기설명서를 참조하세요.

릴리스 범주가 강조 표시되고 릴리스 만들기에 대한 A 요청 실패 옵션이 호출된 새 구독 마법사를 보여주는 스크린샷.

원본 또는 파이프라인 변경에 대한 릴리스 예약

이전에는 예약된 릴리스 트리거가 있을 때 업스트림 아티팩트 또는 릴리스 정의에서 변경이 검색되지 않은 경우에도 릴리스가 트리거됩니다. 아티팩트 버전 또는 릴리스 정의가 변경된 경우에만 릴리스를 예약하는 옵션이 릴리스 트리거 예약 패널에 추가되었습니다.

원본 또는 파이프라인이 변경된 경우에만 일정 릴리스 옵션이 호출된 예약된 릴리스 트리거 섹션의 스크린샷.

릴리스 만들기 대화 상자의 변수에 대한 기여 지점

이전에는 릴리스를 만드는 동안 필요한 변수 값을 사용자가 도움이나 제안 없이 입력해야 했습니다. 릴리스를 만드는 동안 변수 값을 채우는 데 도움이 되는 확장을 지원하기 위해 새 릴리스 만들기 대화 상자에 기여 지점을 추가했습니다.

새 릴리스 만들기 대화 상자의 스크린샷.

Azure Service Bus 세션 큐에 게시

세션 큐에 메시지를 게시하는 기능을 포함하도록 에이전트 없는 작업 빌드 태스크를 확장했습니다. 이 옵션은 Azure Service Bus 게시 작업에 추가되었습니다.

Azure에 게시 Service Bus 작업의 스크린샷.

Kubernetes 서비스 연결의 새 Azure 구독 옵션

빌드 및 릴리스에 대한 서비스 연결을 사용하면 외부 및 원격 서비스에 연결하여 빌드 또는 배포에 대한 작업을 실행할 수 있습니다. 프로젝트의 관리자 설정에서 서비스 연결을 정의하고 관리할 수 있습니다.

이 업데이트에서는 Kubernetes 서비스 연결 양식에 인증 옵션을 추가했습니다. 이제 Azure 구독을 선택하여 연결을 인증할 수 있습니다. 이렇게 하면 Azure 구독 및 클러스터 이름으로 Kubernetes 연결을 설정하여 특정 네임스페이스에 쉽게 배포할 수 있습니다.

RBAC(역할 기반 액세스 제어)가 설정된 클러스터의 경우 ServiceAccountRoleBinding 개체가 선택한 네임스페이스에 만들어집니다. RoleBinding 개체는 생성된 서비스 계정의 작업을 선택한 네임스페이스로만 제한합니다. RBAC 사용 안 함 클러스터의 경우 만든 서비스 계정에는 네임스페이스에 대한 클러스터 전체 권한이 있습니다.

Azure 구독 옵션이 호출된 Kubernetes 서비스 연결 추가 대화 상자의 스크린샷.

Docker 레지스트리 서비스 연결의 Azure 컨테이너 레지스트리

이제 프로젝트의 설정 페이지에서 Docker 레지스트리 서비스 연결을 만들 수 있습니다. 연결을 만들려면 AAD(Azure Active Directory) ID와 연결된 구독 중 하나에서 Azure Container Registry를 선택합니다. 및 와 같은 컨테이너 레지스트리에 대한 서비스 연결이 필요한 모든 작업은 Docker@2 KubernetesManifest@0 연결을 지정하는 단일 방법을 지원합니다.

Docker 서비스 연결을 추가하는 방법을 보여주는 스크린샷.

릴리스 정의에서 폴더 이름으로 검색

릴리스 정의를 폴더에 저장하여 구성할 수 있습니다. 이전에는 폴더별로 검색을 수행할 수 있는 옵션이 없었습니다. 많은 폴더를 만든 경우 특정 릴리스 정의를 찾기가 어려웠습니다. 이제 릴리스 정의에서 폴더 이름으로 검색하여 원하는 정의를 더 쉽게 찾을 수 있습니다.

폴더에 저장된 릴리스 정의를 보여주는 스크린샷.

빌드 및 릴리스 파이프라인의 실행 도구 설치 관리자 작업

실행은 CNAB(클라우드 네이티브 애플리케이션 번들)를 설치하고 관리할 수 있는 명령줄 도구입니다. CNAB를 사용하면 컨테이너 네이티브 앱과 해당 서비스를 번들, 설치 및 관리할 수 있습니다.

이 업데이트에서는 특정 버전의 표시줄 이진 파일을 설치할 수 있는 빌드 및 릴리스 파이프라인에 대한 새 작업을 추가했습니다.

표시 도구 설치 관리자의 스크린샷.

Kubernetes 매니페스트 작업

매니페스트 파일을 사용하여 Kubernetes 클러스터에 배포하는 프로세스를 간소화하기 위해 릴리스 파이프라인에 새 작업을 추가했습니다. 이 작업은 스크립트에서 kubectl 이진을 사용하는 경우와 비교할 때 다음과 같은 이점을 제공합니다.

  • 아티팩트 대체 - 배포 작업은 태그 또는 다이제스트와 함께 지정할 수 있는 컨테이너 이미지 목록을 입력으로 사용합니다. 이는 클러스터에 적용하기 전에 매니페스트 파일의 템플릿이 아닌 버전으로 대체되어 클러스터의 노드에서 올바른 버전의 이미지를 끌어오도록 합니다.

  • 매니페스트 안정성 - 작업 상태를 성공/실패로 계산하는 동안 안정성 검사를 통합하기 위해 배포된 Kubernetes 개체에 대한 롤아웃 상태가 확인됩니다.

  • 추적 가능성 주석 - 원래 조직, 프로젝트, 파이프라인 및 실행에 대한 추적 가능성 정보를 중첩하기 위해 배포된 Kubernetes 개체에 주석이 추가됩니다.

  • 준비 매니페스트 - 작업의 준비 작업을 통해 Helm 차트를 Kubernetes 매니페스트 파일에 표시하여 클러스터에 적용할 수 있습니다.

  • 배포 전략 - 배포 작업을 사용하여 카나리아 전략을 선택하면 작업의 승격/거부 작업을 활용하여 보존할 버전을 완료하기 전에 작업 중에 비교할 수 있도록 -baseline-canary 접미사가 붙는 원하는 워크로드 비율을 만들 ManualIntervention 수 있습니다.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

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

Docker 작업으로 업그레이드

파이프라인 제작 환경을 간소화하기 위해 Docker 작업을 업그레이드했습니다. 이제 buildAndPush 명령을 사용하여 특정 컨테이너 리포지토리에 대한 여러 태그를 빌드하고 한 단계로 여러 컨테이너 레지스트리에 푸시할 수 있습니다. 이 작업은 Docker 레지스트리 서비스 연결을 사용하여 컨테이너 레지스트리에 로그인할 수 있습니다. 원본 리포지토리, 커밋 및 빌드 출처에 대한 추적 가능성 메타데이터는 이 작업을 사용하여 빌드된 이미지에 레이블로 추가됩니다.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectl 도구 설치 관리자

에이전트에 특정 버전의 Kubectl 이진 파일을 설치할 수 있는 새 작업을 추가했습니다. 'v1.14.0'과 같은 최신semver 버전 문자열은 Kubectl 버전 사양 입력에 유효한 값으로 허용됩니다.

Kubectl 도구 설치 관리자를 보여주는 스크린샷.

ServiceNow 통합 개선

팀 간 협업의 주요 기능은 각 팀이 선택한 서비스를 사용하고 효과적인 엔드투엔드 배달을 가능하게 하는 것입니다. 이 업데이트를 통해 모든 유형의 변경 내용(정상, 표준 및 응급)을 지원하도록 ServiceNow 통합이 향상되었습니다. 또한 이제 조직에서 이어지는 ITSM 프로세스에 따라 기존 템플릿을 사용하여 새 변경 요청을 만드는 데 사용되는 게이트를 지정할 수 있습니다. 마지막으로 기존 변경 요청에 따라 릴리스를 게이트할 수도 있습니다. 이렇게 하면 IT 팀에서 권장하는 프로세스를 변경할 필요 없이 CD를 채택할 수 있습니다.

ServiceNow 변경 관리 기능을 보여주는 스크린샷.

Red Hat Enterprise Linux 6 지원

이 업데이트를 통해 Red Hat Enterprise Linux 6에 대한 에이전트 지원이 추가되었습니다. 이제 빌드 및 릴리스 작업 실행을 위해 Red Hat Enterprise Linux 6 플랫폼을 대상으로 하는 에이전트를 구성할 수 있습니다.

Azure PowerShell Az 모듈 지원

Azure PowerShell 명령줄에서 Azure 리소스를 관리하는 데 사용할 수 있는 cmdlet 집합을 제공합니다. 지난 12월에 Azure PowerShell Az 모듈을 사용할 수 있게 되었으며, 이제 Azure 리소스를 관리하기 위한 모듈이 되었습니다.

이전에는 호스트된 에이전트에서 Azure PowerShell Az 모듈에 대한 지원을 제공하지 않았습니다. 빌드 및 릴리스 파이프라인의 새 Azure PowerShell 작업 버전 4.*를 통해 모든 플랫폼에 대한 새 Az 모듈에 대한 지원을 추가했습니다. Azure PowerShell 작업 버전 3.*은 AzureRM 모듈을 계속 지원합니다. 그러나 최신 Azure 서비스 및 기능을 사용하려면 최대한 빨리 Azure PowerShell 작업 버전 4.*로 전환하는 것이 좋습니다.

Az 모듈에는 기존 스크립트를 업데이트하여 새 구문을 사용하도록 업데이트하는 데 도움이 되는 호환성 모드가 있습니다. Az 모듈에 대한 호환성을 사용하도록 설정하려면 Enable-AzureRmAlias 명령을 사용합니다. 별칭을 사용하면 Az 모듈에서 이전 cmdlet 이름을 사용할 수 있습니다. Azure RM 모듈에서 Azure PowerShell Az 모듈로 마이그레이션하는 방법은 여기에서 확인할 수 있습니다.

참고

프라이빗 에이전트를 사용하는 경우 에이전트 컴퓨터에 Az 모듈을 설치해야 합니다.

Azure PowerShell Az 모듈에 대한 자세한 내용은 여기 설명서를 참조하세요.

Azure SQL 작업에 대한 AD(Azure Active Directory) 인증 지원

Azure SQL 작업은 SQL 서버 인증에 대한 기존 지원 외에도 Azure AD(통합 & 암호) 및 연결 문자열을 사용하여 데이터베이스에 연결할 수 있도록 향상되었습니다.

인증 유형 드롭다운 옵션이 강조 표시된 Azure SQL Database 배포 대화 상자의 스크린샷.

긴 파일 경로를 통해 빌드 아티팩트 게시

지금까지는 경로가 233자보다 긴 빌드 아티팩트 업로드를 방지하는 제한이 있었습니다. 이렇게 하면 파일 경로가 제한보다 긴 Linux 및 macOS 빌드에서 코드 검사 결과를 업로드하지 못할 수 있습니다. 긴 경로를 지원하도록 제한이 업데이트되었습니다.

커밋에 대한 CI(연속 통합) 건너뛰기

이제 커밋을 무시하고 커밋이 일반적으로 트리거하는 파이프라인 실행을 건너뛰도록 Azure Pipelines 지시할 수 있습니다. HEAD 커밋의 커밋 메시지에 를 포함하기만 [skip ci] 하면 Azure Pipelines CI를 건너뜁니다. 아래에 나열된 변형을 사용할 수도 있습니다. 이는 Azure Repos Git 및 GitHub Enterprise Server에 대한 커밋에 대해 지원됩니다.

  • [skip ci] 또는 [ci skip]
  • skip-checks: true 또는 skip-checks:true
  • [skip azurepipelines] 또는 [azurepipelines skip]
  • [skip azpipelines] 또는 [azpipelines skip]
  • [skip azp] 또는 [azp skip]
  • ***NO_CI***

Test Plans

테스트 결과 추세(고급) 위젯

테스트 결과 추세(고급) 위젯은 여러 빌드 및 릴리스에 대한 테스트 데이터에 대한 거의 실시간 가시성을 제공합니다. 테스트 결과 추세(고급) 위젯은 파이프라인 또는 파이프라인에 대한 테스트 결과의 추세를 표시합니다. 이를 사용하여 일일 테스트 수, 통과율 및 테스트 기간을 추적할 수 있습니다. 시간이 지남에 따라 테스트 품질을 추적하고 테스트 데이터 정렬을 개선하는 것은 정상 DevOps 파이프라인을 유지 관리하는 데 중요합니다.

테스트 결과 추세(고급) 위젯의 스크린샷.

테스트 결과 추세(고급) 위젯을 사용하면 테스트 결과에서 이상값을 찾고 다음과 같은 질문에 답변할 수 있습니다. 테스트를 실행하는 데 평소보다 오래 걸리나요? 전체 통과율에 영향을 주는 테스트 파일 또는 파이프라인은 무엇인가요? 장기 실행 테스트란?

이러한 질문에 대답하는 데 도움이 하려면 위젯에서 다음과 같은 기능을 제공합니다.

  • 통과율의 추세와 테스트 결과 또는 테스트 기간 수를 표시합니다.
  • 여러 빌드 파이프라인 또는 릴리스 파이프라인을 기반으로 테스트 결과를 표시합니다.
  • 결합된 차트 옵션을 사용하여 동일한 추세에 대한 두 메트릭 표시
  • 테스트 결과에 따라 시간에 따라 테스트 수를 필터링합니다.
  • 분기 또는 테스트별로 모든 테스트 결과를 필터링합니다.
  • 우선 순위 또는 환경과 같은 테스트 특성별로 메트릭을 쌓습니다.
  • 테스트 파일, 소유자 또는 파이프라인에서 데이터 그룹화

위젯은 매우 구성 가능하여 다양한 시나리오에 사용할 수 있습니다.

URL을 통해 테스트 실행 결과 공유

빌드 또는 릴리스의 일부로 실행하도록 자동화된 테스트를 구성할 수 있습니다. 게시된 테스트 결과는 빌드 또는 릴리스 요약의 테스트 탭에서 볼 수 있습니다. 이 업데이트에서는 단일 테스트 실행 결과를 팀의 다른 사용자와 공유할 수 있도록 결과 복사 URL 기능을 추가했습니다.

공유 수준은 다음과 같습니다.

  • 실행 수준
  • 결과 수준
  • 테스트 실행 내에서 선택한 개별 탭
  • 공유는 구성된 확장 탭과도 호환됩니다.

URL을 공유하면 뷰어의 전체 화면 보기에 테스트 실행 결과가 표시됩니다.

Artifacts

SemVer 2.0.0 버전 번호가 있는 패키지 NuGet

이전에는 Azure Artifacts SemVer 2.0.0 버전 번호가 있는 NuGet 패키지를 지원하지 않았습니다(일반적으로 버전에서 빌드 메타데이터 부분을 포함하는 버전 번호(로 + 표시). 이제 빌드 메타데이터가 포함된 nuget.org 패키지를 저장하고 빌드 메타데이터를 사용하여 사용자 고유의 패키지를 푸시할 수 있습니다. SemVer 사양NuGet.org 정책에따라 빌드 메타데이터를 사용하여 패키지를 주문할 수 없습니다. 따라서 및 를 Azure Artifacts(또는 nuget.org)에 게시할 수 없습니다. 1.0.0+build1 1.0.0+build2 해당 버전은 동등한 버전으로 간주되므로 불변성 제약 조건이 적용됩니다.

패키지에 대한 출처 정보

이 업데이트를 통해 패키지의 출처를 좀 더 쉽게 이해할 수 있습니다. 패키지의 출처는 누가, 무엇을 게시했는지, 어떤 소스 코드 커밋이 제공된 것인지 등입니다. 이 정보는 Azure Pipelines NuGet, npm, MavenTwine Authenticate(Python의 경우) 작업을 사용하여 게시된 모든 패키지에 대해 자동으로 채워집니다.

패키지 사용 통계

지금까지 Azure Artifacts 패키지의 사용량 또는 인기도를 측정하는 방법을 제공하지 않았습니다. 이 업데이트를 통해 패키지 목록 및 패키지 세부 정보 페이지에 다운로드 수와 사용자 수를 추가했습니다. 두 페이지의 오른쪽에서 통계를 볼 수 있습니다.

패키지 사용량 통계의 스크린샷.

Python 패키지 지원

이제 Azure Artifacts Python 패키지를 호스트할 수 있습니다. 즉, 직접 생성하는 패키지와 공용 PyPI에서 저장된 업스트림 패키지가 모두 있습니다. 자세한 내용은 공지 블로그 게시물 및 문서를 참조하세요.

이제 모든 NuGet, npm, Maven 및 Python 패키지를 동일한 피드에 호스트할 수 있습니다.

동일한 피드에서 호스트되는 모든 패키지를 보여 주는 스크린샷.

Maven에 대한 업스트림 원본

이제 Maven 피드에 업스트림 원본을 사용할 수 있습니다. 여기에는 기본 Maven Central 리포지토리 및 Azure Artifacts 피드가 포함됩니다. Maven 업스트림을 기존 피드에 추가하려면 피드 설정을 방문하여 업스트림 원본 피벗 을 선택한 다음, 업스트림 원본 추가를 선택합니다.

업스트림 원본 추가 옵션을 보여주는 스크린샷.

지금까지는 많은 Artifacts 관련 빌드 작업이 Azure Pipelines 프록시 인프라를 완전히 지원하지 않아 온-프레미스 에이전트의 작업을 사용하는 데 어려움이 있었습니다. 이 업데이트를 통해 다음 작업에 프록시에 대한 지원을 추가했습니다.

  • Npm@1 (디자이너의 'npm')
  • NuGetCommand@2(디자이너의 ' NuGet '): 복원 및 푸시 명령만
  • DotNetCoreCLI@2 (디자이너의 ' .NET Core '): 복원 및 nuget 푸시 명령만
  • NpmAuthenticate@0, PipAuthenticate@0 및 TwineAuthenticate@0 (디자이너의 ' [Type] 인증 '): 이러한 작업은 인증 토큰을 획득 하는 동안 프록시를 지원 하지만 프록시를 사용 하도록 후속 작업/스크립트/도구를 구성 해야 합니다. 다른 방법으로, 이러한 작업은 기본 도구 (npm, pip, twine)에 대해 프록시를 구성 하지 않습니다.
  • NuGetToolInstaller@0, NodeTool@0 , DotNetCoreInstaller@0 (디자이너의 ' [type] Installer ')

릴리스에서 지원 되는 모든 Artifacts 패키지 유형

지금 까지는 NuGet 패키지만 Pipelines 릴리스의 Azure Artifacts 아티팩트 형식 에서 지원 됩니다. 이 업데이트를 사용 하면 Maven, npm 및 Python 등의 모든 Azure Artifacts 패키지 유형이 지원 됩니다.

릴리스에 지원 되는 Artifacts 뷰

이전에는 Azure Artifacts 아티팩트 형식은 새 패키지 버전이 피드에 게시 된 경우에만 트리거할 수 있었습니다. 이제 뷰에 대 한 지원도 추가 했으므로 피드에 이미 있는 패키지가 뷰로 승격 된 경우 릴리스를 트리거할 수 있습니다.

보존 정책은 최근에 다운로드 한 패키지를 건너뛸 수 있습니다.

지금까지 Azure Artifacts 피드에는 "패키지 당 최대 버전 수"에 도달할 때 이전 패키지 버전 삭제를 시작 하는 기본 보존 정책이 제공 됩니다. 이 업데이트를 사용 하 여이 정리 작업을 수행할 때 최근에 다운로드 한 패키지를 건너뛰는 기능을 추가 했습니다. 사용 하도록 설정 하려면 피드를 편집 하 고 최근에 다운로드 한 패키지 건너뛰기 확인란을 선택 합니다.

피드를 관리할 수 있는 사람 위임

Project Azure Artifacts에서 pcas ( 컬렉션 관리자 )는 항상 Azure DevOps 서버에서 모든 피드를 관리할 수 있습니다. 이 업데이트를 통해 PCAs는 다른 사용자 및 그룹에이 기능을 제공할 수도 있으므로 피드를 관리 하는 기능을 위임할 수 있습니다.

Wiki

수식 및 비디오에 대 한 Markdown 템플릿

Wiki를 편집할 때 수식, 비디오yaml 태그 를 추가 하기 위한 markdown 구문을 더 이상 기억할 필요가 없습니다. 이제 도구 모음에서 상황에 맞는 메뉴를 클릭 하 고 원하는 옵션을 선택할 수 있습니다.

목차, 비디오, YAML 태그 및 수식과 같은 옵션을 사용 하 여 확장 된 상황에 맞는 메뉴를 보여 주는 스크린샷.

Wiki에 Azure Boards 쿼리 결과 포함

이제 테이블 형식으로 wiki 페이지에 Azure Boards 쿼리 결과를 포함할 수 있습니다. 아래 이미지에서는 해제 된 모든 기능 및 wiki에 포함 된 현재 스 프린트의 모든 활성 버그 목록이 포함 된 wiki 페이지의 샘플을 보여 줍니다. 페이지에 표시 된 콘텐츠는 기존 작업 항목 쿼리를 사용 하 고 있습니다. 이 새로운 기능을 사용 하 여 동적 콘텐츠를 만들 수 있으며 wiki 페이지를 수동으로 업데이트 하는 것에 대해 걱정할 필요가 없습니다.

Wiki에 표시 되는 포함 된 Azure Boards 쿼리 결과의 스크린샷

쿼리 결과는 다음 두 단계로 추가할 수 있습니다.

  1. 편집 도구 모음에서 "쿼리 결과" 단추를 클릭 합니다.

쿼리 결과 옵션이 out 인 확장 된 상황에 맞는 메뉴를 보여 주는 스크린샷

  1. 필요한 쿼리를 선택 하 고 "삽입" 단추를 클릭 합니다.

이제 페이지를 저장 한 후 쿼리 결과를 테이블 형식으로 볼 수 있습니다.

쿼리 결과 대화 상자의 스크린샷

Wiki Markdown 편집기의 고정 폭 글꼴

Wiki Markdown 편집기의 고정 폭 글꼴이 도입 됨에 따라서 가독성은 더 이상 쉽지 않습니다. Markdown 원본은 깨끗 하 고 읽기 쉽게 보입니다. 이 기능은 이 제안 티켓에 따라 우선 순위가 지정 되었습니다.

고정 폭 글꼴이 있는 Wiki의 스크린샷

지금 까지는 연결 된 페이지의 이름이 바뀌었거나 이동 된 경우 공유 Wiki 페이지 링크가 중단 됩니다. 이제 URL에 페이지 Id를 추가 하 여 영구 링크를 도입 했습니다. 이렇게 하면 wiki가 시간에 따라 변경 될 때 공유 하는 링크가 그대로 유지 됩니다.

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

Wiki 페이지에서 작업 항목 상태 표시

이 업데이트에서는 작업 항목의 상태를 페이지에 추가 하 고 해당 ID와 제목을 추가 하 여 Wiki 페이지에서 작업 항목을 향상 시켰습니다.

향상 된 작업 항목 멘 션을 보여 주는 스크린샷

끌어오기 요청 설명 및 Boards 토론의 작업 항목 참조에도 상태가 표시 됩니다.

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

@mention 사용자 및 그룹

이제 @mention wiki 페이지에서 사용자 및 그룹을 사용할 수 있습니다. 이렇게 하면 팀의 연락처 페이지, 지침 문서 및 지식 문서와 같은 문서를 더 다양 하 게 만들 수 있습니다. 아래 이미지는 작업과 작업을 담당 하는 스 프린트 검토를 보여 주는 예입니다.

사용자 및 그룹이 표시 되는 모양을 보여 주는 스크린샷 @mention

또한 wiki 편집 페이지에서 "@"을 입력 하 여 자동 제안에서 사용자 또는 그룹을 선택할 수도 있습니다. 언급 한 사용자는 메일에 의해 알림이 수신 됩니다.

입력을 시작할 때 나타나는 autosuggestions 보여 주는 스크린샷 @mention

마지막으로, 사용자를 클릭 하 여 @mentioned 프로필 정보 카드를 볼 수도 있습니다. 이 기능은 기능 제안에 따라 우선 순위가 지정 되었습니다.

Wiki 페이지에 대 한 알림

지금 까지는 wiki 페이지의 콘텐츠가 변경 된 시기를 알 수 없었습니다. 이제 wiki 페이지를 따라 페이지를 편집, 삭제 또는 이름을 바꾸면 전자 메일을 통해 알림 메시지를 받을 수 있습니다. Wiki에 대 한 변경 내용을 추적 하려면 wiki 페이지에서 다음 단추를 선택 합니다.

out 이라는 Follow 옵션을 사용 하 여 Azure DevOps Wiki 페이지의 스크린샷

이 기능은 제안 티켓에 따라 우선 순위가 지정 되었습니다. 자세히 알아보려면 여기에서 설명서를 참조 하세요.

HTML 태그 지원

이제 HTML 태그를 사용 하 여 wiki에서 더 풍부한 콘텐츠를 만들 수 있습니다. 아래 HTML 태그를 사용 하 여 수행할 수 있는 작업을 확인 하세요.

  1. 이제 세부 정보요약 태그를 사용 하 여 wiki 페이지 내부에 축소 가능한 섹션을 만들 수 있습니다. Open 특성을 추가 하 여 세부 정보를 기본적으로 확장 된 상태로 유지할 수 있습니다.

    세부 정보 및 요약 태그를 사용 하 여 만든 축소 가능한 섹션을 보여 주는 스크린샷

    자세히 태그에 대 한 자세한 내용은 여기에서 설명서를 참조 하세요.

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

    참고

    이 태그는 Edge 및 Internet Explorer 브라우저에서 지원 되지 않습니다.

향상 된 테이블 만들기 및 편집

지금까지 wiki에서 테이블을 만들고 편집 하는 것은 어렵습니다. Wiki에서 테이블을 더 쉽게 추가 하 고 관리할 수 있도록 변경 했습니다.

  1. 표에서 테이블 만들기

    더 이상 markdown 테이블 구문을 기억할 필요가 없습니다. 이제 15 X 15 표를 선택 하 여 markdown 테이블을 쉽게 만들 수 있습니다. 필요한 수의 열과 행을 선택 하 여 한 번의 클릭으로 테이블을 삽입 하면 됩니다.

    표 형식 옵션을 선택 하 여 빈 wiki 페이지를 보여 주는 스크린샷

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

  2. 테이블 가독성 향상

    이제 편집기에서 자동 줄 바꿈을 설정/해제 하 여 테이블의 가독성을 높일 수 있습니다. 자동 줄 바꿈 기능을 사용 하지 않도록 설정 하면 많은 테이블의 내용을 쉽게 볼 수 있는 스크롤 막대가 추가 됩니다.

    자동 줄 바꿈 옵션과 out 이라는 가로 스크롤 막대를 사용 하는 Wiki 페이지의 스크린샷

  3. Autoformating markdown 테이블

    더 이상 markdown 열을 정렬 하기 위해 공백을 추가할 필요가 없습니다. 테이블 서식 단추를 사용 하면 셀에 공백을 추가 하 여 열을 정렬 하 여 markdown 테이블의 서식을 자동으로 지정 합니다. 테이블이 클 경우에는 자동 줄 바꿈 비활성화 와 함께 사용 하 여 테이블을 더 쉽게 읽을 수 있도록 합니다.

    테이블 형식 옵션을 호출한 Wiki 페이지의 스크린샷

    Ctrl + Shift + F 바로 가기를 사용 하 여 테이블의 서식을 지정할 수도 있습니다.

보고

분석을 사용 하는 데 더 이상 필요 하지 않은 분석 확장

분석은 Azure DevOps 환경의 필수적인 부분이 점점 증가 하 고 있습니다. 고객이 데이터 기반 결정을 내리는 데 도움이 되는 중요 한 기능입니다.

업데이트 1에서는 분석을 사용 하기 위해 고객에 게 더 이상 분석 확장 프로그램이 필요 하지 않습니다. 이제 고객은 Project Collection 설정 아래에서 분석을 활성화할 수 있습니다. 이는 제품 내에서 바로 진행 되는 간단한 프로세스입니다.

다음은 고객이 분석을 사용 하도록 설정 하는 방법입니다.

  1. Project Collection 설정로 이동 합니다.

분석 설정을 찾을 수 있는 위치를 보여 주는 스크린샷

  1. 분석 사용 을 클릭 합니다.

분석 사용 옵션을 보여 주는 스크린샷

정말 간단하죠! 컬렉션에 대해 분석 기반 환경이 켜 집니다.

업데이트 1 및 업데이트 된 분석 확장이 설치 된 Azure DevOps Server 2019 컬렉션에서 만든 새 컬렉션은 기본적으로 분석을 사용 하도록 설정 됩니다.

분석 및 사용 환경에 대 한 자세한 내용은 다음을 확인 하세요.


사용자 의견

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


맨 위로 이동