Azure DevOps Server 2022 릴리스 정보

아티클
07/17/2024

| 개발자 커뮤니티 | 시스템 요구 사항 및 호환성 | 사용 조건 | 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일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2022용 패치(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 2022 RC2 및 RC1의 모든 기능이 포함됩니다.

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

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

참고 항목

새 SSH RSA 알고리즘 사용

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

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

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

작업 필요

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

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

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

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

Important

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

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

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

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

Boards
Repos
파이프라인
보고

Boards

배달 계획

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

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

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

두 가지 주요 보기: 압축 및 확장

배달 계획 2.0을 사용하면 시작 날짜와 대상 날짜 또는 반복 날짜를 사용하여 일정에 있는 계획의 모든 작업 항목을 볼 수 있습니다. 우선 순위는 시작 날짜와 대상 날짜, 반복입니다. 이를 통해 반복에 정의되지 않는Epic과 같은 포트폴리오 수준 작업 항목을 추가할 수 있습니다.

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

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

압축된 뷰

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

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

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

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

종속성 추적

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

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

종속성 보기

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

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

다음 몇 가지 예를 참조하십시오.

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

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

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

카드 스타일 지정

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

스타일 설정

이전

전에 카드 스타일 지정

이후

카드 스타일 지정 후

배달 계획에 대한 자세한 내용은 여기에서 설명서를 확인하세요.

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

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

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

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

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

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

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

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

파이프라인

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

이제 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 리포지토리의 포크에서 기여를 빌드할 때 작업 액세스 토큰에 부여된 권한을 제한하며 이러한 작업에서 파이프라인 비밀에 액세스하는 것을 허용하지 않습니다. 빌드 포크의 보안에 대한 자세한 내용은 설명서에서 확인할 수 있습니다.

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

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

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

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

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

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

리포지토리 A의 기여자로서 리포지토리에 검사 및 파이프라인 권한을 추가할 수 있습니다. 이렇게 하려면 프로젝트 설정으로 이동하고 리포지토리를 선택한 다음 리포지토리를 선택합니다. "체크"라는 새 메뉴가 표시됩니다. 여기서 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 은 최신 실행만 리소스에 대한 잠금을 획득한다는 것을 의미합니다.

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

환경(또는 다른 보호된 리소스)에서 배타적 잠금 검사를 사용하도록 설정합니다.
파이프라인에 대한 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 파일에서 조건식을 작성하면 식을 사용하는 ${{ else }} ${{ elseif }} 것이 더 쉬워졌습니다. 다음은 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 트리거에 대한 포함 및 제외 분기를 지정할 때 사용할 수 있습니다. 그러나 경로 필터를 지정할 때는 사용할 수 없습니다. 예를 들어 일치하는 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 windows-2019의 전체 목록은 GitHub 문제를 참조하세요. 이미지에 설치된 소프트웨어의 전체 목록은 여기를 참조 하세요.

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

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

파이프라인 에이전트 런타임 업그레이드 계획

파이프라인 에이전트란?

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

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

.NET 6 릴리스에서는 새로운 플랫폼 간 기능을 활용할 수 있습니다. 특히 Apple Silicon 및 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 또는 지원되는 MIME 형식 중 하나를 복사하면 파일의 콘텐츠 형식이 올바르게 설정됩니다.
새 버전의 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 파이프라인 템플릿을 단계, 작업 및 배포에 대한 컨텍스트 정보를 전달할 수 있습니다.

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

다음은 사용하기 templateContext위한 시나리오입니다.

템플릿을 사용하여 코드 중복을 줄이거나 파이프라인의 보안을 향상시킵니다.
템플릿은 매개 변수 목록으로 stagesjobs사용되거나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 페이지를 일반 공급할 수 있습니다.

리포지토리 사용 안 함

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

리포지토리에서 비밀을 찾았습니다.
타사 검사 도구에서 리포지토리가 규정을 준수하지 않고 있는 것을 발견했습니다.

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

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

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

리포지토리 사용 안 함

분기에 대한 “관리 권한”을 갖지 않도록 분기 작성자 구성

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

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

모든 리포지토리 설정

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

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

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

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

리포지토리 설정

보고

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

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

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

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

피드백

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

맨 위로 이동