향상된 YAML 미리 보기 API 및 유니버설 패키지에 대한 업스트림 원본 구성
이 스프린트에서는 완료된 YAML 본문을 검색할 수 있는 새 API 엔드포인트를 롤아웃합니다. 또한 이 릴리스에서 유니버설 패키지에 대한 업스트림 원본을 구성하는 기능을 추가한다고 발표하게 되어 기쁩니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
Azure Boards
- 백로그 및 보드의 시스템 작업 항목 형식
- 감사 로깅 이벤트
- Azure Boards GitHub 앱 리포지토리 제한 발생(프라이빗 미리 보기)
- 끌어오기 요청이 병합될 때 작업 항목 상태 사용자 지정(프라이빗 미리 보기)
Azure Pipelines
- 파이프라인 이미지 알림
- 에이전트 로그 업로드가 개선됨
- 선택적으로 컨테이너 볼륨을 읽기 전용으로 탑재
- 컨테이너 시작/중지를 세분화하여 제어
- 각 단계의 작업 번들 압축 풀기
- 액세스 토큰의 범위를 제한하여 릴리스 보안 개선
- YAML 미리 보기 API 개선 사항
Azure Artifacts
Azure Boards
백로그 및 보드의 시스템 작업 항목 형식
선택한 백로그 수준에 시스템 작업 항목 유형을 추가할 수 있는 기능의 프라이빗 미리 보기를 시작했습니다. 지금까지 이러한 작업 항목 유형은 쿼리에서만 사용할 수 있었습니다.
Process | 작업 항목 형식 |
---|---|
애자일. | 문제 |
스크럼 | 장애 |
Cmmi | 변경 요청 |
문제 | |
검토 | |
위험 |
이제 이 기능이 미리 보기로 제공되지 않으며 모든 조직에서 일반적으로 사용할 수 있음을 알려드리겠습니다. 백로그 수준에 시스템 작업 항목 유형을 추가하는 것은 간단합니다. 사용자 지정 프로세스로 이동하여 백로그 수준 탭을 클릭합니다. 선택한 백로그 수준(예: 요구 사항 백로그)을 선택하고 편집 옵션을 선택합니다. 그런 다음 작업 항목 유형을 추가합니다.

감사 로깅 이벤트
고객이 관련 변경 내용을 더 잘 추적할 수 있도록 감사 로그에 새 이벤트를 추가했습니다. 선택 목록의 값이 변경될 때마다 이벤트가 기록됩니다. 선택 목록 필드의 변경 내용은 일반적으로 프로세스에 대한 가장 일반적인 변경 내용입니다. 이 새 이벤트를 사용하면 조직 관리자가 해당 필드를 변경한 시기와 사용자를 더 잘 추적할 수 있습니다.

Azure Boards GitHub 앱 리포지토리 제한 발생(프라이빗 미리 보기)
GitHub Marketplace에서 Azure Boards 애플리케이션을 사용하는 경우 연결할 수 있는 GitHub 리포지토리는 100개로 제한됩니다. 이는 100개가 넘는 리포지토리를 가질 수 있는 대규모 조직의 차단기가 됩니다. 이 스프린트에서는 Azure Boards가 GitHub 리포지토리에 연결하는 방식을 변경하여 100개 이상을 지원합니다. 현재 100 리포지토리 한도에 도달한 경우 알려주세요. 이 기능을 사용하여 해당 제한을 늘리고 차단을 해제할 수 있습니다. 조직 이름으로 직접 이메일을 보내주세요(dev.azure.com/{organization}).
끌어오기 요청이 병합될 때 작업 항목 상태 사용자 지정(프라이빗 미리 보기)
모든 워크플로가 동일한 것은 아닙니다. 일부 고객은 끌어오기 요청이 완료되면 관련 작업 항목을 닫고자 합니다. 다른 사용자는 작업 항목을 닫기 전에 유효성을 검사할 다른 상태로 설정하려고 합니다. 우리는 둘 다 허용해야합니다.
스프린트 174부터 끌어오기 요청이 병합되고 완료될 때 작업 항목을 원하는 상태로 설정할 수 있는 새로운 기능이 있습니다. 이렇게 하려면 끌어오기 요청 설명을 검색하고 작업 항목의 #멘션 뒤에 오는 상태 값을 찾습니다. 이 예제에서는 두 개의 사용자 스토리를 해결됨으로 설정하고 두 작업을 닫습니다.

이 기능은 오랜 시간이 다가오고 있으며, 우리는 당신이 어떻게 생각하는지보고 기쁘게 생각합니다. 시작하려면 끌어오기 요청 설명을 검사하고 사용자 인터페이스 변경 내용을 포함하지 않습니다. 우리는 더 투자하기 전에 먼저 피드백을 얻고 싶었습니다.
프라이빗 미리 보기 에 참여하려면 직접 이메일을 보내주세요. 조직(dev.azure.com/{organization})을 포함해야 합니다.
Azure Pipelines
파이프라인 이미지 알림
참고 항목
Azure Pipelines 이미지는 사용자에게 최상의 환경을 제공하기 위해 지속적으로 업데이트됩니다. 이러한 일상적인 업데이트는 주로 버그 또는 오래된 소프트웨어를 해결하기 위한 것입니다. 파이프라인에 영향을 주지 않는 경우가 많을 수 있지만 항상 그런 것은 아닙니다. 파이프라인은 이미지에서 제거되거나 업데이트된 소프트웨어에 대한 종속성을 사용하는 경우 영향을 받을 수 있습니다.
Windows, Linux 및 macOS 이미지에서 예정된 업데이트에 대해 자세히 알아보려면 다음 공지 사항을 참조하세요.
예정된(시험판) 및 배포된 변경 내용에 대한 릴리스 정보를 보려면 다음 릴리스 정보를 구독하세요.
에이전트 로그 업로드가 개선됨
에이전트가 Azure Pipelines 서버와의 통신을 중지하면 실행 중인 작업이 중단됩니다. 스트리밍 콘솔 로그를 살펴보는 경우 에이전트가 응답을 중지하기 직전에 무엇이었는지에 대한 단서를 얻었을 수 있습니다. 그러나 그렇지 않았거나 페이지를 새로 고친 경우 해당 콘솔 로그가 사라졌습니다. 이 릴리스에서는 에이전트가 전체 로그를 보내기 전에 응답을 중지하는 경우 콘솔 로그를 다음으로 가장 좋은 것으로 유지합니다. 콘솔 로그는 줄당 1000자로 제한되며 경우에 따라 불완전할 수 있지만 아무것도 표시하지 않는 것보다 훨씬 더 유용합니다. 이러한 로그를 검토하면 고유한 파이프라인 문제를 해결하는 데 도움이 될 수 있으며, 지원 엔지니어가 문제 해결을 지원할 때 확실히 도움이 될 것입니다.
선택적으로 컨테이너 볼륨을 읽기 전용으로 탑재
Azure Pipelines에서 컨테이너 작업을 실행하면 작업 영역, 작업 및 기타 자료가 포함된 여러 볼륨이 볼륨으로 매핑됩니다. 이러한 볼륨은 기본적으로 읽기/쓰기 액세스로 설정됩니다. 보안을 강화하기 위해 YAML에서 컨테이너 사양을 변경하여 볼륨을 읽기 전용으로 탑재할 수 있습니다. 아래 mountReadOnly
의 각 키는 읽기 전용으로 true
설정할 수 있습니다(기본값은 false
).
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
컨테이너 시작/중지를 세분화하여 제어
일반적으로 Azure Pipelines가 작업 및 서비스 컨테이너의 수명 주기를 관리할 수 있도록 허용하는 것이 좋습니다. 그러나 일부 드문 시나리오에서는 직접 시작하고 중지할 수 있습니다. 이 릴리스에서는 Docker 작업에 해당 기능을 빌드했습니다.
다음은 새 기능을 사용하는 예제 파이프라인입니다.
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
또한 파이프라인 변수 Agent.ContainerMapping
에 컨테이너 목록을 포함합니다. 예를 들어 스크립트의 컨테이너 목록을 검사하려는 경우 이를 사용할 수 있습니다. 여기에는 리소스 이름(위 예제의 "작성기")을 에이전트가 관리하는 컨테이너 ID에 매핑하는 문자열화된 JSON 개체가 포함되어 있습니다.
각 단계의 작업 번들 압축 풀기
에이전트가 작업을 실행하면 먼저 작업의 단계에 필요한 모든 작업 번들을 다운로드합니다. 일반적으로 성능의 경우 태스크가 여러 단계에서 사용되는 경우에도 작업당 한 번씩 태스크의 압축을 해제합니다. 압축을 푼 콘텐츠를 변경하는 신뢰할 수 없는 코드에 대한 우려가 있는 경우 에이전트가 각 사용량에 대해 작업의 압축을 풉니다. 이 모드를 사용하도록 설정하려면 에이전트를 구성할 때 전달 --alwaysextracttask
합니다.
액세스 토큰의 범위를 제한하여 릴리스 보안 개선
Azure Pipelines에 대한 보안 설정을 강화하기 위한 이니셔티브에 따라 이제 릴리스에 대한 액세스 토큰 범위 제한이 지원됩니다.
릴리스에서 실행되는 모든 작업은 액세스 토큰을 가져옵니다. 액세스 토큰은 태스크 및 스크립트에서 Azure DevOps로 다시 호출하는 데 사용됩니다. 예를 들어 액세스 토큰을 사용하여 소스 코드를 가져오거나, 아티팩트 다운로드, 로그 업로드, 결과 테스트 또는 Azure DevOps에 REST 호출을 합니다. 새 액세스 토큰은 각 작업에 대해 생성되며 작업이 완료되면 만료됩니다.
이 업데이트를 통해 액세스 토큰 의 범위를 제한하고 클래식 릴리스로 동일하게 확장하여 파이프라인 보안을 개선합니다.
이 기능은 기본적으로 새 프로젝트 및 조직에 대해 설정됩니다. 기존 조직의 경우 조직 설정 파이프라인 > 설정 > 사용하도록 설정해야 합니다. > 릴리스 파이프라인에 대한 작업 권한 부여 범위를 현재 프로젝트로 제한합니다. 여기서 자세히 알아봅니다.
YAML 미리 보기 API 개선 사항
몇 가지 스프린트 전에 파이프라인을 실행하지 않고 파이프라인의 전체 YAML을 미리 볼 수 있는 기능이 도입되었습니다. 이 업데이트를 통해 미리 보기 기능에 대한 전용 새 URL을 만들었습니다. 이제 POST를 사용하여 https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview
완료된 YAML 본문을 검색할 수 있습니다. 이 새 API는 실행 큐와 동일한 매개 변수를 사용하지만 더 이상 "큐 빌드" 권한이 필요하지 않습니다.
Azure Artifacts
Universal Packages의 업스트림 소스 구성
이제 요청 시 업스트림 원본에서 유니버설 패키지를 자동으로 다운로드하도록 Azure Artifacts 피드를 구성할 수 있습니다.
이전에는 NuGet, Python, Maven 및 npm 패키지에 대한 피드에서 업스트림 원본을 구성할 수 있었지만 유니버설 패키지에는 구성할 수 없었습니다. 이는 지원되는 다른 패키지 유형보다 훨씬 더 큰 패키지를 지원하는 유니버설 패키지에 사용되는 스토리지 기술의 차이 때문입니다.
이제 다른 패키지 유형과 동일한 방식으로 유니버설 패키지에 대한 업스트림 원본을 구성할 수 있습니다. 피드 설정을 열고 업스트림 원본 ->업스트림 원본 추가를> 클릭하고 적합한 원본 유형을 선택할 수 있습니다. 다음 보기에서 UPack(유니버설 패키지)이 새 옵션으로 표시됩니다(아래 이미지 참조). 자세한 내용은 업스트림 원본 구성 설명서를 참조하세요.

업스트림 원본의 유니버설 패키지는 동일한 DevOps 조직의 피드 간에만 지원됩니다.
이제 Maven 패키지에 업데이트 패키지 버전 REST API 사용 가능
이제 Azure Artifacts "패키지 버전 업데이트" REST API를 사용하여 Maven 패키지 버전을 업데이트할 수 있습니다. 이전에는 REST API를 사용하여 NuGet, Maven, npm 및 유니버설 패키지에 대한 패키지 버전을 업데이트할 수 있었지만 Maven 패키지는 업데이트할 수 없었습니다.
Maven 패키지를 업데이트하려면 다음과 같이 HTTP PATCH 명령을 사용합니다.
PATCH
https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
다음을 설정할 수 있습니다.
URI 매개 변수
이름 | In | Required | Type | 설명 |
---|---|---|---|---|
artifactId | path | TRUE | string | 패키지의 아티팩트 ID |
피드 | path | TRUE | string | 피드의 이름 또는 ID |
groupId | path | TRUE | string | 패키지의 그룹 ID |
조직 | path | TRUE | string | Azure DevOps 조직의 이름 |
version | path | TRUE | string | 패키지 버전 |
project | 경로 | string | 프로젝트 ID 또는 프로젝트 이름 | |
api-version | query | TRUE | string | 사용할 API의 버전입니다. 이 버전의 API를 사용하려면 '5.1-preview.1'로 설정해야 합니다. |
요청 본문
이름 | 타입 | 설명 |
---|---|---|
보기 | JsonPatchOperation | 패키지 버전이 추가될 보기 |
자세한 내용은 업데이트되는 REST API 설명서를 참조하세요.
다음 단계
참고 항목
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
아론 할버그