Azure DevOps Server 2022 릴리스 정보

아티클
11/14/2023

| | Developer Community시스템 요구 사항 및 호환성 | 사용 조건 | DevOps 블로그 | SHA-256 해시 |

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

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

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

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

Azure DevOps Server 2022 업데이트 0.1 패치 5 릴리스 날짜: 2023년 11월 14일

참고

Azure DevOps Server 패치는 누적됩니다. 패치 3을 설치하지 않은 경우 이 패치에는 Azure Pipelines 에이전트에 대한 업데이트가 포함됩니다. 패치 5를 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

파일	SHA-256 해시
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

셸 작업 사용 인수 매개 변수 유효성 검사에 대해 PowerShell 작업 허용 문자 목록을 확장했습니다.
취소 단추를 클릭한 후 서비스 연결 편집이 영구적으로 발생하는 문제를 해결합니다.

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

참고

Azure DevOps Server 패치는 누적됩니다. 패치 3을 설치하지 않은 경우 이 패치에는 Azure Pipelines 에이전트에 대한 업데이트가 포함됩니다. 패치 5를 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

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

파이프라인 실행 모델을 업그레이드하여 파이프라인이 중단되는 버그가 수정되었습니다.
패치 업그레이드 컴퓨터에서 "분석 소유자" ID가 비활성 ID로 표시되는 버그가 수정되었습니다.
빌드 정리 작업에는 여러 작업이 포함되며, 각 작업은 빌드에 대한 아티팩트를 삭제합니다. 이러한 작업이 실패하면 후속 작업이 실행되지 않습니다. 작업 오류를 무시하고 가능한 한 많은 아티팩트 클린 위해 이 동작을 변경했습니다.

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

참고

이 패치에는 Azure Pipelines 에이전트에 대한 업데이트가 포함됩니다. 패치 3을 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

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

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

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

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

CVE-2023-36869: 스푸핑 취약성을 Azure DevOps Server.
큰 메타데이터 XML 응답에 대해 ArithmeticException을 발생할 수 있는 SOAP 호출의 버그가 수정되었습니다.
구성 요소 해제 시 엔드포인트 상태가 플러시되도록 서비스 연결 편집기 변경 내용이 구현되었습니다.
markdown 파일에서 상대 링크가 작동하지 않는 문제를 해결했습니다.
많은 수의 태그가 정의되어 있는 경우 애플리케이션 계층과 관련된 성능 문제를 정상 시작 시간보다 오래 걸리는 문제를 해결했습니다.
에이전트 풀 페이지에서 TF400367 오류를 해결했습니다.
분석 소유자 ID가 비활성 ID로 표시되는 버그가 수정되었습니다.
CronScheduleJobExtension에서 무한 루프 버그가 수정되었습니다.

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

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

CVE-2023-21565: Azure DevOps Server 스푸핑 취약성.
CVE-2023-21569: Azure DevOps Server 스푸핑 취약성.
서비스 연결 편집기가 있는 버그가 수정되었습니다. 이제 구성 요소 해제 시 엔드포인트 상태 초안이 플러시됩니다.
분리 또는 연결 컬렉션이 다음 오류를 보고하지 못하는 버그를 수정했습니다. 'TF246018: 데이터베이스 작업이 제한 시간을 초과하여 취소되었습니다.

Azure DevOps Server 2022 업데이트 0.1 릴리스 날짜: 2023년 5월 9일

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

Azure DevOps Server 2022 업데이트 0.1 RC 릴리스 날짜: 2023년 4월 11일

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

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

보안 취약성을 해결하기 위해 GVFS(Git Virtual File System)를 에서 v2.39.1.1-micorosoft.2로 업그레이드했습니다.
테스트 데이터가 삭제되지 않아 데이터베이스가 증가했습니다. 이 수정을 통해 새 분리 테스트 데이터를 만들지 못하도록 빌드 보존을 업데이트했습니다.
AnalyticCleanupJob에 업데이트 작업 상태 중지되었고 이제 성공이 보고되었습니다.
"지정된 키가 사전에 없음" 오류로 "tfx 확장 게시" 명령이 실패하는 문제를 해결했습니다.
팀 일정 확장에 액세스하는 동안 및 오류를 해결하기 위한 해결 방법을 구현했습니다.
CVE-2023-21564: 사이트 간 스크립팅 취약성 Azure DevOps Server
CVE-2023-21553: 원격 코드 실행 취약성 Azure DevOps Server
Visual Studio 2022를 지원하도록 MSBuild 및 VSBuild 작업이 업데이트되었습니다.
XSS 공격 벡터를 방지하기 위해 재인증을 로드하는 방법론을 업데이트합니다.
Azure DevOps Server 2022 프록시는 다음 오류를 보고합니다. VS800069: 이 서비스는 온-프레미스 Azure DevOps에서만 사용할 수 있습니다.
웹 UI를 통한 선반 접근성 문제를 해결했습니다.
Azure DevOps Server 관리 콘솔에서 SMTP 관련 설정을 업데이트한 후 tfsjobagent 서비스를 다시 시작하고 애플리케이션 풀을 Azure DevOps Server 문제를 해결했습니다.
만료 날짜 7일 전에 PAT에 대한 알림이 전송되지 않았습니다.

Azure DevOps Server 2022 패치 4 릴리스 날짜: 2023년 6월 13일

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

CVE-2023-21565: Azure DevOps Server 스푸핑 취약성.
CVE-2023-21569: Azure DevOps Server 스푸핑 취약성.
서비스 연결 편집기가 있는 버그가 수정되었습니다. 이제 구성 요소 해제 시 엔드포인트 상태 초안이 플러시됩니다.
분리 또는 연결 컬렉션이 다음 오류를 보고하지 못하는 버그를 수정했습니다. 'TF246018: 데이터베이스 작업이 제한 시간을 초과하여 취소되었습니다.

Azure DevOps Server 2022 패치 3 릴리스 날짜: 2023년 3월 21일

2022년 Azure DevOps Server 대한 패치(19.205.33506.1)를 릴리스했습니다. 여기에는 다음의 수정 사항이 포함되어 있습니다.

Azure DevOps Server 관리 콘솔에서 SMTP 관련 설정을 업데이트한 후 tfsjobagent 서비스를 다시 시작하고 애플리케이션 풀을 Azure DevOps Server 문제를 해결했습니다.
엔드포인트 상태를 참조로 전달하는 대신 서비스 엔드포인트 편집 패널에 복사합니다.
이전에는 서비스 연결을 편집할 때 취소 단추를 선택한 후 편집이 UI에 유지되었습니다. 이 패치를 통해 팀에서 알림 배달이 배달 안 됨으로 설정된 경우 알림 SDK에서 수정했습니다. 이 시나리오에서 알림 구독이 팀 기본 설정 배달 옵션으로 구성된 경우 팀 구성원은 알림을 받지 않습니다. 구성원의 기본 설정을 검사 위해 팀에서 ID를 더 확장할 필요가 없습니다.

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

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

CVE-2023-21564: 사이트 간 스크립팅 취약성 Azure DevOps Server
Visual Studio 2022를 지원하도록 MSBuild 및 VSBuild 작업이 업데이트되었습니다.
가능한 XSS 공격 벡터를 방지하기 위해 재인증 로드 방법론을 업데이트합니다.
Azure DevOps Server 2022 프록시는 다음 오류를 보고합니다. VS800069: 이 서비스는 온-프레미스 Azure DevOps에서만 사용할 수 있습니다.

Azure DevOps Server 2022 패치 1 릴리스 날짜: 2023년 1월 24일

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

테스트 데이터가 삭제되지 않아 데이터베이스가 증가했습니다. 이 수정을 통해 새 고아 테스트 데이터를 만들지 못하도록 빌드 보존을 업데이트했습니다.
AnalyticCleanupJob에 업데이트 작업 상태 중지되었으며 이제 성공으로 보고됩니다.
"지정된 키가 사전에 없음" 오류로 "tfx 확장 게시" 명령이 실패하는 문제를 해결했습니다.
팀 일정 확장에 액세스하는 동안 및 오류를 해결하기 위한 해결 방법을 구현했습니다.

Azure DevOps Server 2022 릴리스 날짜: 2022년 12월 6일

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

Azure DevOps Server 2022 RC2 릴리스 날짜: 2022년 10월 25일

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

참고

새 SSH RSA 알고리즘 사용

이전에 지원했던 SHA1 SSH-RSA 외에도 SHA2 공개 키 유형을 지원하도록 RSA 공개 키 지원이 개선되었습니다.

이제 지원되는 공개 키 유형은 다음과 같습니다.

SSH-RSA
RSA-SHA2-256
RSA-SHA2-512

작업 필요

파일에 명시적으로 지정하여 SSH-RSA를 .ssh/config1 사용하도록 설정하는 작업을 구현한 경우 를 제거 PubkeyAcceptedTypes하거나 RSA-SHA2-256 또는 RSA-SHA2-512 또는 둘 다를 사용하도록 수정해야 합니다. 암호를 GIT_SSH_COMMAND="ssh -v" git fetch 묻는 메시지가 표시되고 여기에 설명서에 상호 서명 알고리즘이 표시되지 않는 경우 수행할 작업에 대한 세부 정보를 찾을 수 있습니다.

타원형 키 지원은 아직 추가되지 않았으며 백로그에서 매우 요청이 많은 기능으로 남아 있습니다.

Azure DevOps Server 2022 RC1 릴리스 날짜: 2022년 8월 9일

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

중요

웨어하우스 및 분석 서비스는 이전 버전의 Azure DevOps Server(2020)에서 더 이상 사용되지 않습니다. 2022년 Azure DevOps Server 웨어하우스 및 분석 서비스가 제품에서 제거되었습니다. 이제 Analytics는 제품 내 보고 환경을 제공합니다.

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

배달 계획
커밋 링크에 올바른 가상 사용자 표시
파이프라인의 환경 변수에 대한 새 컨트롤
포크 빌드에 대한 무제한 토큰 생성
새 TFVC 페이지
차트 위젯에서 사용할 수 있는 그룹화 기준 태그

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

Boards
Repos
파이프라인
보고

Boards

배달 계획

이제 배달 계획이 Azure DevOps Server 포함되어 있음을 발표하게 되어 기쁩니다. 배달 계획은 3가지 주요 시나리오를 제공합니다.

계획의 타임라인 보기
작업 진행률
종속성 추적

다음은 기본 기능입니다. 필터링, 표식 및 필드 조건도 배달 계획의 일부입니다.

기본 보기에는 압축 및 확장의 두 가지가 있습니다.

배달 계획 2.0을 사용하면 시작 및 대상 날짜 또는 반복 날짜를 사용하여 타임라인 계획의 모든 작업 항목을 볼 수 있습니다. 우선 순위는 대상 날짜에 & 다음 반복으로 시작됩니다. 이렇게 하면 반복에 정의되지 않는Epic과 같은 포트폴리오 수준 작업 항목을 추가할 수 있습니다.

압축된 뷰와 확장된 뷰에는 두 개의 기본 보기가 있습니다. 계획의 오른쪽에 있는 돋보기를 클릭하여 계획을 확대 및 축소할 수도 있습니다.

압축된 뷰와 확장된 뷰에는 두 개의 기본 보기가 있습니다. 계획의 오른쪽에 있는 돋보기를 클릭하여 계획을 확대 및 축소할 수도 있습니다.

압축된 보기

압축된 보기에는 축소된 모든 작업 항목 카드가 표시되므로 모든 카드 정보가 표시되지는 않습니다. 이 보기는 계획에서 작업의 전체 보기에 유용합니다. 카드 필드를 축소하려면 계획의 오른쪽에 있는 돋보기 아이콘 옆에 있는 카드 아이콘을 클릭합니다.

다음은 압축된 뷰와 확장된 뷰 간에 전환하는 계획의 예입니다.
확장된 보기

확장된 보기는 자식 및 연결된 항목의 수를 계산하고 완료 비율을 보여 줌으로써 작업 항목의 진행률을 보여줍니다. 현재 진행률은 작업 항목 수에 따라 결정됩니다.

다음은 확장된 보기를 사용하는 계획의 예입니다. 진행률 표시줄 및 완료 백분율을 확인합니다.

종속성 추적

종속성 추적은 작업 항목에 정의된 선행 및 후속 링크를 기반으로 합니다. 이러한 링크가 정의되지 않으면 종속성 줄이 표시되지 않습니다. 작업 항목에 종속성 문제가 있는 경우 종속성 링크 아이콘은 빨간색으로 표시됩니다.

종속성을 표시하기 위해 종속성 아이콘이 빨간색으로 표시된 종속성 추적

종속성 보기

특정 종속성은 방향을 포함하여 해당 작업 항목에 대한 모든 종속성을 보여 주는 종속성 패널을 통해 볼 수 있습니다. 빨간색 느낌표는 종속성 문제를 나타냅니다. 패널을 표시하려면 카드 오른쪽 위 모서리에 있는 종속성 링크 아이콘을 클릭하기만 하면 됩니다. 다음은 종속성의 예입니다.
종속성 선

작업 항목 간의 종속성은 각 작업 항목 사이의 방향 화살표 선으로 시각화됩니다. 여러 종속성이 여러 줄로 표시됩니다. 빨간색 선은 문제를 나타냅니다.

다음은 몇 가지 예제입니다.

다음은 여러 종속성이 있는 작업 항목의 예이며 압축된 뷰를 사용하여 작동합니다.

문제가 발생하면 선 색이 빨간색이며 종속성 아이콘도 마찬가지입니다.

다음은 예제입니다.

카드 스타일 지정

이제 Kanban 보드와 같은 규칙을 사용하여 카드의 스타일을 지정할 수 있습니다. 계획 설정을 열고 스타일을 클릭합니다. 스타일 창에서 + 스타일 지정 규칙 추가 를 클릭하여 규칙을 추가한 다음 저장을 클릭합니다. 최대 10개의 규칙이 있을 수 있으며 각 규칙에는 최대 5개의 절이 있을 수 있습니다.

스타일 설정

이전

이전 카드 스타일 지정

After

카드 스타일 지정 후

배달 계획에 대해 자세히 알아보려면 여기에서 설명서를 검사.

작업 항목 허브에서 제거된 항목

작업 항목 허브는 사용자가 만들었거나 사용자에게 할당된 항목 목록을 볼 수 있는 위치입니다. 작업 항목 나열을 간소화하기 위해 여러 개인 설정된 피벗 및 필터 기능을 제공합니다. 나에게 할당된 피벗의 가장 큰 불만 중 하나는 제거된 작업 항목을 표시한다는 것입니다. 제거된 작업 항목은 더 이상 가치가 없으며 백로그에 있으면 안 된다는 데 동의합니다. 이 스프린트에서는 작업 항목 허브의 할당된 항목 보기에서 제거된 모든 항목을 숨기려고 합니다.

커밋 링크에 올바른 가상 사용자 표시

작업 항목의 개발 섹션 에는 관련 커밋 및 끌어오기 요청 목록이 표시됩니다. 연결된 시간과 함께 커밋 또는 끌어오기 요청의 작성자를 볼 수 있습니다. 이 업데이트를 통해 작성자의 아바타가 보기에 잘못 표시되는 문제를 해결했습니다.

작업 항목 기록에서 삭제된 첨부 파일을 다운로드하는 기능 제거

양식에서 첨부 파일이 제거된 후에도 사용자가 작업 항목 기록에서 첨부 파일을 다운로드할 수 있는 작은 문제를 해결했습니다. 이제 첨부 파일이 제거되면 기록에서 다운로드할 수 없으며 REST API 응답에서 다운로드 URL을 사용할 수도 없습니다.

버그 이유 필드에 "수정 안 함" 값이 추가됨

다른 모든 작업 항목 유형과 마찬가지로 버그 작업 항목 유형에는 잘 정의된 워크플로가 있습니다. 각 워크플로는 3개 이상의 상태와 이유로 구성됩니다. 이유는 항목이 한 상태에서 다른 상태로 전환된 이유를 지정합니다. 이 업데이트를 통해 Agile 프로세스에서 버그 작업 항목 유형에 대한 이유 값을 수정하지 않음 을 추가했습니다. 이 값은 버그를 새로 만들기 또는 활성에서 해결됨으로 이동할 때 원인으로 사용할 수 있습니다. Azure Boards 설명서에서 소프트웨어 버그를 정의, 캡처, 심사 및 관리하는 방법에 대해 자세히 알아볼 수 있습니다.

Pipelines

클래식 빌드에서 파이프라인별 보존 정책 제거

이제 Azure DevOps 프로젝트 설정에서 클래식 빌드 및 YAML 파이프라인 모두에 대한 보존 정책을 구성할 수 있습니다. 클래식 빌드 파이프라인에 대한 파이프라인별 보존 규칙은 더 이상 지원되지 않습니다. YAML 파이프라인에 대한 보존을 구성하는 유일한 방법이지만 파이프라인별로 클래식 빌드 파이프라인에 대한 보존을 구성할 수도 있습니다. 예정된 릴리스에서 클래식 빌드 파이프라인에 대한 파이프라인별 보존 규칙을 모두 제거했습니다.

이것이 의미하는 바: 파이프라인별 보존 규칙을 사용하던 모든 클래식 빌드 파이프라인은 프로젝트 수준 보존 규칙에 따라 관리됩니다.

업그레이드할 때 빌드가 손실되지 않도록 하려면 업그레이드 시 임대가 없는 모든 빌드에 대한 임대를 만듭니다.

업그레이드 후 프로젝트 수준 보존 설정을 검사 것이 좋습니다. 파이프라인에 특히 사용자 지정 규칙이 필요한 경우 파이프라인에서 사용자 지정 작업을 사용할 수 있습니다. 작업을 통해 보존 임대를 추가하는 방법에 대한 자세한 내용은 빌드, 릴리스 및 테스트에 대한 보존 정책 설정 설명서를 참조하세요.

파이프라인의 환경 변수에 대한 새 컨트롤

Azure Pipelines 에이전트는 표준 출력에서 특수 로깅 명령을 검사하고 실행합니다. 명령을setVariable 사용하여 변수를 설정하거나 이전에 정의된 변수를 수정할 수 있습니다. 이는 잠재적으로 시스템 외부의 행위자가 악용할 수 있습니다. 예를 들어 파이프라인에 ftp 서버의 파일 목록을 인쇄하는 단계가 있는 경우 ftp 서버에 액세스할 수 있는 사용자가 새 파일을 추가할 수 있습니다. 이 파일에는 명령에 명령이 포함되어 setVariable 파이프라인의 동작이 변경됩니다.

파이프라인에서 로깅 명령을 사용하여 변수를 설정하는 데 의존하는 많은 사용자가 있습니다. 이 릴리스에서는 명령의 원치 않는 사용 위험을 줄이기 위해 다음과 같이 변경합니다 setVariable .

작업 작성자를 위한 새 구문을 추가했습니다. 에 다음과 같은 코드 조각을 포함하면 태스크 작성자는 태스크에 task.json의해 변수가 설정되었는지 제어할 수 있습니다.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}

또한 악용할 수 없도록 ssh와 같은 여러 기본 제공 작업을 업데이트하고 있습니다.
마지막으로 이제 YAML 구문을 사용하여 단계가 변수를 설정할 수 있는지 여부를 제어할 수 있습니다.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

포크 빌드에 대한 무제한 토큰 생성

GitHub Enterprise 사용자는 일반적으로 포크를 사용하여 업스트림 리포지토리에 기여합니다. Azure Pipelines가 GitHub Enterprise 리포지토리의 포크에서 기여 빌드하는 경우 작업 액세스 토큰에 부여된 권한을 제한하고 이러한 작업에서 파이프라인 비밀에 액세스하는 것을 허용하지 않습니다. 빌드 포크의 보안에 대한 자세한 내용은 설명서에서 확인할 수 있습니다.

이는 사용자가 내부 소스 공동 작업 모델의 혜택을 계속 누릴 수 있는 이러한 닫힌 환경에서 원하는 것보다 더 제한적일 수 있습니다. 포크에 비밀을 사용할 수 있도록 파이프라인에서 설정을 구성할 수 있지만 작업 액세스 토큰 scope 제어하는 설정은 없습니다. 이 릴리스에서는 포크 빌드에 대해서도 일반 작업 액세스 토큰을 생성할 수 있는 제어를 제공합니다.

파이프라인 편집기에서 트리거 에서 이 설정을 변경할 수 있습니다. 이 설정을 변경하기 전에 이 구성을 사용하도록 설정하면 보안에 미치는 영향을 완전히 이해해야 합니다.

포크 빌드에 대한 무제한 토큰 생성

YAML 파이프라인에서 보호된 리소스로 리포지토리

각각 자체 Azure DevOps Git 리포지토리 및 하나 이상의 파이프라인을 사용하여 여러 하위 프로젝트를 호스트하도록 Azure DevOps 프로젝트를 구성할 수 있습니다. 이 구조에서는 어떤 파이프라인이 어떤 리포지토리에 액세스할 수 있는지 제어할 수 있습니다. 예를 들어 동일한 프로젝트에 두 개의 리포지토리 A와 B가 있고 일반적으로 이러한 리포지토리를 빌드하는 두 개의 파이프라인 X와 Y가 있다고 가정해 보겠습니다. 파이프라인 Y가 리포지토리 A에 액세스하지 못하도록 방지할 수 있습니다. 일반적으로 A의 기여자가 액세스를 제공할 파이프라인을 제어하려고 합니다.

이는 Azure Git 리포지토리 및 파이프라인에서 부분적으로 가능하지만 관리 경험이 없었습니다. 이 기능은 해당 간격을 해결합니다. 이제 Azure Git 리포지토리는 서비스 연결 및 에이전트 풀과 마찬가지로 YAML 파이프라인에서 보호된 리소스 로 처리될 수 있습니다.

리포지토리 A의 기여자 리포지토리에 검사 및 파이프라인 권한을 추가할 수 있습니다. 이렇게 하려면 프로젝트 설정으로 이동하고 리포지토리를 선택한 다음 리포지토리를 선택합니다. "Checks"라는 새 메뉴가 표시됩니다. 여기서는 기본 제공 또는 사용자 지정 검사를 Azure 함수 형식으로 구성할 수 있습니다.

검사 추가

"보안" 탭에서 리포지토리에 액세스할 수 있는 파이프라인 목록을 관리할 수 있습니다.

보안 탭에서 파이프라인 목록 관리

YAML 파이프라인이 리포지토리를 사용할 때마다 Azure Pipelines 인프라는 모든 검사 및 권한이 충족되는지 확인하고 확인합니다.

참고

이러한 권한 및 검사는 YAML 파이프라인에만 적용됩니다. 클래식 파이프라인은 이러한 새로운 기능을 인식하지 않습니다.

변수 그룹 및 보안 파일에 대한 권한 및 검사

YAML 파이프라인에서 다양한 유형의 공유 리소스를 사용할 수 있습니다. 예를 들어 서비스 연결, 변수 그룹, 보안 파일, 에이전트 풀, 환경 또는 리포지토리가 있습니다. 파이프라인이 리소스에 액세스하지 못하도록 보호하기 위해 리소스 소유자는 권한을 구성하고 해당 리소스에 대한 검사를 수행할 수 있습니다. 파이프라인이 리소스에 액세스하려고 할 때마다 구성된 모든 권한과 검사가 평가됩니다. 이러한 보호는 잠시 동안 서비스 연결, 환경 및 에이전트 풀에서 사용할 수 있습니다. 최근에 리포지토리에 추가되었습니다. 이 릴리스에서는 변수 그룹 및 보안 파일에 동일한 보호를 추가합니다.

변수 그룹 또는 보안 파일에 대한 액세스를 작은 파이프라인 집합으로 제한하려면 파이프라인 권한 기능을 사용합니다.

내 비밀 변수

파이프라인이 실행될 때마다 평가해야 하는 검사 또는 승인을 구성하려면 승인 및 라이브러리 검사 기능을 사용합니다.

검사 승인 추가

환경 자동 만들기의 변경 내용

YAML 파이프라인을 작성하고 존재하지 않는 환경을 참조하면 Azure Pipelines가 자동으로 환경을 만듭니다. 이 자동 생성은 사용자 컨텍스트 또는 시스템 컨텍스트에서 발생할 수 있습니다. 다음 흐름에서 Azure Pipelines는 작업을 수행하는 사용자에 대해 알고 있습니다.

Azure Pipelines 웹 환경에서 YAML 파이프라인 만들기 마법사를 사용하고 아직 만들어지지 않은 환경을 참조합니다.
Azure Pipelines 웹 편집기를 사용하여 YAML 파일을 업데이트하고 존재하지 않는 환경에 대한 참조를 추가한 후 파이프라인을 저장합니다. 위의 각 경우에서 Azure Pipelines는 작업을 수행하는 사용자를 명확하게 이해합니다. 따라서 환경을 만들고 사용자를 환경의 관리자 역할에 추가합니다. 이 사용자에게는 환경을 관리하거나 환경을 관리하기 위한 다양한 역할에 다른 사용자를 포함할 수 있는 모든 권한이 있습니다.

다음 흐름에서 Azure Pipelines에는 환경을 만드는 사용자에 대한 정보가 없습니다. 다른 외부 코드 편집기를 사용하여 YAML 파일을 업데이트하고, 존재하지 않는 환경에 대한 참조를 추가한 다음, 연속 통합 파이프라인이 트리거됩니다. 이 경우 Azure Pipelines는 사용자에 대해 알지 못합니다. 이전에는 환경의 관리자 역할에 모든 프로젝트 기여자를 추가하여 이 사례를 처리했습니다. 그러면 프로젝트의 모든 구성원이 이러한 권한을 변경하고 다른 사용자가 환경에 액세스하지 못하도록 할 수 있습니다.

프로젝트의 모든 구성원에게 환경에 대한 관리자 권한을 부여하는 것에 대한 피드백을 받았습니다. 사용자의 의견을 들어보면서 작업을 수행하는 사용자가 누구인지 명확하지 않은 경우 환경을 자동으로 만들어서는 안 된다고 들었습니다. 이 릴리스에서는 환경을 자동으로 만드는 방법을 변경했습니다.

앞으로 파이프라인 실행은 환경이 존재하지 않고 사용자 컨텍스트를 알 수 없는 경우 환경을 자동으로 만들지 않습니다. 이러한 경우 파이프라인은 환경을 찾을 수 없음 오류로 실패합니다. 파이프라인에서 사용하기 전에 올바른 보안으로 환경을 미리 만들고 구성을 확인해야 합니다.
알려진 사용자 컨텍스트가 있는 파이프라인은 이전과 마찬가지로 환경을 자동으로 만듭니다.
마지막으로, 환경을 자동으로 만드는 기능은 Azure Pipelines 시작 프로세스를 간소화하기 위해 추가되었습니다. 프로덕션 시나리오가 아닌 테스트 시나리오를 위한 것이었습니다. 항상 올바른 권한 및 검사를 사용하여 프로덕션 환경을 미리 만든 다음 파이프라인에서 사용해야 합니다.

빌드 파이프라인에서 Insights 대화 상자 제거

피드백에 따라 빌드 파이프라인을 탐색할 때 표시되는 작업/파이프라인 인사이트 대화 상자가 제거되어 워크플로를 개선합니다. 필요한 인사이트를 얻을 수 있도록 파이프라인 분석을 계속 사용할 수 있습니다.

단독 잠금 검사를 사용하는 경우에만 최신이 아닌 순차 배포 지원

YAML 파이프라인에서 검사는 보호된 리소스에 대한 단계 실행을 제어하는 데 사용됩니다. 사용할 수 있는 일반적인 검사 중 하나는 전용 잠금 검사. 이 검사 파이프라인에서 한 번만 실행할 수 있습니다. 여러 실행이 동시에 환경에 배포하려고 하면 검사 모든 이전 실행을 취소하고 최신 실행을 배포하도록 허용합니다.

이전 실행을 취소하는 것은 릴리스가 누적되고 이전 실행의 모든 코드 변경 내용을 포함하는 경우에 좋은 방법입니다. 그러나 코드 변경이 누적되지 않는 일부 파이프라인이 있습니다. 이 새로운 기능을 사용하면 모든 실행이 환경에 순차적으로 진행 및 배포되도록 허용하거나 이전 실행을 취소하고 최신 실행만 허용하는 이전 동작을 유지하도록 선택할 수 있습니다. 파이프라인 YAML 파일에서 라는 lockBehavior 새 속성을 사용하여 이 동작을 지정할 수 있습니다. 값은 sequential 모든 실행이 보호된 리소스에 대한 잠금을 순차적으로 획득한다는 것을 의미합니다. 값은 runLatest 최신 실행만 리소스에 대한 잠금을 획득한다는 것을 의미합니다.

배포 또는 runLatest에서 배타적 잠금 검사 sequential 사용하려면 다음 단계를 수행합니다.

환경(또는 다른 보호된 리소스)에서 배타적 잠금 검사 사용하도록 설정합니다.
파이프라인에 대한 YAML 파일에서 라는 lockBehavior새 속성을 지정합니다. 전체 파이프라인 또는 지정된 단계에 대해 지정할 수 있습니다.

스테이지에서 설정:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

파이프라인에서 다음을 설정합니다.

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

를 지정 lockBehavior하지 않으면 로 간주됩니다 runLatest.

퀘벡 버전의 ServiceNow 지원

Azure Pipelines에는 ServiceNow와 기존 통합이 있습니다. 통합은 ServiceNow의 앱 과 Azure DevOps의 확장 에 의존합니다. 이제 퀘벡 버전의 ServiceNow와 함께 작동하도록 앱을 업데이트했습니다. 클래식 및 YAML 파이프라인은 이제 퀘벡에서 작동합니다. 이 통합이 작동하는지 확인하려면 Service Now 저장소에서 앱의 새 버전(4.188.0)으로 업그레이드합니다. 자세한 내용은 ServiceNow 변경 관리와 통합을 참조하세요.

새 YAML 조건식

YAML 파일에서 조건식을 작성하면 및 ${{ elseif }} 식을 더 쉽게 사용할 ${{ else }} 수 있습니다. 다음은 YAML 파이프라인 파일에서 이러한 식을 사용하는 방법의 예입니다.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

경로 필터에서 와일드카드 지원

와일드카드 는 파이프라인 YAML 파일에서 CI 또는 PR 트리거에 대한 포함 및 제외 분기를 지정할 때 사용할 수 있습니다. 그러나 경로 필터를 지정할 때는 사용할 수 없습니다. instance 경우 일치하는 src/app/**/myapp*모든 경로를 포함할 수 없습니다. 이는 여러 고객이 불편을 끼쳐 드려서 지적되었습니다. 이 업데이트는 이 간격을 채웁니다. 이제 경로 필터를 지정할 때 야생 카드 문자(**, *또는 ?)를 사용할 수 있습니다.

파이프라인의 기본 에이전트 사양은 Windows-2022입니다.

이미지는 windows-2022 Azure Pipelines Microsoft 호스팅 에이전트에서 레이블의 windows-latest 기본 버전이 될 준비가 된 것입니다. 지금까지 이 레이블은 windows-2019 에이전트를 가리켰습니다. 이 변경 내용은 1월 17일부터 몇 주 동안 배포됩니다. 3월까지 마이그레이션을 완료할 계획입니다.

Azure Pipelines는 2021년 9월부터 지원 windows-2022 됩니다. 이미지 안정성을 개선하기 windows-2022 위해 피드백을 모니터링했으며 이제 최신 버전으로 설정할 준비가 되었습니다.

이미지 windows-2022 에는 Visual Studio 2022가 포함됩니다. 와 의 차이점에 대한 windows-2022 전체 목록은 GitHub 문제를 참조하세요.windows-2019 이미지에 설치된 소프트웨어의 전체 목록은 여기를 검사.

파이프라인 폴더 이름 바꾸기는 사용 권한의 유효성을 검사합니다.

파이프라인이 포함된 폴더의 이름을 바꿀 수 있습니다. 이제 폴더 이름 바꾸기는 사용자가 폴더에 포함된 하나 이상의 파이프라인에 대한 편집 권한이 있는 경우에만 성공합니다.

Pipelines 에이전트 런타임 업그레이드 계획

파이프라인 에이전트란?

Azure DevOps 파이프라인 에이전트는 파이프라인 호스트에서 실행되어 파이프라인 작업을 실행하는 소프트웨어 제품입니다. Microsoft 호스팅 에이전트, Scale Set 에이전트 및 자체 호스팅 에이전트에서 실행됩니다. 후자의 경우 직접 설치합니다. 파이프라인 에이전트는 수신기 및 작업자(.NET에서 구현됨)로 구성되며, Worker는 노드 또는 PowerShell에서 구현된 작업을 실행하므로 해당 런타임을 호스트합니다.

Red Hat 6 사용 중단을 & .NET 6으로 예정된 업그레이드

.NET 6 릴리스에서는 새로운 플랫폼 간 기능을 활용할 수 있습니다. 특히 Apple 실리콘 및 Windows Arm64에 대한 기본 호환성을 제공할 수 있습니다. 따라서 앞으로 몇 달 안에 파이프라인 에이전트(수신기 및 작업자)용 .NET 6으로 이동할 계획입니다.

여러 제약 조건으로 인해 2022년 4월 30일 에이전트에서 Red Hat Enterprise Linux 6 지원을 삭제하고 있습니다.

Azure 파일 복사 작업으로 업데이트

새 버전의 Azure 파일 복사 작업을 롤아웃하고 있습니다. 이 작업은 Microsoft Azure Storage Blob 또는 VM(가상 머신)에 파일을 복사하는 데 사용됩니다. 새 버전에는 커뮤니티에서 자주 요청한 몇 가지 업데이트가 있습니다.

AzCopy 도구의 버전이 파일 콘텐츠 형식을 지원하는 10.12.2로 업데이트되었습니다. 따라서 PDF, Excel, PPT 또는 지원되는 마임 형식 중 하나를 복사하면 파일의 콘텐츠 형식이 올바르게 설정됩니다.
새 버전의 AzCopy를 사용하면 대상 유형이 Azure Blob일 때 대상을 클린 설정을 구성할 수도 있습니다. 이 옵션을 설정하면 해당 컨테이너의 모든 폴더/파일이 삭제됩니다. 또는 Blob 접두사를 제공하면 해당 접두사에 있는 모든 폴더/파일이 삭제됩니다.
새 버전의 작업은 AzureRM 모듈 대신 에이전트에 설치된 Az 모듈을 사용합니다. 이렇게 하면 작업을 사용할 때 불필요한 경고가 제거됩니다.

변경 내용은 이 작업에 대한 주 버전 업데이트의 일부입니다. 새 버전을 사용하려면 파이프라인을 명시적으로 업데이트해야 합니다. 주 버전을 업데이트하여 여전히 AzureRM 모듈에 종속된 파이프라인을 중단하지 않도록 했습니다.

파이프라인 세부 정보 보기에 대한 새 확장 지점

확장에서 대상으로 지정할 수 있는 두 개의 새로운 확장성 지점을 추가했습니다. 이러한 확장성 지점을 사용하면 파이프라인 헤더에 사용자 지정 단추와 파이프라인 폴더의 사용자 지정 메뉴를 추가할 수 있습니다.

파이프라인 헤더의 사용자 지정 단추: ms.vss-build-web.pipelines-header-menu
파이프라인 폴더의 사용자 지정 메뉴: ms.vss-build-web.pipelines-folder-menu

이러한 새 확장성 지점을 사용하려면 Azure DevOps 확장의 vss-extension.json 매니페스트 파일에서 대상을 지정하는 새 기여를 추가하면 됩니다.

예를 들면 다음과 같습니다.

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

결과는 다음과 같습니다.

파이프라인 헤더의 사용자 지정 단추
파이프라인 폴더의 사용자 지정 메뉴

Azure DevOps Services 마이그레이션 개선

Azure DevOps Server Azure DevOps Services 가져오기를 실행하는 경우 Azure DevOps가 더 이상 파이프라인별 보존 규칙을 지원하지 않는다는 점을 고려해야 합니다. 이 업데이트에서는 온-프레미스 Azure DevOps Server Azure DevOps Services 마이그레이션할 때 이러한 정책을 제거했습니다. 보존 정책 구성에 대한 자세한 내용은 빌드, 릴리스 및 테스트에 대한 보존 정책 설정에 대한 설명서를 참조하세요.

파이프라인 실행 REST API 개선

이전에는 파이프라인 실행 REST API 가 리포지토리만 반환했습니다 self . 이 업데이트를 통해 Pipelines Runs REST API는 빌드의 모든 리포지토리 리소스를 반환합니다.

확장 YAML 파이프라인 템플릿은 이제 단계, 작업 및 배포에 대한 컨텍스트 정보를 전달할 수 있습니다.

이 업데이트를 통해 템플릿과 함께 사용할 , deployment및 stage YAML 파이프라인 구성 요소에 대한 job새 templateContext 속성을 추가합니다.

를 사용하는 templateContext시나리오는 다음과 같습니다.

템플릿을 사용하여 코드 중복을 줄이거나 파이프라인의 보안을 개선합니다.
템플릿은 , jobs또는 의 stages목록을 매개 변수로 사용합니다.deployments
템플릿은 입력 목록을 처리하고 각 단계, 작업 또는 배포에서 일부 변환을 수행합니다. 예를 들어 각 작업이 실행되는 환경을 설정하거나 규정 준수를 적용하는 추가 단계를 추가합니다.
처리를 수행하려면 파이프라인 작성자가 목록의 각 단계, 작업 또는 배포에 대한 템플릿에 추가 정보를 전달해야 합니다.

예제를 살펴보겠습니다. 끌어오기 요청 유효성 검사를 위해 엔드 투 엔드 테스트를 실행하는 파이프라인을 작성한다고 가정해 봅시다. 목표는 시스템의 구성 요소를 하나만 테스트하는 것이지만 엔드 투 엔드 테스트를 실행할 계획이므로 더 많은 시스템 구성 요소를 사용할 수 있는 환경이 필요하며 해당 동작을 지정해야 합니다.

다른 팀에도 비슷한 요구 사항이 있으므로 환경을 템플릿으로 설정하는 단계를 추출하기로 결정했습니다. 해당 코드는 다음과 같습니다.

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

템플릿이 수행하는 작업은 매개 변수의 각 작업에 testSet 대해 ${{ testJob.templateContext.requiredComponents }}에 지정된 시스템 구성 요소의 응답을 ${{ testJob.templateContext.expectedHTTPResponseCode }}를 반환하도록 설정합니다.

그런 다음, 다음 예제와 같이 확장되는 고유한 파이프라인을 testing-template.yml 만들 수 있습니다.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

이 파이프라인은 양수 및 음수 테스트인 두 가지 테스트를 실행합니다. 두 테스트 모두 구성 요소를 사용할 수 있어야 합니다 dimensionsapi . 작업에는 positive_test 반환 HTTP 코드 200이 필요한 dimensionsapi 반면 negative_test HTTP 코드 500은 반환됩니다.

에이전트 서비스 계정으로 그룹 관리 서비스 계정 지원

이제 Azure Pipelines 에이전트는 Windows의 자체 호스팅 에이전트에서 그룹 관리 서비스 계정을 지원합니다.

그룹 관리 서비스 계정은 서비스 계정 역할을 하는 도메인 계정에 대한 중앙 집중식 암호 관리를 제공합니다. Azure Pipelines 에이전트는 구성 중에 암호가 필요하지 않도록 이러한 유형의 계정을 인식할 수 있습니다.

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

정보 실행

정보 실행은 Azure DevOps가 YAML 파이프라인의 소스 코드를 검색하지 못했음을 알려줍니다. 이러한 실행은 다음과 같습니다.

최근에 실행된 파이프라인

Azure DevOps는 외부 이벤트(예: 푸시된 커밋)에 대한 응답으로 또는 내부 트리거에 대한 응답으로 YAML 파이프라인의 소스 코드를 검색하여 코드 변경 내용이 있는지 검사 예약된 실행을 시작합니다. 이 단계가 실패하면 시스템에서 정보 실행을 만듭니다. 이러한 실행은 파이프라인의 코드가 GitHub 또는 BitBucket 리포지토리에 있는 경우에만 만들어집니다.

다음으로 인해 파이프라인의 YAML 코드 검색이 실패할 수 있습니다.

중단이 발생한 리포지토리 공급자
요청 제한
인증 문제
파이프라인의 .yml 파일의 콘텐츠를 검색할 수 없음

정보 실행에 대해 자세히 알아보세요.

빌드 정의 REST API `retentionRules` 속성이 사용되지 않음

빌드 정의 REST API의 BuildDefinition 응답 형식 retentionRules 에서 이 속성은 항상 빈 집합을 반환하므로 이제 속성이 사용되지 않는 것으로 표시됩니다.

Repos

새 TFVC 페이지

다양한 서비스에서 환경을 보다 일관되고 더 쉽게 액세스할 수 있도록 하기 위해 새 웹 플랫폼을 사용하도록 Azure DevOps의 다양한 페이지를 업데이트하고 있습니다. 새 웹 플랫폼을 사용하도록 TFVC 페이지가 업데이트되었습니다. 이 버전을 사용하면 새 TFVC 페이지를 일반 공급할 수 있습니다.

리포지토리 사용 안 함

고객은 종종 리포지토리를 사용하지 않도록 설정하고 사용자가 해당 콘텐츠에 액세스하지 못하도록 하는 방법을 요청했습니다. 예를 들어 다음과 같은 경우에 이 작업을 수행할 수 있습니다.

리포지토리에서 비밀을 찾았습니다.
타사 검사 도구에서 리포지토리가 규정 준수를 벗어나는 것을 발견했습니다.

이러한 경우 문제를 resolve 작업하는 동안 리포지토리를 일시적으로 사용하지 않도록 설정할 수 있습니다. 이 업데이트를 사용하면 리포지토리 삭제 권한이 있는 경우 리포지토리 를 사용하지 않도록 설정할 수 있습니다. 리포지토리를 사용하지 않도록 설정하면 다음을 수행할 수 있습니다.

리포지토리 목록에 리포지토리를 나열할 수 있음
리포지토리의 내용을 읽을 수 없음
리포지토리의 콘텐츠를 업데이트할 수 없음
Azure Repos UI에서 리포지토리에 액세스하려고 할 때 리포지토리가 비활성화되었다는 메시지를 참조하세요.

필요한 완화 단계를 수행한 후 리포지토리 삭제 권한이 있는 사용자는 리포지토리를 다시 사용하도록 설정할 수 있습니다. 리포지토리를 사용하지 않거나 사용하도록 설정하려면 프로젝트 설정으로 이동하여 리포지토리를 선택한 다음 특정 리포지토리를 선택합니다.

리포지토리 사용 안 함

분기 작성자가 분기에서 "권한 관리"를 받지 않도록 구성

새 분기를 만들 때 해당 분기에 대해 "권한 관리"가 표시됩니다. 이 권한을 사용하면 다른 사용자의 권한을 변경하거나 해당 분기에 기여할 추가 사용자를 허용할 수 있습니다. instance 경우 분기 작성자는 이 권한을 사용하여 다른 외부 사용자가 코드를 변경할 수 있도록 할 수 있습니다. 또는 파이프라인(빌드 서비스 ID)이 해당 분기의 코드를 변경하도록 허용할 수 있습니다. 규정 준수 요구 사항이 높은 특정 프로젝트에서는 사용자가 이러한 변경을 수행할 수 없습니다.

이 업데이트를 사용하면 팀 프로젝트에서 모든 리포지토리를 구성하고 분기 작성자가 "권한 관리" 권한을 얻지 못하도록 제한할 수 있습니다. 이렇게 하려면 프로젝트 설정으로 이동하여 리포지토리를 선택한 다음, 모든 리포지토리 또는 특정 리포지토리에 대한 설정을 선택합니다.

모든 리포지토리 설정

이 설정은 기존 동작을 모방하기 위해 기본적으로 설정됩니다. 그러나 이 새로운 보안 기능을 사용하려는 경우 해제할 수 있습니다.

포크 사용자가 업스트림 PR에 투표하지 못하도록 방지

Azure Repos 리포지토리에 대한 "읽기" 권한이 있는 사용자는 리포지토리를 포크하고 포크를 변경할 수 있습니다. 업스트림 변경 내용이 포함된 끌어오기 요청을 제출하려면 사용자가 업스트림 대해 "끌어오기 요청에 기여" 권한이 필요합니다. 그러나 이 권한은 업스트림 리포지토리에서 끌어오기 요청에 투표할 수 있는 사용자를 제어합니다. 결과적으로 리포지토리에 대한 기여자 아닌 사용자가 끌어오기 요청을 제출하고 분기 정책을 설정하는 방법에 따라 병합될 수 있는 상황이 발생할 수 있습니다.

내부 원본 모델을 승격하는 프로젝트에서 포크 및 기여는 일반적인 패턴입니다. 이 패턴을 추가로 보호하고 승격하기 위해 끌어오기 요청에 대한 투표 권한을 "끌어오기 요청에 기여"에서 "기여"로 변경하고 있습니다. 그러나 이 변경은 기본적으로 모든 프로젝트에서 수행되지 않습니다. 이 권한을 전환하려면 리포지토리에서 "엄격한 투표 모드"라는 새 정책을 옵트인하고 선택해야 합니다. Azure Repos 포크를 사용하는 경우 이 작업을 수행하는 것이 좋습니다.

리포지토리 설정

보고

차트 위젯에서 사용할 수 있는 그룹화 기준 태그

이제 모든 고객이 그룹화 기준 차트 위젯을 기본적으로 사용할 수 있습니다. 차트 위젯을 사용하는 경우 이제 태그에 사용할 수 있는 옵션이 있습니다. 사용자는 위젯에서 모든 태그 또는 태그 집합을 선택하여 정보를 시각화할 수 있습니다.

차트 위젯에서 사용할 수 있는 그룹화 기준 태그

이전에는 번다운 위젯에 구성된 사용자 지정 작업 항목 유형을 볼 수 없으며 사용자 지정 필드에 의해 합계 또는 계산됩니다. 이 업데이트를 통해 이 문제를 해결했으며 이제 번다운 위젯에서 사용자 지정 작업 항목 유형을 볼 수 있습니다.

사용자 의견

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

맨 위로 이동