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

아티클
06/11/2024

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

Azure DevOps Server 배포를 설치하거나 업그레이드하는 방법에 대한 자세한 내용은 Azure DevOps Server 요구 사항을 참조 하세요.

Azure DevOps Server 제품을 다운로드하려면 Azure DevOps Server 다운로드 페이지를 방문하세요.

Azure DevOps Server 2022 업데이트 1로의 직접 업그레이드는 Azure DevOps Server 2019 또는 Team Foundation Server 2015 이상에서 지원됩니다. TFS 배포가 TFS 2013 이하에 있는 경우 Azure DevOps Server 2022로 업그레이드하기 전에 몇 가지 중간 단계를 수행해야 합니다. 자세한 내용은 설치 페이지를 참조하세요.

Azure DevOps Server 2022 업데이트 1 패치 4 릴리스 날짜: 2024년 6월 11일

파일	SHA-256 해시
devops2022.1patch4.exe	3A17B4F973A6FA4DE5D0B30C6C87B3C18C885620C683FA1032EC4F6BDB2DA4FB

다음 수정 사항이 포함된 Azure DevOps Server 2022 업데이트 1용 패치 4를 릴리스했습니다.

터키어 로캘 이름에 터키어 "I"가 있는 프로젝트에 대해 검색 결과를 사용할 수 없는 위키 및 작업 항목의 문제를 해결했습니다.

Azure DevOps Server 2022 업데이트 1 패치 3 릴리스 날짜: 2024년 3월 12일

파일	SHA-256 해시
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2022 업데이트 1용 패치 3을 릴리스했습니다.

패치 2를 설치한 후 프록시 서버의 작동이 중지되는 문제를 해결했습니다.
영어가 아닌 언어에 영향을 주는 확장 세부 정보 페이지의 렌더링 문제가 해결되었습니다.

Azure DevOps Server 2022 업데이트 1 패치 2 릴리스 날짜: 2024년 2월 13일

파일	SHA-256 해시
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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

검색 확장 프로그램에서 세부 정보 페이지 렌더링 문제를 수정합니다.
프록시 캐시 폴더에서 사용하는 디스크 공간이 잘못 계산되고 폴더가 제대로 정리되지 않은 버그가 수정되었습니다.
CVE-2024-20667: Azure DevOps Server 원격 코드 실행 취약성.

Azure DevOps Server 2022 업데이트 1 패치 1 릴리스 날짜: 2023년 12월 12일

파일	SHA-256 해시
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

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

파이프라인 실행을 큐에 대기할 때 설정을 requested for 방지합니다.

Azure DevOps Server 2022 업데이트 1 릴리스 날짜: 2023년 11월 28일

참고 항목

이 릴리스에는 두 가지 알려진 문제가 있습니다.

Azure DevOps Server 2022.1로 업그레이드하고 에이전트 풀 구성에서 업데이트 에이전트를 사용한 후에는 에이전트 버전이 업데이트되지 않습니다. 현재 이 문제를 해결하기 위해 패치를 개발 중이며 진행 중인 개발자 커뮤니티에서 업데이트를 공유할 예정입니다. 그 동안 이 개발자 커뮤니티 티켓에서 이 문제에 대한 해결 방법을 찾을 수 있습니다.
Maven 3.9.x 호환성 Maven 3.9.x는 기본 Maven Resolver 전송을 Wagon에서 네이티브 HTTP로 업데이트하여 Azure Artifacts의 호환성이 손상되는 변경 사항을 도입했습니다. 이로 인해 https 대신 http를 사용하는 고객에게 401개의 인증 문제가 발생합니다. 이 문제에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 해결 방법으로 Maven 3.9.x를 속성 -Dmaven.resolver.transport=wagon과 함께 계속 사용할 수 있습니다. 이렇게 변경하면 Maven에서 Wagon Resolver 전송을 사용하도록 강제합니다. 자세한 내용은 여기 설명서를 참조하세요.

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

참고 항목

Maven 3.9.x 호환성에 알려진 문제가 있습니다. Maven 3.9.x는 기본 Maven Resolver 전송을 Wagon에서 네이티브 HTTP로 업데이트하여 Azure Artifacts의 호환성이 손상되는 변경 사항을 도입했습니다. 이로 인해 https 대신 http를 사용하는 고객에게 401개의 인증 문제가 발생합니다. 이 문제에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

해결 방법으로 Maven 3.9.x를 속성 -Dmaven.resolver.transport=wagon과 함께 계속 사용할 수 있습니다. 이렇게 변경하면 Maven에서 Wagon Resolver 전송을 사용하도록 강제합니다. 자세한 내용은 여기 설명서를 참조하세요.

Azure DevOps Server 2022 업데이트 1 RC2 릴리스 날짜: 2023년 10월 31일

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

참고 항목

이 릴리스에서는 다음과 같은 문제가 해결되었습니다.

업스트림 항목이 표시 이름 변경을 해결하지 못하는 로컬 피드의 문제를 해결했습니다.
검색 페이지의 코드에서 다른 탭으로 탭을 전환할 때 예기치 않은 오류가 발생했습니다.
중국어, 일본어 및 한국어(CJK) 통합 Ideographs를 사용하여 새 작업 항목 형식을 만드는 동안 오류가 발생했습니다. 팀 프로젝트 이름 또는 파일에 CJK가 포함된 경우 제어된 체크 인의 RAW 로그에 물음표가 표시되었습니다.
JVM(Java Virtual Machine)이 Elastic Search 프로세스에 충분한 메모리를 할당할 수 없는 Search를 설치하는 동안 문제가 해결되었습니다. 검색 구성 위젯은 이제 Elastic Search와 함께 번들로 제공되는 JDK(Java Development Kit)를 사용하므로 대상 서버에 미리 설치된 JRE(Java 런타임 환경)에 대한 종속성을 제거합니다.

Azure DevOps Server 2022 업데이트 1 RC1 릴리스 날짜: 2023년 9월 19일

Azure DevOps Server 2022.1 RC1에는 많은 새로운 기능이 포함되어 있습니다. 몇 가지 중요한 기능은 다음과 같습니다.

모든 공용 REST API는 세분화된 PAT 범위를 지원합니다.
배달 계획 페이지의 마지막 액세스 열
배달 계획에 대한 모든 종속성 시각화
배달 계획의 @CurrentIteration 매크로
클래식 파이프라인에서 빌드 액세스 토큰의 기본 범위로 설정된 현재 프로젝트
쿼리 결과 위젯에 부모 표시
대시보드 복사
위키 페이지의 추가 다이어그램 유형 지원
이제 Container Registry 서비스 연결에서 Azure 관리 ID를 사용할 수 있습니다.

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

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

일반

모든 공용 REST API는 세분화된 PAT 범위를 지원합니다.

이전에는 공개적으로 문서화된 여러 Azure DevOps REST API가 범위(예: 작업 항목 읽기)와 연결되지 않아 고객이 PAT(개인 액세스 토큰)와 같은 비대화형 인증 메커니즘을 통해 전체 범위를 사용하여 이러한 API를 사용하도록 했습니다. 전체 범위 개인용 액세스 토큰을 사용하면 악의적인 사용자의 손에 맡기면 위험이 높아질 수 있습니다. 이는 많은 고객이 PAT의 사용 및 동작을 제한하기 위해 컨트롤 플레인 정책을 최대한 활용하지 못한 주된 이유 중 하나입니다.

이제 모든 공용 Azure DevOps REST API가 세분화된 PAT 범위와 연결되고 지원됩니다. 현재 전체 범위 PAT를 사용하여 공용 Azure DevOps REST API 중 하나에 인증하는 경우 불필요한 액세스를 방지하기 위해 API에서 허용하는 특정 범위를 사용하여 PAT로 마이그레이션하는 것이 좋습니다. 지정된 REST API에 대해 지원되는 세분화된 PAT 범위는 설명서 페이지의 보안 섹션에서 찾을 수 있습니다. 또한 여기에 범위 테이블이 있습니다.

확장에 해당 범위가 표시되어야 합니다.

Azure DevOps 컬렉션에 확장을 설치할 때 설치의 일부로 확장에 필요한 권한을 검토할 수 있습니다. 그러나 설치되면 확장 권한은 확장 설정에 표시되지 않습니다. 이로 인해 관리자가 설치된 확장을 정기적으로 검토해야 하는 문제가 발생했습니다. 이제 확장 설정을 검토하고 유지할지 여부에 대한 정보에 입각한 결정을 내릴 수 있도록 확장 설정에 확장 권한을 추가했습니다.

Marketplace에 배포할 개인용 액세스 토큰 만들기

Boards

배달 계획 페이지의 마지막 액세스 열

배달 계획 디렉터리 페이지에서는 프로젝트에 대해 정의된 계획 목록을 제공합니다. 이름, 만든 사람, 설명, 마지막으로 구성된 항목 또는 즐겨찾기를 기준으로 정렬할 수 있습니다. 이 업데이트를 통해 디렉터리 페이지에 마지막으로 액세스한 열을 추가했습니다. 이렇게 하면 배달 계획을 마지막으로 열고 살펴본 시기를 볼 수 있습니다. 따라서 더 이상 사용되지 않고 삭제할 수 있는 계획을 쉽게 식별할 수 있습니다.

Gif를 사용하여 배달 계획 페이지에서 마지막으로 액세스한 필드를 데모로 표시합니다.

배달 계획에 대한 모든 종속성 시각화

배달 계획은 항상 작업 항목에서 종속성을 볼 수 있는 기능을 제공했습니다. 종속성 줄을 하나씩 시각화할 수 있습니다. 이 릴리스에서는 화면의 모든 작업 항목에서 모든 종속성 줄을 볼 수 있도록 하여 환경을 개선했습니다. 배달 계획의 오른쪽 위에 있는 종속성 토글 단추를 클릭하기만 하면 됩니다. 다시 클릭하여 선을 끕니다.

Gif를 사용하여 배달 계획 페이지의 모든 종속성을 시각화합니다.

새 작업 항목 수정 제한

지난 몇 년 동안 자동화된 도구를 사용하는 프로젝트 컬렉션은 수만 개의 작업 항목 수정 버전을 생성하는 것을 보았습니다. 이렇게 하면 작업 항목 양식 및 보고 REST API의 성능 및 유용성에 문제가 발생합니다. 이 문제를 완화하기 위해 Azure DevOps Service에 대한 작업 항목 수정 제한인 10,000을 구현했습니다. 이 제한은 작업 항목 양식이 아닌 REST API를 사용하는 업데이트에만 영향을 줍니다.

수정 제한 및 자동화된 도구에서 이를 처리하는 방법에 대해 자세히 알아보려면 여기 를 클릭하세요.

배달 계획 팀 제한을 15에서 20으로 늘입니다.

배달 계획을 사용하면 프로젝트 컬렉션 전체에서 여러 백로그 및 여러 팀을 볼 수 있습니다. 이전에는 여러 프로젝트의 백로그와 팀을 포함하여 15개의 팀 백로그를 볼 수 있습니다. 이 릴리스에서는 최대 한도를 15에서 20으로 늘렸습니다.

보고 작업 항목 링크 Get API의 버그 수정

보고 작업 항목 링크 가져오기 API의 버그를 수정하여 링크 형식에 대한 System.LinkTypes.Remote.Related 올바른 remoteUrl 값을 반환했습니다. 이 수정 전에 잘못된 프로젝트 컬렉션 이름과 누락된 프로젝트 ID를 반환했습니다.

임시 쿼리 REST 엔드포인트 만들기

WIQL(작업 항목 쿼리 언어) 문을 쿼리 문자열을 통해 전달하여 저장되지 않은 쿼리를 실행하려는 확장 작성자의 여러 인스턴스를 확인했습니다. 이는 쿼리 문자열 길이에 대한 브라우저 제한에 도달하는 큰 WIQL 문이 없는 한 잘 작동합니다. 이 문제를 해결하기 위해 도구 작성자가 임시 쿼리를 생성할 수 있도록 새 REST 엔드포인트를 만들었습니다. 응답의 ID를 사용하여 쿼리 문자열을 통해 전달하면 이 문제가 제거됩니다.

임시 쿼리 REST API 설명서 페이지에서 자세히 알아봅니다.

일괄 처리 삭제 API

현재 휴지통에서 작업 항목을 제거하는 유일한 방법은 이 REST API 를 사용하여 한 번에 하나씩 삭제하는 것입니다. 이것은 느린 과정이 될 수 있으며 모든 종류의 대량 정리를 수행하려고 할 때 속도 제한이 적용됩니다. 이에 대한 응답으로 작업 항목을 일괄 처리로 삭제 및/또는 삭제하는 새 REST API 엔드포인트를 추가했습니다.

@CurrentIteration 배달 계획의 매크로

이 업데이트를 통해 배달 계획의 스타일에 대한 @CurrentIteration 매크로 지원이 추가되었습니다. 이 매크로를 사용하면 계획의 각 행에 대한 팀 컨텍스트에서 현재 반복을 가져올 수 있습니다.

배달 계획에서 CurrentIteration 매크로를 데모하는 Gif입니다.

배달 계획의 카드 크기 조정 논리

기능 및 에픽을 추적할 때 모든 사용자가 대상 날짜 및/또는 시작 날짜를 사용하는 것은 아닙니다. 일부는 날짜와 반복 경로의 조합을 사용하도록 선택합니다. 이 릴리스에서는 사용 방법에 따라 반복 경로 및 날짜 필드 조합을 적절하게 설정하도록 논리를 개선했습니다.

예를 들어 대상 날짜가 사용되지 않고 카드 크기를 조정하는 경우 대상 날짜를 업데이트하는 대신 새 반복 경로가 설정됩니다.

Gif를 사용하여 주석 복사 링크를 데모로 복사합니다.

Batch 업데이트 개선 사항

작업 항목 일괄 업데이트 API의 7.1 버전을 몇 가지 변경했습니다. 여기에는 사소한 성능 향상 및 부분 오류 처리가 포함됩니다. 즉, 하나의 패치가 실패하지만 다른 패치가 실패하면 다른 패치가 성공적으로 완료됩니다.

일괄 업데이트 REST API에 대해 자세히 알아보려면 여기 를 클릭하세요.

일괄 처리 삭제 API

일괄 처리로 작업 항목을 삭제 및/또는 삭제하는 이 새로운 REST API 엔드포인트는 이제 공개적으로 사용할 수 있습니다. 자세한 내용은 여기를 클릭하세요.

공유 가능한 선택 목록 필드 편집 방지

사용자 지정 필드는 프로세스 간에 공유됩니다. 프로세스 관리자가 필드에서 값을 추가하거나 제거할 수 있으므로 선택 목록 필드에 문제가 발생할 수 있습니다. 이렇게 하면 변경 내용이 해당 필드를 사용하는 모든 프로세스에서 해당 필드에 영향을 미칩니다.

이 문제를 해결하기 위해 컬렉션 관리자가 필드를 편집하지 못하도록 "잠글" 수 있는 기능을 추가했습니다. 선택 목록 필드가 잠겨 있으면 로컬 프로세스 관리자는 해당 선택 목록의 값을 변경할 수 없습니다. 프로세스에서 필드를 추가하거나 제거할 수 있습니다.

공유 가능한 선택 목록 필드의 데모 편집을 위한 Gif입니다.

새 메모 저장 권한

작업 항목 주석만 저장하는 기능은 개발자 커뮤니티에서 가장 큰 요청이었습니다. 이 기능을 구현했음을 알려드리게 되어 기쁩니다. 시작하려면 가장 일반적인 시나리오를 검토해 보겠습니다.

"일부 사용자가 작업 항목 필드를 편집하는 것을 방지하지만 토론에 참여할 수 있도록 허용하려고 합니다."

이렇게 하려면 프로젝트 설정 > 프로젝트 구성 > 영역 경로로 이동해야 합니다. 그런 다음, 선택한 영역 경로를 선택하고 보안을 클릭합니다.

영역 경로

새 권한 "이 노드에서 작업 항목 주석 편집"을 확인합니다. 기본적으로 사용 권한은 설정되지 않음으로 설정됩니다. 즉, 작업 항목은 이전과 똑같이 동작합니다. 그룹 또는 사용자가 메모를 저장할 수 있도록 하려면 해당 그룹/사용자를 선택하고 사용 권한을 허용으로 변경합니다.

새 권한

사용자가 이 영역 경로에서 작업 항목 양식을 열면 메모를 추가할 수 있지만 다른 필드를 업데이트할 수는 없습니다.

공유 가능한 선택 목록 필드의 데모 편집

우리는 당신이 우리만큼이 기능을 사랑 바랍니다. 언제나처럼 피드백이나 제안이 있는 경우 알려주세요.

대화형 보드 보고서

Boards 허브에 있는 대화형 보고서는 호스트된 버전의 제품에서 몇 년 동안 액세스할 수 있었습니다. 이전 누적 흐름 다이어그램, 속도 및 스프린트 번다운 차트를 대체합니다. 이 릴리스에서는 사용할 수 있습니다.

이러한 차트를 보려면 Kanban 보드, 백로그 및 스프린트 페이지에서 분석 탭 위치를 클릭합니다.

Repos

분기 작성자에 대한 "정책 편집" 권한 제거

이전에는 새 분기를 만들 때 해당 분기에 대한 정책을 편집할 수 있는 권한이 부여되었습니다. 이 업데이트에서는 리포지토리에 대해 "권한 관리" 설정이 켜져 있어도 이 권한을 부여하지 않도록 기본 동작을 변경합니다.

권한 관리 이미지입니다.

사용자는 보안 권한 상속 또는 그룹 멤버 자격을 통해 명시적으로(수동으로 또는 REST API를 통해) 부여받은 "정책 편집" 권한이 필요합니다.

Pipelines

클래식 파이프라인에서 빌드 액세스 토큰의 기본 범위로 설정된 현재 프로젝트

Azure Pipelines는 작업 액세스 토큰을 사용하여 런타임에 Azure DevOps의 다른 리소스에 액세스합니다. 작업 액세스 토큰은 런타임에 각 작업에 대해 Azure Pipelines에서 동적으로 생성되는 보안 토큰입니다. 이전에는 새 클래식 파이프라인을 만들 때 액세스 토큰의 기본값이 Project Collection으로 설정되었습니다. 이 업데이트를 통해 새 클래식 파이프라인을 만들 때 작업 권한 부여 범위를 기본값으로 현재 프로젝트 로 설정합니다.

Access 리포지토리, 아티팩트 및 기타 리소스 설명서에서 작업 액세스 토큰에 대한 자세한 내용을 확인할 수 있습니다.

클래식 빌드 파이프라인에서 액세스 토큰의 기본 범위 변경

클래식 빌드 파이프라인의 보안을 개선하기 위해 새 빌드 파이프라인을 만들 때 빌드 작업 권한 부여 범위는 기본적으로 Project입니다. 지금까지는 프로젝트 컬렉션으로 사용되었습니다. 작업 액세스 토큰에 대해 자세히 알아보세요. 이 변경 내용은 기존 파이프라인에 영향을 주지 않습니다. 이 시점부터 만드는 새 클래식 빌드 파이프라인에만 영향을 줍니다.

ServiceNow의 샌디에이고, 도쿄 및 유타 릴리스에 대한 Azure Pipelines 지원

Azure Pipelines는 ServiceNow와 기존 통합을 가지고 있습니다. 통합은 ServiceNow의 앱과 Azure DevOps의 확장에 의존합니다. 이제 ServiceNow의 샌디에이고, 도쿄 및 유타 버전과 함께 작동하도록 앱을 업데이트했습니다. 이 통합이 작동하는지 확인하려면 ServiceNow 저장소에서 앱의 새 버전(4.215.2)으로 업그레이드합니다.

자세한 내용은 ServiceNow 변경 관리와 통합 설명서를 참조 하세요.

GitHub Enterprise 통합에 프록시 URL 사용

Azure Pipelines는 온-프레미스 GitHub 엔터프라이즈 서버와 통합되어 연속 통합 및 PR 빌드를 실행합니다. 경우에 따라 GitHub Enterprise Server는 방화벽 뒤에 있으며 프록시 서버를 통해 트래픽을 라우팅해야 합니다. 이 시나리오를 지원하기 위해 Azure DevOps의 GitHub Enterprise Server 서비스 연결을 통해 프록시 URL을 구성할 수 있습니다. 이전에는 Azure DevOps의 모든 트래픽이 이 프록시 URL을 통해 라우팅되지 않았습니다. 이 업데이트를 통해 Azure Pipelines에서 다음 트래픽을 라우팅하여 프록시 URL을 통과하도록 합니다.

분기 가져오기
끌어오기 요청 정보 가져오기
보고서 작성 상태

이제 Container Registry 서비스 연결에서 Azure 관리 ID를 사용할 수 있습니다.

Azure Container Registry에 대한 Docker 레지스트리 서비스 연결을 만들 때 시스템 할당 관리 ID를 사용할 수 있습니다. 이렇게 하면 자체 호스팅 Azure Pipelines 에이전트와 연결된 관리 ID를 사용하여 Azure Container Registry에 액세스할 수 있으므로 자격 증명을 관리할 필요가 없습니다.

승인 변경에 대한 새 Docker 레지스트리 서비스 연결

참고 항목

Azure Container Registry에 액세스하는 데 사용되는 관리 ID에는 적절한 AZURE RBAC(역할 기반 액세스 제어) 할당(예: AcrPull 또는 AcrPush 역할)이 필요합니다.

Kubernetes 서비스 연결을 위해 만든 자동 토큰

Kubernetes 1.24 이후 새 Kubernetes 서비스 연결을 만들 때 토큰이 더 이상 자동으로 만들어지지 않습니다. 이 기능을 다시 추가했습니다. 그러나 AKS에 액세스할 때 Azure 서비스 연결을 사용하는 것이 좋습니다. 자세한 내용은 Kubernetes 작업 블로그 게시물을 사용하여 AKS 고객을 위한 서비스 연결 지침을 참조하세요.

Kubernetes 작업은 이제 kubelogin을 지원합니다.

kubelogin을 지원하기 위해 KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 및 AzureFunctionOnKubernetes@1 작업을 업데이트했습니다. 이렇게 하면 Azure Active Directory 통합으로 구성된 AKS(Azure Kubernetes Service)를 대상으로 지정할 수 있습니다.

Kubelogin은 호스트된 이미지에 미리 설치되어 있지 않습니다. 위에서 언급한 작업이 kubelogin을 사용하는지 확인하려면 kubelogin을 사용하는 작업 앞에 KubeloginInstaller@0 작업을 삽입하여 설치합니다.

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

파이프라인 권한에 대한 향상된 환경

파이프라인이 이전에 서비스 연결과 같은 보호된 리소스를 사용했는지를 기억하도록 파이프라인 사용 권한을 관리하는 환경을 개선했습니다.

과거에 보호된 리소스를 만들 때 "모든 파이프라인에 액세스 권한 부여"를 선택했지만 리소스에 대한 액세스를 제한한 경우 파이프라인에 리소스를 사용하기 위한 새 권한 부여가 필요했습니다. 이 동작은 새 권한 부여가 필요하지 않은 리소스에 대한 후속 열기 및 닫기 액세스와 일치하지 않습니다. 이제 해결했습니다.

파이프라인 권한 부여 및 승인 및 검사를 관리하기 위한 새 PAT 범위

PAT 토큰을 누수하여 피해를 제한하기 위해 새 PAT 범위(명명됨 Pipeline Resources)를 추가했습니다. 서비스 연결과 같은 보호된 리소스를 사용하여 파이프라인 권한 부여를 관리하거나 해당 리소스에 대한 승인 및 검사를 관리할 때 이 PAT 범위를 사용할 수 있습니다.

파이프라인 REST API 업데이트

다음 REST API 호출은 다음과 같이 새 PAT 범위를 지원합니다.

승인 지원 범위 업데이트 Pipeline Resources Use
검사 관리에서 범위를 지원합니다. Pipeline Resources Use and Manage
리소스에 대한 파이프라인 권한 업데이트는 범위를 지원합니다. Pipeline Resources Use and Manage
정의 리소스 권한 부여에서 범위를 지원합니다. Pipeline Resources Use and Manage
프로젝트 리소스 권한 부여에서 범위를 지원합니다 . Pipeline Resources Use and Manage

리소스 관리자에게 보호된 리소스 열기 제한

애플리케이션을 안전하게 빌드하고 배포하는 기능에 중요한 리소스의 보안을 개선하기 위해 이제 Azure Pipelines는 모든 파이프라인에 대한 리소스에 대한 액세스를 열 때 리소스 유형 관리자 역할이 필요합니다.

예를 들어 모든 파이프라인이 서비스 연결을 사용하도록 허용하려면 일반 서비스 연결 관리자 역할이 필요합니다. 이 제한은 보호된 리소스를 만들거나 보안 구성을 편집할 때 적용됩니다.

또한 서비스 연결을 만들 때 충분한 권한이 없으면 모든 파이프라인 에 대한 액세스 권한 부여 옵션을 사용할 수 없습니다.

서비스 연결 또한 기존 리소스에 대한 액세스를 열려고 할 때 충분한 권한이 없는 경우 이 리소스 메시지에 대한 액세스를 열 수 있는 권한이 없습니다.

파이프라인 사용 권한

파이프라인 REST API 보안 개선 사항

Azure DevOps의 대부분의 REST API는 범위가 지정된 PAT 토큰을 사용합니다. 그러나 일부 토큰에는 완전히 범위가 지정된 PAT 토큰이 필요합니다. 즉, 이러한 API 중 일부를 사용하려면 '모든 권한'을 선택하여 PAT 토큰을 만들어야 합니다. 이러한 토큰은 REST API를 호출하는 데 사용할 수 있으므로 보안 위험을 초래합니다. 각 REST API를 특정 범위에 통합하여 완전히 범위가 지정된 토큰의 필요성을 제거하기 위해 Azure DevOps에서 개선되었습니다. 이러한 노력의 일환으로 리소스에 대한 파이프라인 권한을 업데이트하는 REST API에는 이제 특정 범위가 필요합니다. 범위는 사용 권한이 부여되는 리소스의 유형에 따라 달라집니다.

Code (read, write, and manage) 형식의 리소스에 대한 repository
Agent Pools (read, manage)또는 Environment (read, manage) 형식 및 리소스의 경우 queueagentpool
Secure Files (read, create, and manage) 형식의 리소스에 대한 securefile
Variable Groups (read, create and manage) 형식의 리소스에 대한 variablegroup
Service Endpoints (read, query and manage) 형식의 리소스에 대한 endpoint
Environment (read, manage) 형식의 리소스에 대한 environment

파이프라인 권한을 대량으로 편집하려면 전체 범위의 PAT 토큰이 필요합니다. 리소스 에 대한 파이프라인 사용 권한을 업데이트하는 방법에 대한 자세한 내용은 파이프라인 사용 권한 - 리소스 에 대한 파이프라인 권한 업데이트 설명서를 참조하세요.

에이전트 풀에 대한 세분화된 액세스 관리

에이전트 풀을 사용하면 파이프라인이 실행되는 컴퓨터를 지정하고 관리할 수 있습니다.

이전에는 사용자 지정 에이전트 풀을 사용한 경우 액세스할 수 있는 파이프라인을 관리하는 것은 거칠게 구성되었습니다. 모든 파이프라인에서 사용하도록 허용하거나 각 파이프라인에 사용 권한을 요청하도록 요구할 수 있습니다. 아쉽게도 에이전트 풀에 대한 파이프라인 액세스 권한을 부여한 후에는 파이프라인 UI를 사용하여 취소할 수 없습니다.

이제 Azure Pipelines는 에이전트 풀에 대한 세분화된 액세스 관리를 제공합니다. 이 환경은 서비스 연결에 대한 파이프라인 사용 권한을 관리하는 환경과 비슷합니다.

승인 변경에 대한 FabrikamFiber 에이전트 풀

보호된 리소스에 대한 모든 파이프라인 액세스 권한 부여 방지

서비스 연결 또는 환경과 같은 보호된 리소스를 만들 때 모든 파이프라인에 대한 액세스 권한 부여 확인란을 선택할 수 있습니다 . 지금까지 이 옵션은 기본적으로 선택되었습니다.

이렇게 하면 파이프라인에서 보호된 새 리소스를 더 쉽게 사용할 수 있지만, 반대로 너무 많은 파이프라인에 리소스에 액세스할 수 있는 권한을 실수로 부여하는 것이 좋습니다.

기본적으로 안전한 선택을 승격하기 위해 Azure DevOps는 이제 확인란을 선택 취소된 상태로 둡니다.

모든 파이프라인에 대한 액세스 권한 부여는 기본적으로 해제됩니다.

짧은 비밀에 대해 마스킹을 사용하지 않도록 설정하는 기능

Azure Pipelines는 로그의 비밀을 마스킹합니다. 비밀은 비밀로 표시된 변수, Azure Key Vault에 연결된 변수 그룹의 변수 또는 서비스 연결 공급자가 비밀로 표시된 서비스 연결의 요소일 수 있습니다.

모든 비밀 값이 마스킹됩니다. 짧은 비밀(예: '', '12', 'Dev')을 마스킹하면 해당 값을 쉽게 추측할 수 있습니다(예:Jan 3, 202*** '').
이제 ''3가 비밀이라는 것이 분명해졌습니다. 이러한 경우 비밀을 완전히 마스킹하지 않는 것을 선호할 수 있습니다. 값을 비밀로 표시할 수 없는 경우(예: Key Vault에서 값을 가져온 경우) 노브를 최대 4의 값으로 설정할 AZP_IGNORE_SECRETS_SHORTER_THAN 수 있습니다.

노드 실행기 다운로드 작업

노드 6 작업 실행기를 제외하는 에이전트 릴리스를 채택할 때 최신 노드 실행 기를 사용하도록 업데이트되지 않은 작업을 가끔 실행해야 할 수 있습니다. 이 시나리오에서는 Node End-of-Life Runner에 종속된 작업을 계속 사용하는 방법을 제공합니다. Node Runner 지침 블로그 게시물을 참조하세요.

아래 작업은 노드 6 실행기를 Just-In-Time으로 설치하는 메서드이므로 이전 작업을 계속 실행할 수 있습니다.

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

업데이트된 TFX 노드 실행기 유효성 검사

태스크 작성자는 TFX(확장 패키징 도구)를 사용하여 확장을 게시합니다. 노드 실행기 버전에서 유효성 검사를 수행하도록 TFX가 업데이트되었습니다. Node Runner 지침 블로그 게시물을 참조하세요.

노드 6 실행기를 사용하는 작업이 포함된 확장에는 다음 경고가 표시됩니다.

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

파이프라인 에이전트에 노드 6을 수동으로 사전 설치하기 위한 지침

에이전트 피드를 사용하는 경우 에이전트에 pipeline- 노드 6이 포함되지 않습니다. Marketplace 작업이 여전히 노드 6에 종속되고 에이전트가 NodeTaskRunnerInstaller 작업을 사용할 수 없는 경우(예: 연결 제한으로 인해) 노드 6을 독립적으로 사전 설치해야 합니다. 이렇게 하려면 Node 6 실행기를 수동으로 설치하는 방법에 대한 지침을 확인하세요.

파이프라인 작업 변경 로그

이제 이 변경 로그에 파이프라인 작업에 대한 변경 내용을 게시합니다. 여기에는 기본 제공 파이프라인 작업에 대한 전체 변경 목록이 포함되어 있습니다. 이전 내용 사항을 소급하여 게시했으므로 변경 로그는 작업 업데이트 기록을 제공합니다.

릴리스 작업에서 Microsoft Graph API 사용

Microsoft Graph API를 사용하도록 릴리스 작업을 업데이트했습니다. 이렇게 하면 작업에서 AAD Graph API 사용이 제거됩니다.

Windows PowerShell 작업 성능 향상

작업을 사용하여 파이프라인에서 자동화를 정의할 수 있습니다. 이러한 작업 중 하나는 파이프라인에서 PowerShell@2 PowerShell 스크립트를 실행할 수 있는 유틸리티 작업입니다. PowerShell 스크립트를 사용하여 Azure 환경을 대상으로 지정하려면 이 작업을 사용할 AzurePowerShell@5 수 있습니다. 예를 들어 Invoke-WebRequest진행률 업데이트를 인쇄할 수 있는 일부 PowerShell 명령은 이제 더 빠르게 실행됩니다. 스크립트에 이러한 명령이 많거나 장기 실행 중인 경우 개선이 더 중요합니다. 이 업데이트를 progressPreference 사용하면 이제 작업 및 AzurePowerShell@5 작업의 PowerShell@2 속성이 기본적으로 설정 SilentlyContinue 됩니다.

.NET 6의 파이프라인 에이전트 v3

파이프라인 에이전트가 런타임으로 .NET 3.1 Core를 .NET 6으로 사용하도록 업그레이드되었습니다. 이것은 애플 실리콘뿐만 아니라 Windows Arm64에 대한 기본 지원을 소개합니다.

.NET 6을 사용하면 에이전트의 시스템 요구 사항에 영향을 줍니다. 특히 CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6 운영 체제에 대한 지원을 중단합니다. 에이전트 소프트웨어 버전 3의 설명서를 참조하세요.

이 스크립트 를 사용하여 지원되지 않는 운영 체제에서 에이전트를 사용하는 파이프라인을 식별할 수 있습니다.

Important

.NET 6 기반 에이전트를 롤아웃하면 위의 운영 체제에서 실행되는 에이전트가 더 이상 업데이트되거나 실패하지 않습니다.

에이전트 VM 확장에서 에이전트 버전 지정

Azure VM은 VM 확장을 사용하여 배포 그룹에 포함할 수 있습니다. 필요에 따라 설치할 원하는 에이전트 버전을 지정하도록 VM 확장이 업데이트되었습니다.

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

클래식 파이프라인 만들기를 제어하는 새 토글

이제 Azure DevOps를 사용하면 클래식 빌드 파이프라인, 클래식 릴리스 파이프라인, 작업 그룹 및 배포 그룹을 만들지 않도록 설정하여 프로젝트 컬렉션에서 YAML 파이프라인만 사용할 수 있도록 할 수 있습니다. 기존 클래식 파이프라인은 계속 실행되며 편집할 수 있지만 새 파이프라인을 만들 수는 없습니다.

이제 Azure DevOps를 사용하면 클래식 빌드 파이프라인, 클래식 릴리스 파이프라인, 작업 그룹 및 배포 그룹을 만들지 않도록 설정하여 조직에서 YAML 파이프라인만 사용할 수 있도록 할 수 있습니다. 기존 클래식 파이프라인은 계속 실행되며 편집할 수 있지만 새 파이프라인을 만들 수는 없습니다.

해당 토글을 켜면 프로젝트 컬렉션 수준 또는 프로젝트 수준에서 클래식 파이프라인 만들기를 사용하지 않도록 설정할 수 있습니다. 토글은 프로젝트/프로젝트 설정 - 파이프라인 ->> 설정에서 찾을 수 있습니다. 두 개의 토글이 있습니다. 하나는 클래식 빌드 파이프라인용이고 다른 하나는 클래식 릴리스 파이프라인, 배포 그룹 및 작업 그룹용입니다.

클래식 파이프라인 만들기 사용 안 함

토글 상태는 기본적으로 해제되어 있으며 상태를 변경하려면 관리자 권한이 필요합니다. 토글이 조직 수준에서 설정되면 모든 프로젝트에 대해 사용하지 않도록 설정이 적용됩니다. 그렇지 않으면 각 프로젝트에서 비활성화를 적용할지 여부를 자유롭게 선택할 수 있습니다.

클래식 파이프라인 만들기를 사용하지 않도록 설정하면 클래식 파이프라인, 작업 그룹 및 배포 그룹 만들기와 관련된 REST API가 실패합니다. YAML 파이프라인을 만드는 REST API가 작동합니다.

"실행 단계 상태 변경됨" 서비스 후크 이벤트에 대한 업데이트

서비스 후크를 사용하면 Azure DevOps 의 프로젝트에서 이벤트가 발생할 때 다른 서비스에서 작업을 실행할 수 있습니다. 실행 단계 상태가 변경된 것은 이러한 이벤트 중 하나입니다. 실행 단계 상태 변경 이벤트에는 파이프라인 이름을 포함하여 실행에 대한 정보가 포함되어야 합니다. 이전에는 실행의 ID 및 이름에 대한 정보만 포함했습니다. 이 업데이트를 통해 누락된 정보를 포함하도록 이벤트를 변경했습니다.

파이프라인 실행에 대한 마지막 커밋 메시지 표시 안 함

이전에는 파이프라인 실행을 표시할 때 마지막 커밋 메시지 표시하는 데 파이프라인 UI를 사용했습니다.

마지막 커밋 메시지 예

예를 들어 YAML 파이프라인의 코드가 빌드하는 코드를 보유하는 리포지토리와 다른 리포지토리에 있는 경우 이 메시지는 혼동될 수 있습니다. 모든 파이프라인 실행의 타이틀에 최신 커밋 메시지 추가하거나 사용하지 않도록 설정하는 방법을 묻는 개발자 커뮤니티의 피드백을 들었습니다.

이 업데이트를 통해 정확하게 수행할 수 있는 새 YAML 속성인 이름이 appendCommitMessageToRunName추가되었습니다. 기본적으로 속성은 .로 설정됩니다 true. 이 값을 false설정하면 파이프라인 실행에서 . BuildNumber만 표시됩니다.

빌드 번호가 있는 파이프라인 실행의 예

마지막 커밋 메시지 사용하여 파이프라인 실행의 예

ARM(4MB 최대 Azure Resource Manager) 템플릿 크기에 맞게 Azure Pipeline 제한이 증가했습니다.

Azure Resource Manager 템플릿 배포 작업을 사용하여 Azure 인프라를 만들 수 있습니다. 피드백에 따라 Azure Pipelines 통합 제한이 2MB에서 4MB로 증가했습니다. 이렇게 하면 큰 템플릿을 통합하는 동안 크기 제약 조건을 해결하는 ARM 템플릿의 최대 크기인 4MB 에 맞춥니다.

파이프라인 실행 상태 개요 아이콘

이 릴리스에서는 파이프라인 실행의 전반적인 상태를 더 쉽게 알 수 있습니다.

단계가 많은 YAML 파이프라인의 경우 파이프라인 실행 상태를 알기 어려웠습니다. 즉, 여전히 실행 중이거나 완료되었습니다. 완료된 경우 전체 상태는 성공, 실패 또는 취소됨입니다. 실행 상태 개요 아이콘을 추가하여 이 문제를 해결했습니다.

파이프라인 단계 측면 패널

YAML 파이프라인에는 수십 개의 단계가 있을 수 있으며 모든 단계가 화면에 맞지는 않습니다. 파이프라인 실행 개요 아이콘은 실행의 전체 상태를 알려주지만, 실패한 단계 또는 아직 실행 중인 스테이지를 알기는 여전히 어렵습니다.

이 릴리스에서는 모든 스테이지의 상태를 빠르게 볼 수 있는 파이프라인 스테이지 사이드 패널을 추가했습니다. 그런 다음 스테이지를 클릭하고 해당 로그로 직접 가져올 수 있습니다.

파이프라인 업데이트

파이프라인 UI 업데이트

측면 패널에서 스테이지 검색

스테이지 쪽 패널에서 찾고 있는 스테이지를 더 쉽게 찾을 수 있습니다. 이제 상태(예: 실행 단계 또는 수동 개입이 필요한 단계)에 따라 스테이지를 빠르게 필터링할 수 있습니다. 해당 이름으로 스테이지를 검색할 수도 있습니다.

AZ 파이프라인 업데이트

빠른 작업 스테이징

파이프라인의 실행 화면을 사용하면 모든 실행 단계에 빠르게 액세스할 수 있습니다. 이 릴리스에서는 각 단계에 대해 작업을 수행할 수 있는 단계 패널을 추가했습니다. 예를 들어 실패한 작업을 쉽게 다시 실행하거나 전체 단계를 다시 실행할 수 있습니다. 다음 스크린샷에서 볼 수 있듯이 모든 단계가 사용자 인터페이스에 맞지 않는 경우 패널을 사용할 수 있습니다.

단계가 너무 많은 파이프라인의 스크린샷 스테이지 열에서 '+' 기호를 클릭하면 스테이지 패널이 표시되고 스테이지 작업을 수행할 수 있습니다.

스테이지 패널의 스크린샷.

사용자 환경 개선 사항 확인

검사 로그를 더 쉽게 읽을 수 있도록 하고 있습니다. 검사 로그는 배포 성공에 중요한 정보를 제공합니다. 작업 항목 티켓을 닫는 것을 잊었는지 또는 ServiceNow에서 티켓을 업데이트해야 하는지 알 수 있습니다. 이전에는 검사가 이러한 중요한 정보를 제공했다는 것을 아는 것은 어려웠습니다.

이제 파이프라인 실행 세부 정보 페이지에 최신 확인 로그가 표시됩니다. 이는 권장 사용량을 따르는 검사에만 해당합니다.

최신 검사 로그를 보여 주는 이미지입니다. 실수로 승인된 승인을 방지하기 위해 Azure DevOps는 승인에 승인자에게지침을 표시하고 파이프라인 실행의 세부 정보 페이지에서 측면 패널을 확인합니다.

파이프라인 검토 이미지를 기다리고 있습니다.

확인 사용 안 함

디버깅 검사를 덜 지루하게 만들었습니다. 경우에 따라 Azure 함수 호출 또는 REST API 호출 확인이 제대로 작동하지 않아 수정해야 합니다. 이전에는 이러한 검사를 삭제하여 배포를 잘못 차단하지 않도록 해야 했습니다. 검사를 수정한 후에는 다시 추가하고 올바르게 구성하여 필요한 모든 헤더가 설정되거나 쿼리 매개 변수가 올바른지 확인해야 했습니다. 이것은 지루합니다.

이제 검사를 사용하지 않도록 설정할 수 있습니다. 비활성화된 검사는 후속 검사 도구 모음 평가에서 실행되지 않습니다.

확인 이미지를 사용하지 않도록 설정합니다. 잘못된 검사를 수정한 후에는 사용하도록 설정할 수 있습니다.

확인 이미지를 사용하도록 설정합니다.

파이프라인 실행 Rest API에서 사용된 리소스 및 템플릿 매개 변수

확장 된 파이프라인 실행 REST API 는 이제 파이프라인 실행에 사용되는 더 많은 형식의 아티팩트와 해당 실행을 트리거하는 데 사용되는 매개 변수를 반환합니다. 파이프라인 실행에 사용되는 리소스 및 pipeline 템플릿 매개 변수를 반환 container 하도록 API를 향상시켰습니다. 예를 들어 이제 파이프라인에서 사용하는 리포지토리, 컨테이너 및 기타 파이프라인 실행을 평가하는 준수 검사를 작성할 수 있습니다.

다음은 새 응답 본문의 예입니다.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

YAML 편집기에서 일반 공급 템플릿 지원

템플릿은 YAML 파이프라인에서 일반적으로 사용되는 기능입니다. 파이프라인 조각을 쉽게 공유할 수 있습니다. 또한 파이프라인을 통해 보안 및 거버넌스를 확인하거나 적용하는 강력한 메커니즘입니다.

Azure Pipelines는 YAML 편집기를 지원하므로 파이프라인을 편집할 때 유용할 수 있습니다. 그러나 편집기에서는 지금까지 템플릿을 지원하지 않았습니다. YAML 파이프라인의 작성자는 템플릿을 사용할 때 intellisense를 통해 지원을 받을 수 없습니다. 템플릿 작성자가 YAML 편집기를 사용할 수 없습니다. 이 릴리스에서는 YAML 편집기에서 템플릿에 대한 지원을 추가합니다.

기본 Azure Pipelines YAML 파일을 편집할 때 템플릿을 포함하거나 확장할 수 있습니다. 템플릿의 이름을 입력하면 템플릿의 유효성을 검사하라는 메시지가 표시됩니다. 유효성이 검사되면 YAML 편집기에서 입력 매개 변수를 포함하여 템플릿의 스키마를 이해합니다.

파이프라인 REST API 업데이트

유효성 검사 후 템플릿으로 이동하도록 선택할 수 있습니다. YAML 편집기의 모든 기능을 사용하여 템플릿을 변경할 수 있습니다.

알려진 제한 사항은 다음과 같습니다.

템플릿에 기본 YAML 파일에 입력으로 제공되지 않는 필수 매개 변수가 있는 경우 유효성 검사가 실패하고 해당 입력을 제공하라는 메시지가 표시됩니다. 이상적인 환경에서 유효성 검사를 차단하면 안 되며 intellisense를 사용하여 입력 매개 변수를 채울 수 있어야 합니다.
편집기에서 새 템플릿을 만들 수 없습니다. 기존 템플릿만 사용하거나 편집할 수 있습니다.

미리 정의된 새 시스템 변수

빌드 파이프라인 정의의 폴더 경로인 새 미리 정의된 시스템 변수 Build.DefinitionFolderPath를 도입했습니다. 이 변수는 YAML 및 클래식 빌드 파이프라인 모두에서 사용할 수 있습니다.

예를 들어 파이프라인이 Azure Pipelines의 FabrikamFiber\Chat 폴더 아래에 있는 경우 값 Build.DefinitionFolderPath 은 다음과 같습니다 FabrikamFiber\Chat.

YAML 템플릿 식에서 문자열 분할 함수에 대한 지원 추가

YAML 파이프라인은 개체의 목록 또는 속성 값을 반복하는 등 코드 중복을 each 줄이는 편리한 방법을 제공합니다.

반복할 항목 집합이 문자열로 표시되는 경우도 있습니다. 예를 들어 배포할 환경 목록이 문자열 integration1, integration2에 의해 정의되는 경우입니다.

개발자 커뮤니티의 피드백을 들으면서 YAML 템플릿 식에서 문자열 split 함수를 원한다는 소식을 들었습니다.

이제 문자열을 만들고 해당 부분 문자열을 반복할 each 수 split 있습니다.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

리포지토리 리소스 정의의 템플릿 식

YAML 파이프라인에서 리소스의 repository 속성을 정의할 ref 때 템플릿 식에 대한 지원을 추가했습니다. 개발자 커뮤니티에서 매우 많이 요청한 기능입니다.

파이프라인이 동일한 리포지토리 리소스의 다른 분기를 체크 아웃하도록 하려는 경우 사용 사례가 있습니다.

예를 들어 자체 리포지토리를 빌드하는 파이프라인이 있다고 가정하고 이를 위해 리소스 리포지토리에서 라이브러리를 체크 아웃해야 합니다. 또한 파이프라인이 자체에서 사용 중인 것과 동일한 라이브러리 분기를 체크 아웃하도록 하려는 경우를 가정해 보겠습니다. 예를 들어 파이프라인이 main 분기에서 실행되는 경우 라이브러리 리포지토리의 분기를 체크 아웃 main 해야 합니다. 파이프라인이 분기에서 dev 실행되는 경우 라이브러리 분기를 dev 체크 아웃해야 합니다.

지금까지 체크 아웃할 분기를 명시적으로 지정하고 분기가 변경될 때마다 파이프라인 코드를 변경해야 했습니다.

이제 템플릿 식을 사용하여 리포지토리 리소스의 분기를 선택할 수 있습니다. 파이프라인의 기본이 아닌 분기에 사용할 YAML 코드의 다음 예제를 참조하세요.

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

파이프라인을 실행할 때 리포지토리에 체크 아웃할 분기를 library 지정할 수 있습니다.

빌드 큐 타임에 확장할 템플릿의 버전 지정

템플릿은 코드 중복을 줄이고 파이프라인의 보안을 개선하는 좋은 방법을 나타냅니다.

인기 있는 사용 사례 중 하나는 자체 리포지토리에 템플릿을 보관하는 것입니다. 이렇게 하면 템플릿과 템플릿을 확장하는 파이프라인 간의 결합이 줄어들고 템플릿과 파이프라인을 독립적으로 더 쉽게 발전시킬 수 있습니다.

다음 예제에서는 템플릿을 사용하여 단계 목록의 실행을 모니터링합니다. 템플릿 코드는 리포지토리에 Templates 있습니다.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

리포지토리에 있는 이 템플릿을 확장하는 YAML 파이프라인이 있다고 가정해 FabrikamFiber보겠습니다. 지금까지는 리포지토리를 템플릿 원본으로 사용할 때 리포지토리 리소스의 templates 속성을 동적으로 지정할 ref 수 없었습니다. 즉, 파이프라인을 실행한 분기에 관계없이 다른 분기에서 템플릿을 확장하여 파이프라인과 동일한 분기 이름에서 템플릿을 확장하도록 파이프라인 코드를 변경해야 했습니다.

리포지토리 리소스 정의에 템플릿 식이 도입되면 다음과 같이 파이프라인을 작성할 수 있습니다.

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

이렇게 하면 파이프라인이 실행되는 분기와 동일한 분기에서 템플릿을 확장하므로 파이프라인과 템플릿의 분기가 항상 일치하는지 확인할 수 있습니다. 즉, 분기dev에서 파이프라인을 실행하는 경우 리포지토리의 분기에서 dev 파일에 지정된 template.yml 템플릿을 templates 확장합니다.

또는 다음 YAML 코드를 작성하여 빌드 큐 타임에 사용할 템플릿 리포지토리 분기를 선택할 수 있습니다.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

이제 분기 main 의 파이프라인이 한 실행의 분기 dev 에서 템플릿을 확장하고 파이프라인의 코드를 변경하지 않고 다른 실행의 분기 main 에서 템플릿을 확장하도록 할 수 있습니다.

리포지토리 리소스의 속성에 대한 ref 템플릿 식을 지정할 때는 미리 정의된 변수 및 시스템을 사용할 parameters 수 있지만 YAML 또는 Pipelines UI 정의 변수는 사용할 수 없습니다.

컨테이너 리소스 정의의 템플릿 식

YAML 파이프라인에서 리소스의 , volumes및 portsoptions 속성을 container 정의할 endpoint때 템플릿 식에 대한 지원을 추가했습니다. 개발자 커뮤니티에서 매우 많이 요청한 기능입니다.

이제 다음과 같이 YAML 파이프라인을 작성할 수 있습니다.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

템플릿 식에서 사용할 parameters.variables. 수 있습니다. 변수의 경우 YAML 파일에 정의된 변수만 사용할 수 있지만 파이프라인 UI에 정의된 변수는 사용할 수 없습니다. 예를 들어 에이전트 로그 명령을 사용하여 변수를 다시 정의하면 아무런 영향을 주지 않습니다.

예약된 빌드 개선 사항

파이프라인의 일정 정보가 손상되고 파이프라인이 로드되지 않는 문제를 해결했습니다. 예를 들어 분기 이름이 특정 개수의 문자를 초과했을 때 발생합니다.

파이프라인을 로드하지 못한 경우 오류 메시지 개선

Azure Pipelines는 파이프라인 시작 방법을 구성하는 여러 유형의 트리거를 제공합니다. 파이프라인을 실행하는 한 가지 방법은 예약된 트리거를 사용하는 것입니다. 경우에 따라 파이프라인의 예약된 실행 정보가 손상되어 부하가 실패할 수 있습니다. 이전에는 파이프라인을 찾을 수 없다고 주장하는 잘못된 오류 메시지가 표시되었습니다. 이 업데이트를 통해 이 문제를 해결하고 정보 오류 메시지를 반환합니다. 앞으로 파이프라인이 로드되지 않으면 빌드 일정 데이터가 손상됨과 비슷한 메시지가 표시됩니다.

Git 리포지토리를 가져올 때 태그 동기화 안 함

체크 아웃 작업은 Git 리포지토리의 콘텐츠를 가져오는 옵션을 사용합니다--tags. 이렇게 하면 서버는 모든 태그와 해당 태그가 가리키는 모든 개체를 가져옵니다. 이렇게 하면 파이프라인에서 작업을 실행하는 시간이 늘어나며, 특히 많은 태그가 있는 큰 리포지토리가 있는 경우 더 많은 시간이 소요됩니다. 또한 체크 아웃 작업은 단순 인출 옵션을 사용하도록 설정해도 태그를 동기화하므로 용도가 무용지물이 될 수 있습니다. Git 리포지토리에서 가져오거나 가져온 데이터의 양을 줄이기 위해 이제 태그 동기화 동작을 제어하는 새 옵션을 작업에 추가했습니다. 이 옵션은 클래식 및 YAML 파이프라인 모두에서 사용할 수 있습니다.

YAML
클래식

이 동작은 YAML 파일 또는 UI에서 제어할 수 있습니다.

YAML 파일을 통해 태그 동기화를 옵트아웃하려면 체크 아웃 단계에 추가 fetchTags: false 합니다. fetchTags 옵션을 지정하지 않으면 사용되는 경우 fetchTags: true 와 동일합니다.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

기존 YAML 파이프라인의 동작을 변경하려는 경우 YAML 파일을 업데이트하는 대신 UI에서 이 옵션을 설정하는 것이 더 편리할 수 있습니다. UI로 이동하려면 파이프라인에 대한 YAML 편집기를 열고 트리거, 프로세스 및 체크 아웃 단계를 선택합니다.

YAML 파일과 UI 모두에서 이 설정을 지정하면 YAML 파일에 지정된 값이 우선합니다.

만드는 모든 새 파이프라인(YAML 또는 클래식)의 경우 태그는 기본적으로 여전히 동기화됩니다. 이 옵션은 기존 파이프라인의 동작을 변경하지 않습니다. 위에서 설명한 대로 옵션을 명시적으로 변경하지 않는 한 태그는 해당 파이프라인에서 계속 동기화됩니다.

Artifacts

업데이트된 기본 피드 권한

이제 프로젝트 컬렉션 빌드 서비스 계정은 현재 기여자 역할 대신 새 프로젝트 컬렉션 범위 Azure Artifacts 피드를 만들 때 기본적으로 협력자 역할을 갖게 됩니다.

업스트림 패키지 검색을 위한 새 사용자 인터페이스

이전에는 피드의 복사본이 있는 경우 업스트림 패키지를 볼 수 있었습니다. 문제는 업스트림에서 사용할 수 있고 피드에 아직 저장되지 않은 패키지를 검색할 수 없다는 점이었습니다. 이제 새 피드 사용자 인터페이스를 사용하여 사용 가능한 업스트림 패키지를 검색할 수 있습니다.

이제 Azure Artifacts는 업스트림 원본에서 패키지를 검색하고 패키지 버전을 피드에 저장할 수 있는 사용자 인터페이스를 제공합니다. 이는 제품 및 서비스를 개선하기 위한 Microsoft의 목표와 일치합니다.

보고

이제 쿼리 결과 위젯은 부모의 이름과 해당 부모에 대한 직접 링크를 지원합니다.

Marketplace에 배포할 개인용 액세스 토큰 만들기

대시보드 복사

이 릴리스에서는 대시보드 복사를 포함합니다.

대시보드에 마지막으로 액세스한 날짜 및 수정한 날짜

팀이 여러 대시보드를 만들 수 있도록 하는 과제 중 하나는 오래되고 사용되지 않는 대시보드를 관리하고 정리하는 것입니다. 대시보드를 마지막으로 방문하거나 수정한 시기를 아는 것은 제거할 수 있는 대시보드를 이해하는 데 중요한 부분입니다. 이 릴리스에서는 대시보드 디렉터리 페이지에 두 개의 새 열을 포함했습니다. 마지막으로 액세스한 날짜 는 대시보드가 가장 최근에 방문한 시기를 추적합니다. 수정 기준 은 대시보드가 마지막으로 편집된 시기와 대상을 추적합니다.

수정된 정보도 대시보드 페이지 자체에 표시됩니다.

이러한 새 필드를 통해 프로젝트 관리자가 대시보드를 제거할지 여부를 결정할 수 있는 활동 수준을 이해할 수 있기를 바랍니다.

이제 분석 보기를 사용할 수 있습니다.

분석 뷰 기능은 호스트된 제품 버전에서 오랜 시간 동안 미리 보기 상태로 유지되었습니다. 이 릴리스를 통해 이제 모든 프로젝트 컬렉션에서 이 기능을 사용할 수 있음을 알려드리겠습니다.

탐색에서 분석 보기가 개요 탭에서 보드 탭으로 이동되었습니다.

분석 뷰는 분석 데이터를 기반으로 Power BI 보고서에 대한 필터 조건을 지정하는 간소화된 방법을 제공합니다. 분석 뷰에 익숙하지 않은 경우 다음 몇 가지 설명서를 참조하세요.

여러 리포지토리에 대한 끌어오기 요청 위젯을 Azure DevOps Server 2022.1에서 사용할 수 있다는 사실을 발표하게 되어 기쁩니다. 이 새로운 위젯을 사용하면 간소화된 단일 목록에서 최대 10개의 다른 리포지토리에서 끌어오기 요청을 쉽게 볼 수 있으므로 그 어느 때보다 쉽게 끌어오기 요청을 유지할 수 있습니다.

커뮤니티 제안 티켓

번다운 및 번업 차트에서 완료된 것으로 확인된 소개

차트에서 완료된 것으로 확인된 항목을 포함하여 팀 진행 상황을 정확하게 반영하는 것이 중요하다는 것을 이해합니다. 간단한 토글 옵션을 사용하면 이제 확인된 항목을 완료된 상태로 표시하도록 선택하여 팀의 번다운 상태를 정확하게 반영할 수 있습니다. 이러한 향상된 기능을 통해 보다 정확한 추적 및 계획을 수립할 수 있으므로 팀은 실제 진행 상황에 따라 정보에 입각한 의사 결정을 내릴 수 있습니다. 보고에서 업데이트된 번다운 및 번업 차트를 사용하여 향상된 투명성과 더 나은 인사이트를 경험하세요.

데모에 대한 Gif는 번다운 및 번업 차트에서 완료된 것으로 확인됩니다.

Wiki

위키 페이지의 추가 다이어그램 유형 지원

위키 페이지에 사용되는 인어 차트 버전을 8.13.9로 업그레이드했습니다. 이 업그레이드를 통해 이제 Azure DevOps 위키 페이지에 다음 다이어그램 및 시각화를 포함할 수 있습니다.

순서도
시퀀스 다이어그램
Gantt 차트
원형 차트
요구 사항 다이어그램
상태 다이어그램
사용자 경험

엔터티 관계 및 Git 그래프와 같은 실험적 모드에 있는 다이어그램은 포함되지 않습니다. 새 기능에 대한 자세한 내용은 인어 릴리스 정보를 참조하세요.

피드백

많은 의견 부탁드립니다! 문제를 보고하거나 아이디어를 제공하고 개발자 커뮤니티를 통해 추적하고 Stack Overflow에 대한 조언을 얻을 수 있습니다.

맨 위로 이동

다음을 통해 공유

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

Azure DevOps Server 2022 업데이트 1 패치 4 릴리스 날짜: 2024년 6월 11일

Azure DevOps Server 2022 업데이트 1 패치 3 릴리스 날짜: 2024년 3월 12일

Azure DevOps Server 2022 업데이트 1 패치 2 릴리스 날짜: 2024년 2월 13일

Azure DevOps Server 2022 업데이트 1 패치 1 릴리스 날짜: 2023년 12월 12일

Azure DevOps Server 2022 업데이트 1 릴리스 날짜: 2023년 11월 28일

Azure DevOps Server 2022 업데이트 1 RC2 릴리스 날짜: 2023년 10월 31일

Azure DevOps Server 2022 업데이트 1 RC1 릴리스 날짜: 2023년 9월 19일

일반

모든 공용 REST API는 세분화된 PAT 범위를 지원합니다.

확장에 해당 범위가 표시되어야 합니다.

Boards

배달 계획 페이지의 마지막 액세스 열

배달 계획에 대한 모든 종속성 시각화

새 작업 항목 수정 제한

배달 계획 팀 제한을 15에서 20으로 늘입니다.

보고 작업 항목 링크 Get API의 버그 수정

임시 쿼리 REST 엔드포인트 만들기

일괄 처리 삭제 API

@CurrentIteration 배달 계획의 매크로

배달 계획의 카드 크기 조정 논리

Batch 업데이트 개선 사항

일괄 처리 삭제 API

공유 가능한 선택 목록 필드 편집 방지

새 메모 저장 권한

대화형 보드 보고서

Repos

분기 작성자에 대한 "정책 편집" 권한 제거

Pipelines

클래식 파이프라인에서 빌드 액세스 토큰의 기본 범위로 설정된 현재 프로젝트

클래식 빌드 파이프라인에서 액세스 토큰의 기본 범위 변경

ServiceNow의 샌디에이고, 도쿄 및 유타 릴리스에 대한 Azure Pipelines 지원

GitHub Enterprise 통합에 프록시 URL 사용

이제 Container Registry 서비스 연결에서 Azure 관리 ID를 사용할 수 있습니다.

Kubernetes 서비스 연결을 위해 만든 자동 토큰

Kubernetes 작업은 이제 kubelogin을 지원합니다.

파이프라인 권한에 대한 향상된 환경

파이프라인 권한 부여 및 승인 및 검사를 관리하기 위한 새 PAT 범위

리소스 관리자에게 보호된 리소스 열기 제한

파이프라인 REST API 보안 개선 사항

에이전트 풀에 대한 세분화된 액세스 관리

보호된 리소스에 대한 모든 파이프라인 액세스 권한 부여 방지

짧은 비밀에 대해 마스킹을 사용하지 않도록 설정하는 기능

노드 실행기 다운로드 작업

업데이트된 TFX 노드 실행기 유효성 검사

파이프라인 에이전트에 노드 6을 수동으로 사전 설치하기 위한 지침

파이프라인 작업 변경 로그

릴리스 작업에서 Microsoft Graph API 사용

Windows PowerShell 작업 성능 향상

.NET 6의 파이프라인 에이전트 v3

에이전트 VM 확장에서 에이전트 버전 지정

클래식 파이프라인 만들기를 제어하는 새 토글

"실행 단계 상태 변경됨" 서비스 후크 이벤트에 대한 업데이트

파이프라인 실행에 대한 마지막 커밋 메시지 표시 안 함

ARM(4MB 최대 Azure Resource Manager) 템플릿 크기에 맞게 Azure Pipeline 제한이 증가했습니다.

파이프라인 실행 상태 개요 아이콘

파이프라인 단계 측면 패널

측면 패널에서 스테이지 검색

빠른 작업 스테이징

사용자 환경 개선 사항 확인

확인 사용 안 함

파이프라인 실행 Rest API에서 사용된 리소스 및 템플릿 매개 변수

YAML 편집기에서 일반 공급 템플릿 지원

미리 정의된 새 시스템 변수

YAML 템플릿 식에서 문자열 분할 함수에 대한 지원 추가

리포지토리 리소스 정의의 템플릿 식

빌드 큐 타임에 확장할 템플릿의 버전 지정

컨테이너 리소스 정의의 템플릿 식

예약된 빌드 개선 사항

파이프라인을 로드하지 못한 경우 오류 메시지 개선

Git 리포지토리를 가져올 때 태그 동기화 안 함

Artifacts

업데이트된 기본 피드 권한

업스트림 패키지 검색을 위한 새 사용자 인터페이스

보고

쿼리 결과 위젯에 부모 표시

대시보드 복사

대시보드에 마지막으로 액세스한 날짜 및 수정한 날짜

이제 분석 보기를 사용할 수 있습니다.