Azure DevOps Server 2022 업데이트 2 릴리스 정보
| 개발자 커뮤니티 | 시스템 요구 사항 및 호환성 | 사용 조건 | DevOps 블로그 | SHA-256 해시 |
이 문서에서는 Azure DevOps Server의 최신 릴리스에 대한 정보를 찾을 수 있습니다.
Azure DevOps Server 배포를 설치하거나 업그레이드하는 방법에 대한 자세한 내용은 Azure DevOps Server 요구 사항을 참조 하세요.
Azure DevOps Server 제품을 다운로드하려면 Azure DevOps Server 다운로드 페이지를 방문하세요.
Azure DevOps Server 2022 업데이트 2로의 직접 업그레이드는 Azure DevOps Server 2019 또는 Team Foundation Server 2015 이상에서 지원됩니다. TFS 배포가 TFS 2013 이하에 있는 경우 Azure DevOps Server 2022로 업그레이드하기 전에 몇 가지 중간 단계를 수행해야 합니다. 자세한 내용은 설치 페이지를 참조하세요.
Azure DevOps Server 2022.2 RTW 릴리스 날짜: 2024년 7월 9일
Azure DevOps Server 2022.2 RTW의 새로운 기능 요약
참고 항목
Teams 이름을 로드하는 문제를 해결하기 위해 Azure DevOps Server 2022.2를 다시 릴리스했습니다. 이 문제는 Azure DevOps Server 2022.2 RTW에서 이제 사용 가능한 블로그 게시물에 보고되었습니다. 7월 9일에 릴리스된 Azure DevOps Server 2022.2 버전을 설치한 경우 Azure DevOps Server 2022.2용 패치 1을 설치하여 문제를 해결할 수 있습니다. 다운로드 링크가 수정 사항을 포함하도록 업데이트된 이후 처음으로 Azure DevOps Server 2022.2를 설치하는 경우에는 패치 1이 필요하지 않습니다.
Azure DevOps Server 2022.2 RTW 는 버그 수정의 롤업입니다. 여기에는 이전에 릴리스된 Azure DevOps Server 2022.2 RC의 모든 기능이 포함됩니다. Azure DevOps Server 2022.2를 직접 설치하거나 Azure DevOps Server 2020, 2019 또는 Team Foundation Server 2015 이상에서 업그레이드할 수 있습니다. 이 릴리스에서는 다음과 같은 문제 및 취약성이 해결되었습니다.
- CVE-2024-35266: Azure DevOps Server 스푸핑 취약성
- CVE-2024-35267: Azure DevOps Server 스푸핑 취약성
- 개발자 커뮤니티 피드백 티켓: Azure DevOps Server 2022.1로 업그레이드하고 에이전트 풀 구성에서 업데이트 에이전트를 사용한 후 에이전트 버전이 업데이트되지 않습니다.
- 개발자 커뮤니티 피드백 티켓: 팀 구성 페이지 로드 문제
- 개발자 커뮤니티 피드백 티켓: 특정 지역 형식에 대한 PR 전자 메일 알림의 잘못된 날짜 처리 수정
Azure DevOps Server 2022 업데이트 2 RC 릴리스 날짜: 2024년 5월 7일
Azure DevOps Server 2022.2 RC에는 많은 새로운 기능이 포함되어 있습니다. 몇 가지 중요한 기능은 다음과 같습니다.
- 영역 및 반복 경로에 대한 제한
- 파이프라인에서 승인 및 검사 무시
- 향상된 YAML 유효성 검사
- Cargo Crates에 대한 Azure Artifacts 지원
- 새 대시보드 디렉터리 환경
- 테스트 계획 또는 제품군 ID를 사용하여 빠른 복사 및 가져오기
개별 섹션으로 이동하여 각 서비스에 대한 모든 새로운 기능을 확인할 수도 있습니다.
일반
테스트 결과 게시 태스크
이제 테스트 결과 게시 태스크는 JUnit 보고서 형식에 대한 테스트 실행 첨부 파일을 지원합니다.
Azure DevOps 웹 확장 SDK의 새 버전
이 업데이트를 통해 새 버전의 Azure DevOps 웹 확장 SDK를 릴리스합니다. 클라이언트 SDK를 사용하면 웹 확장이 호스트 프레임과 통신할 수 있습니다. 다음과 같은 용도로 사용할 수 있습니다.
- 확장이 로드되었거나 오류가 있음을 호스트에 알립니다.
- 현재 페이지에 대한 기본 컨텍스트 정보 가져오기(현재 사용자, 호스트 및 확장 정보)
- 테마 정보 가져오기
- AZURE DevOps에 대한 REST 호출에 사용할 권한 부여 토큰 가져오기
- 호스트 프레임에서 제공하는 원격 서비스 가져오기
azure-devops-extension-sdk 패키지 설명서에서 전체 API 참조를 찾을 수 있습니다. 이 새 버전은 다음 모듈을 지원합니다.
ES 모듈 지원: SDK는 이제 기존 AMD(비동기 모듈 정의) 모듈 외에도 ES(ECMAScript) 모듈을 지원합니다. 이제 성능 향상을 제공하고 애플리케이션 크기를 줄이는 ES 모듈 구문을 사용하여 SDK를 가져올 수 있습니다.
AMD 모듈의 이전 버전과의 호환성: AMD 모듈에 대한 기존 지원은 그대로 유지됩니다. 프로젝트에서 AMD 모듈을 사용하는 경우 변경 없이 이전처럼 계속 사용할 수 있습니다.
사용 방법:
ES 모듈의 경우 import 문을 사용하여 모듈을 가져올 수 있습니다.
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
AMD 모듈을 사용하는 경우 함수를 사용하여 SDK를 require 계속 가져올 수 있습니다.
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Boards
영역 및 반복 경로에 대한 제한
제한은 대규모 글로벌 서비스의 상태 및 효율성을 유지하는 데 중요한 역할을 합니다. 이 릴리스에서는 영역 및 반복 경로 모두에 대해 프로젝트당 10,000개의 하드 제한을 도입했습니다. 서비스의 다양한 제한에 대해 자세히 알아보려면 작업 추적, 프로세스 및 프로젝트 제한 페이지를 방문하세요.
개발 및 배포 컨트롤
이제 프로젝트 구성 방법에 따라 작업 항목에서 개발 및/또는 배포 컨트롤을 제거합니다. 예를 들어 리포지토리 및/또는 파이프라인을 해제하도록 프로젝트 설정을 구성할 수 있습니다.
작업 항목으로 이동하면 해당 개발 및 배포 컨트롤이 양식에서 숨겨집니다.
GitHub 리포지토리를 Azure Boards에 연결하려는 경우 GitHub 리포지토리에 대한 개발 컨트롤이 표시됩니다.
Repos
사용자가 자신의 변경 내용을 승인할 수 없도록 하는 새로운 "분기 정책"
사용자가 승인하는 변경 내용에 대한 제어를 개선하고 더 엄격한 규정/규정 준수 요구 사항과 일치하도록 명시적으로 허용하지 않는 한 사용자가 자신의 변경 내용을 승인하지 못하도록 하는 옵션을 제공합니다.
분기 정책을 관리할 수 있는 기능을 가진 사용자는 이제 "새 변경 내용이 푸시되는 경우"에서 새로 추가된 옵션 "모든 반복에 대해 하나 이상의 승인 필요"를 전환할 수 있습니다. 이 옵션을 선택하면 마지막 원본 분기 변경에 대해 하나 이상의 승인 투표가 필요합니다. 사용자의 승인은 해당 사용자가 푸시한 이전의 승인되지 않은 반복에 대해 계산되지 않습니다. 따라서 다른 사용자가 마지막 반복에 대한 추가 승인을 수행해야 합니다.
다음 이미지는 사용자 A에서 만든 끌어오기 요청과 사용자 B, C, A 및 C가 해당 끌어오기 요청에 대해 수행한 추가 4개의 커밋(반복)을 보여 줍니다. 두 번째 반복(사용자 B에 의해 수행된 커밋)이 완료된 후 사용자 C는 이를 승인했습니다. 이때 사용자 A의 첫 번째 커밋(끌어오기 요청이 생성될 때)에 대한 승인을 암시했으며 새로 도입된 정책이 성공합니다. 다섯 번째 반복(사용자 C의 마지막 커밋) 후 사용자 A가 승인을 수행했습니다. 이는 사용자 C가 수행한 이전 커밋에 대한 암시적 승인이지만 네 번째 반복에서 사용자 A가 수행한 두 번째 커밋에 대한 승인을 의미하지는 않았습니다. 새로 도입된 정책을 성공하려면 승인되지 않은 반복 4개는 사용자 B, C 또는 끌어오기 요청을 변경하지 않은 다른 사용자의 승인으로 승인되어야 합니다.
참고 항목
분기 정책이 검토자로 구성된 그룹을 승인 엔터티로 사용하는 알려진 문제가 있습니다. G 그룹의 모든 사용자가 승인해야 하는 경우를 생각해 보겠습니다. 사용자 A는 해당 G 그룹의 구성원입니다. 사용자 A가 위의 이미지에서와 같이 승인을 제공한 후(다섯 번째 반복 후) G 그룹 승인은 사용자 A에 의해 수행된 변경 사항을 승인합니다. 이는 예상되지 않으며 RTW 릴리스에서 해결될 예정입니다.
Blobless 및 트리리스 필터 지원
Important
이 기능은 기본적으로 해제되어 있습니다. 이 기능을 사용하도록 설정하려면 Config DB에서 다음 쿼리를 실행하세요.
exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1
이제 Azure DevOps는 복제/페치하는 동안 두 가지 추가 필터링을 지원합니다. 다음과 같습니다. --filter=blob:none 그리고 --filter=tree:0 첫 번째 옵션(Blobless clone)은 일반 개발에 가장 적합하며, 두 번째 옵션(트리리스 클론)은 빌드 실행과 같이 클론을 삭제한 경우에 더 적합합니다.
SSH-RSA 사용 중단
Azure Repos는 사용자가 Azure Repos의 git 리포지토리에 액세스하는 두 가지 방법인 HTTPS 및 SSH를 제공합니다. SSH를 사용하려면 지원되는 암호화 방법 중 하나를 사용하여 키 쌍을 만들어야 합니다. 과거에는 SSH-RSA만 지원해 왔으며 여기에서 SSH-RSA를 사용하도록 사용자에게 요청했습니다.
이 업데이트를 통해 SSH를 사용하여 Azure Repos에 연결하기 위한 지원되는 암호화 방법으로 SSH-RSA의 사용 중단을 발표합니다. Azure Repos 블로그 게시물에 대한 SSH-RSA 지원 종료에서 자세한 내용을 볼 수 있습니다.
파이프라인
의도하지 않은 파이프라인 실행 방지
현재 YAML 파이프라인에서 섹션을 trigger 지정하지 않으면 해당 리포지토리에 푸시된 모든 변경 내용에 대해 실행됩니다. 이로 인해 파이프라인이 실행되고 의도하지 않은 실행이 많은 이유에 대한 혼란이 발생할 수 있습니다.
이 동작을 변경할 수 있는 암시적 YAML CI 트리거 사용 안 함이라는 프로젝트 컬렉션 및 프로젝트 수준 파이프라인 설정을 추가했습니다. 트리거 섹션이 없는 경우 파이프라인을 트리거하지 않도록 선택할 수 있습니다.
승인 및 확인 시간이 초과되면 스테이지 다시 시도
승인 및 확인 시간이 초과되면 해당 승인이 속한 단계를 건너뜁니다. 건너뛴 스테이지에 대한 종속성이 있는 스테이지도 건너뜁습니다.
이제 승인을 받고 시간 초과를 확인하는 단계를 다시 시도할 수 있습니다. 이전에는 승인 시간이 초과되었을 때만 가능했습니다.
승인 및 검사 우회
승인 및 검사는 서비스 연결, 리포지토리 또는 에이전트 풀과 같은 중요한 리소스에 대한 액세스를 보호하는 데 도움이 됩니다. 일반적인 사용 사례는 프로덕션에 배포할 때 승인 및 검사를 사용하는 것이며 ARM 서비스 연결을 보호하려고 합니다.
서비스 연결에 대한 다음 검사를 추가했다고 가정해 보겠습니다. 승인, 업무 시간 검사 및 Azure 함수 호출 확인(다른 지역 간에 지연을 적용하기 위해).
이제 핫픽스 배포를 수행해야 하는 경우를 상상해 보십시오. 파이프라인 실행을 시작하지만 진행되지 않습니다. 대부분의 검사가 완료되기를 기다립니다. 승인 및 검사가 완료될 때까지 기다릴 여유가 없습니다.
이 릴리스에서는 실행 중인 승인 및 검사를 무시할 수 있으므로 핫픽스를 완료할 수 있습니다.
실행 중인 승인, 업무 시간, Azure 함수 호출 및 REST API 검사를 호출할 수 있습니다.
승인을 무시합니다.
업무 시간 검사를 무시합니다.
Azure 함수 호출 검사를 바이패스합니다. 업무 시간 검사를 무시합니다.
검사를 무시하면 검사 패널에서 확인할 수 있습니다.
검사가 정의된 리소스의 관리자인 경우에만 검사를 무시할 수 있습니다.
Azure 함수 검사 호출 다시 실행
시스템을 여러 단계로 배포한다고 상상해 보십시오. 두 번째 단계를 배포하기 전에 이미 배포된 시스템의 일부에서 온전성 검사를 실행하는 승인 및 Azure 함수 호출 확인이 있습니다.
승인 요청을 검토할 때 정신 검사가 이틀 전에 실행된 것을 알 수 있습니다. 이 시나리오에서는 정신 검사 결과에 영향을 주는 다른 배포를 알고 있을 수 있습니다.
이 업데이트를 사용하면 Azure Function 호출을 다시 실행하고 REST API 검사를 호출할 수 있습니다. 이 기능은 성공했으며 다시 시도하지 않은 검사에만 사용할 수 있습니다.
참고 항목
검사가 정의된 리소스의 관리자인 경우에만 검사를 다시 실행할 수 있습니다.
필요한 템플릿 검사에서 GitHub 엔터프라이즈 서버 지원
템플릿은 프로젝트 컬렉션에서 파이프라인의 단계, 작업 및 단계를 제어할 수 있는 보안 메커니즘입니다.
템플릿 필요 검사를 사용하면 에이전트 풀 또는 서비스 연결과 같은 보호된 리소스에 액세스하기 전에 승인된 템플릿 집합에서 파이프라인이 확장되도록 할 수 있습니다.
이제 GitHub Enterprise Server 리포지토리에 있는 템플릿을 지정할 수 있습니다.
모든 환경에 대한 관리자 역할
YAML 파이프라인의 환경은 애플리케이션을 배포하는 컴퓨팅 리소스(예: AKS 클러스터 또는 VM 집합)를 나타냅니다. 배포에 대한 보안 제어 및 추적 기능을 제공합니다.
환경을 관리하는 것은 매우 어려울 수 있습니다. 환경이 만들어지면 환경을 만드는 사람이 자동으로 유일한 관리자가 되기 때문입니다. 예를 들어 모든 환경의 승인 및 검사를 중앙 집중식으로 관리하려면 모든 환경 관리자에게 특정 사용자 또는 그룹을 관리자로 추가한 다음 REST API를 사용하여 검사를 구성하도록 요청해야 했습니다. 이 방법은 지루하고 오류가 발생하기 쉬울 수 있으며 새 환경이 추가될 때 크기를 조정하지 않습니다.
이 릴리스에서는 환경 허브 수준에서 관리자 역할을 추가했습니다. 이렇게 하면 환경이 서비스 연결 또는 에이전트 풀과 동등합니다. 사용자 또는 그룹에 관리자 역할을 할당하려면 이미 environments-hub 관리자 또는 프로젝트 컬렉션 소유자여야 합니다.
이 관리자 역할이 있는 사용자는 모든 환경을 관리, 관리, 보기 및 사용할 수 있습니다. 여기에는 모든 파이프라인에 대한 환경 열기가 포함됩니다.
환경 허브 수준에서 사용자 관리자 역할을 부여하면 모든 기존 환경 및 향후 환경에 대한 관리자가 됩니다.
향상된 YAML 유효성 검사
YAML 구문이 올바른지 확인하려면 Azure Pipelines 웹 편집기 유효성 검사 기능을 사용할 수 있습니다. 따라서 이 기능은 가능한 한 많은 YAML 문제를 catch하는 것이 중요합니다.
이제 식과 관련하여 YAML 유효성 검사가 더욱 철저해졌습니다.
YAML 파이프라인을 작성할 때 함수를 사용하여 변수 값을 정의할 수 있습니다.
다음 변수를 정의합니다.
variables:
Major: '1'
Minor: '0'
Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]
변수는 Patch 함수와 다른 두 변수를 사용하여 counter 정의됩니다. 위의 YAML 코드에서 단어 format 의 철자가 잘못되었습니다. 이전에는 이 오류가 발견되지 않았습니다. 이제 유효성 검사 기능이 이를 감지하고 오류 메시지를 표시합니다.
Azure Pipelines는 파이프라인/스테이지/작업 수준에서 잘못된 변수 정의를 검색합니다.
YAML 파이프라인에서는 조건을 사용하여 스테이지 실행을 건너뛸 수 있습니다. 오타도 다음 예제와 같이 여기에 표시할 수 있습니다.
steps:
- task: NuGetCommand@2
condition: eq(variable.Patch, 0)
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
변수 값이 NuGetCommand 0인 경우에만 태스크가 Patch 실행됩니다. 또한 조건에 오타가 있으며 유효성 검사 기능에 오타가 표시됩니다.
Azure Pipelines는 파이프라인/스테이지/작업 수준에서 정의된 잘못된 YAML 조건을 검색합니다.
환경에 대한 REST API
환경은 파이프라인의 배포를 사용하여 대상으로 지정할 수 있는 리소스 컬렉션입니다. 환경은 배포 기록, 작업 항목 및 커밋에 대한 추적 가능성 및 액세스 제어 메커니즘을 제공합니다.
프로그래밍 방식으로 환경을 만들려는 것을 알고 있으므로 REST API에 대한 설명서를 게시했습니다.
승인 REST API 개선 사항
사용자가 속한 그룹을 검색 결과에 포함시켜 사용자에게 할당된 승인 찾기를 개선했습니다.
이제 승인에 속한 파이프라인 실행에 대한 정보가 포함됩니다.
예를 들어 다음 GET REST API 호출 https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending 이 반환됩니다.
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
이제 파이프라인 로그에 리소스 사용률이 포함됩니다.
이제 Azure 파이프라인 로그는 메모리, CPU 사용량 및 사용 가능한 디스크 공간과 같은 리소스 사용률 메트릭을 캡처할 수 있습니다. 로그에는 파이프라인 에이전트에서 사용하는 리소스와 작업에서 실행되는 작업을 포함한 자식 프로세스도 포함됩니다.
파이프라인 작업이 리소스 제약 조건이 발생할 수 있다고 의심되는 경우 자세한 정보 표시 로그를 사용하여 파이프라인 로그에 리소스 사용률 정보를 삽입할 수 있습니다. 이는 호스팅 모델과는 별개로 모든 에이전트에서 작동합니다.
이제 Azure Pipelines 에이전트가 Alpine Linux를 지원합니다.
파이프라인 에이전트 v3.227은 이제 Alpine Linux 버전 3.13 이상을 지원합니다. Alpine Linux는 컨테이너(기본) 이미지에 널리 사용됩니다. 릴리스 페이지에서 에이전트를 찾을 수 있습니다 . 에이전트의 Alpine Linux 버전에는 접두사가 vsts-agent-linux-musl 있습니다(예: .). vsts-agent-linux-musl-x64-3.227.1.tar.gz
Azure Pipelines 작업에서 노드 16 사용
파이프라인의 태스크는 실행기를 사용하여 실행되며 대부분의 경우 Node.js 사용됩니다. 노드를 실행자로 활용하는 Azure Pipelines 작업은 이제 모두 노드 16을 사용합니다. Node 16은 Apple 실리콘을 기본적으로 지원하는 첫 번째 노드 버전이므로 Apple 실리콘의 macOS에 대한 전체 작업 지원도 완료합니다. Apple 실리콘에서 실행되는 에이전트는 로제타를 실행할 필요가 없습니다.
노드 16 수명 종료 날짜가 앞으로 이동함에 따라 노드 20을 사용하여 작업을 실행하는 작업을 시작했습니다.
ARM(4MB 최대 Azure Resource Manager) 템플릿 크기에 맞게 Azure Pipeline 제한이 증가했습니다.
Azure Resource Manager 템플릿 배포 작업을 사용하여 Azure 인프라를 만들 수 있습니다. 피드백에 따라 Azure Pipelines 통합 제한이 2MB에서 4MB로 증가했습니다. 이렇게 하면 큰 템플릿을 통합하는 동안 크기 제약 조건을 해결하는 ARM 템플릿의 최대 크기인 4MB 에 맞춥니다.
AzureRmWebAppDeployment 작업은 Microsoft Entra ID 인증을 지원합니다.
AzureRmWebAppDeploymentV3 및 AzureRmWebAppDeployment@4 작업은 기본 인증을 사용하지 않도록 설정된 App Service를 지원하도록 업데이트되었습니다. App Service에서 기본 인증을 사용하지 않도록 설정한 경우 AzureRmWebAppDeploymentV3/4 작업은 Microsoft Entra ID 인증을 사용하여 App Service Kudu 엔드포인트에 배포를 수행합니다. 이렇게 하려면 에이전트에 최신 버전의 msdeploy.exe 설치해야 합니다. 이는 windows-2022/windows-latest Hosted 에이전트의 경우입니다(작업 참조 참조 참조).
빌드가 실패할 때 코드 검사 정책 상태를 장애 조치(Failed)로 재정의할 수 없음
이전에는 PR의 빌드가 실패하는 경우 코드 검사 정책 상태가 '실패'로 재정의되었습니다. 이는 PR에 대한 필수 검사로 빌드를 선택적 검사로 사용하고 코드 검사 정책을 사용하여 PR이 차단되는 일부 사용자에게 차단되었습니다.
이제 빌드가 실패하면 코드 검사 정책이 '실패'로 재정의되지 않습니다. 이 기능은 모든 고객에 대해 사용하도록 설정됩니다.
Artifacts
화물 상자에 대한 Azure Artifacts 지원 소개
Azure Artifacts가 이제 화물 상자에 대한 기본 지원을 제공한다는 것을 발표하게 되어 기쁩니다. 이 지원에는 업스트림 원본으로 사용할 수 있는 crates.io 외에도 기존 프로토콜과 관련된 기능 패리티가 포함됩니다. Rust 개발자와 팀은 이제 Azure의 강력한 인프라를 사용하고 친숙한 Azure DevOps 환경에 머무르는 동안 화물 상자를 원활하게 사용, 게시, 관리 및 공유할 수 있습니다.
NuGet 복원 v1 및 NuGet Installer v0 파이프라인 작업에 대한 사용 중단 공지
NuGet 복원 v1 및 NuGet Installer v0 파이프라인 작업을 사용하는 경우 즉시 NuGetCommand@2 파이프라인 작업으로 전환합니다. 전환이 이루어지지 않은 경우 곧 파이프라인에서 경고 수신을 시작합니다. 2023년 11월 27일부터 아무 작업도 수행되지 않으면 빌드에 오류가 발생합니다.
npm 감사에 대한 Azure Artifacts 지원
이제 Azure Artifacts에서 npm audit 명령과 npm audit fix 지원을 지원합니다. 이 기능을 사용하면 안전하지 않은 패키지 버전을 자동으로 업데이트하여 프로젝트의 취약성을 분석하고 수정할 수 있습니다. 자세한 내용은 npm 감사를 사용하여 패키지 취약성을 감지하고 수정합니다.
보고
새 대시보드 디렉터리 환경
여러분의 의견을 듣고 새로운 대시보드 디렉터리 환경을 소개하게 되어 기쁩니다. 최신 UI 디자인뿐만 아니라 마지막으로 구성된 열을 추가하여 각 열을 기준으로 정렬할 수도 있습니다. 이 열은 프로젝트 컬렉션 내의 전체 대시보드 사용에 대한 더 나은 인사이트를 제공합니다. 또한 이제 팀 또는 프로젝트 수준 대시보드를 필터링하여 보고 싶지 않은 대시보드를 숨기는 동안 확인해야 하는 항목 목록에만 액세스할 수 있습니다.
지금 사용해 보시고 Azure DevOps 커뮤니티에서 어떻게 생각하는지 알려주세요.
작업 항목 필터링
작업 항목 차트 필터링을 발표 하게 되어 기쁩니다. 이 기능을 사용하면 작업 항목 차트를 마우스로 가리키면 빠른 개요를 확인하고 자세한 인사이트를 위해 특정 차트 세그먼트로 드릴다운할 수 있습니다. 필요한 정확한 데이터에 액세스하기 위해 더 이상 사용자 지정 쿼리를 만들 필요가 없습니다. 이제 몇 번의 클릭으로 작업 항목 차트의 작업 항목을 자세히 살펴볼 수 있습니다.
피드백은 이 기능의 미래를 구체화하는 데 매우 중요합니다. 지금 사용해 보시고 Azure DevOps 커뮤니티에서 어떻게 생각하는지 알려주세요.
폴더에 대한 코드 검사 결과
이제 코드 검사 결과는 최상위 숫자로만 제공되는 것이 아니라 모든 개별 파일 및 폴더에 사용할 수 있습니다. 폴더 보기 모드 단추가 전환되면 코드 검사 보기가 나타납니다. 이 모드에서는 드릴다운하고 선택한 하위 트리에 대한 코드 검사를 볼 수 있습니다. 토글 단추를 사용하여 새 보기와 이전 보기 간에 전환합니다.
Test Plans
테스트 계획 또는 제품군 ID를 사용하여 빠른 복사 및 가져오기
이제 Azure Test Plans에서 여러 테스트 계획을 쉽게 처리할 수 있습니다. 테스트 사례( 특히 광범위한 계획 또는 제품군)를 가져오거나 복사하거나 복제하기 위한 긴 드롭다운 메뉴가 이전에 직면했던 문제를 인식하여 워크플로를 간소화하기 위한 단계를 수행했습니다.
테스트 계획 및 제품군 ID 검색 기능을 발표하게 되어 기쁩니다. 지연 없이 테스트 사례를 신속하게 가져오거나 복사하려면 테스트 계획 또는 제품군 ID를 입력합니다. 이 업데이트는 테스트 관리 환경을 개선하기 위한 지속적인 노력의 일부로, 보다 직관적이고 시간이 덜 소요됩니다.
Azure Test Runner에 대한 업데이트
Azure Test Runner가 최신 버전으로 업데이트되었음을 공유하게 되어 기쁩니다. 이 업데이트는 안정성과 성능을 향상시켜 중단 또는 지연 없이 테스트를 실행할 수 있도록 합니다. 이전 버전의 Azure Test Runner는 더 이상 지원되지 않습니다. 테스트 작업의 최상의 성능과 신뢰성을 위해 가능한 한 빨리 최신 버전으로 업데이트하는 것이 좋습니다.
새로운 기능
- 향상된 안정성 및 성능: 테스트 실행기를 크게 개선하여 일부 사용자가 경험한 문제를 해결했습니다. 이 업그레이드는 보다 안정적인 테스트 프로세스를 보장하여 작업 중단을 최소화합니다.
- 업그레이드 프롬프트: 새 버전으로 원활하게 전환하려면 업그레이드하라는 메시지가 표시됩니다. 이렇게 하면 모든 사용자가 편리하게 향상된 버전으로 쉽게 이동할 수 있으므로 호환성과 성능이 향상됩니다.
피드백
많은 의견 부탁드립니다! 문제를 보고하거나 아이디어를 제공하고 개발자 커뮤니티를 통해 추적하고 Stack Overflow에 대한 조언을 얻을 수 있습니다.