리포지토리 및 컨테이너 리소스 정의의 템플릿 식 지원
이 업데이트에서는 리포지토리 및 컨테이너 리소스 정의에서 템플릿 식에 대한 지원을 포함했습니다. 이제 YAML 파이프라인에서 리소스의 repository
속성을 정의할 ref
때 템플릿 식을 사용하여 리포지토리 리소스의 분기를 선택할 수 있습니다. 또한 YAML 파이프라인에서 리소스의 , volumes
및 ports
options
속성을 container
정의할 endpoint
때 템플릿 식에 대한 지원을 추가했습니다.
자세한 내용은 릴리스 정보를 확인하세요.
Azure Boards
Azure Pipelines
Azure Boards
작업 항목 링크 형식 편집
이전에는 작업 항목 링크를 변경하려면 3단계 이상 완료해야 합니다. 예를 들어 부모 링크를 관련 링크로 변경하려면 작업 항목 ID를 복사하고, 부모 링크를 제거하고, 관련된 형식의 새 기존 링크를 추가하고, 마지막으로 복사한 ID를 붙여넣고 저장해야 합니다. 그것은 번거로운 과정입니다.
링크 형식을 직접 편집하고 변경할 수 있도록 하여 문제를 해결했습니다. 한 단계에서만 링크 유형을 빠르게 변경할 수 있습니다.
참고 항목
이 기능은 New Boards Hubs 미리 보기에서만 사용할 수 있습니다.
임시 쿼리 REST 엔드포인트 만들기
WIQL(작업 항목 쿼리 언어) 문을 쿼리 문자열을 통해 전달하여 저장되지 않은 쿼리를 실행하려는 확장 작성자의 여러 인스턴스를 확인했습니다. 이는 쿼리 문자열 길이에 대한 브라우저 제한에 도달하는 큰 WIQL 문이 없는 한 잘 작동합니다. 이 문제를 해결하기 위해 도구 작성자가 임시 쿼리를 생성할 수 있도록 새 REST 엔드포인트를 만들었습니다. 응답의 ID를 사용하여 쿼리 문자열을 통해 전달하면 이 문제가 제거됩니다.
임시 쿼리 REST API 설명서 페이지에서 자세히 알아봅니다.
일괄 삭제 API(프라이빗 미리 보기)
현재 휴지통에서 작업 항목을 제거하는 유일한 방법은 이 REST API 를 사용하여 한 번에 하나씩 삭제하는 것입니다. 이것은 느린 과정이 될 수 있으며 모든 종류의 대량 정리를 수행하려고 할 때 속도 제한이 적용됩니다. 이에 대한 응답으로 작업 항목을 일괄 처리로 삭제 및/또는 삭제하는 새 REST API 엔드포인트를 추가했습니다.
이 새 엔드포인트의 프라이빗 미리 보기에 참여하려면 이메일을 직접 보내주세요.
@CurrentIteration 배달 계획의 매크로
이 업데이트를 통해 배달 계획의 스타일에 대한 @CurrentIteration 매크로 지원이 추가되었습니다. 이 매크로를 사용하면 계획의 각 행에 대한 팀 컨텍스트에서 현재 반복을 가져올 수 있습니다.
Azure Pipelines
리포지토리 리소스 정의의 템플릿 식
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: echo ./build.sh
- script: echo ./test.sh
이제 분기 main
의 파이프라인이 한 실행의 분기 dev
에서 템플릿을 확장하고 파이프라인의 코드를 변경하지 않고 다른 실행의 분기 main
에서 템플릿을 확장하도록 할 수 있습니다.
리포지토리 리소스의 속성에 대한 ref
템플릿 식을 지정할 때는 미리 정의된 변수 및 시스템을 사용할 parameters
수 있지만 YAML 또는 Pipelines UI 정의 변수는 사용할 수 없습니다.
컨테이너 리소스 정의의 템플릿 식
YAML 파이프라인에서 리소스의 , volumes
및 ports
options
속성을 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 DevOps 조직의 보안을 모니터링할 수 있습니다.
특정 단계에 배포할 파이프라인을 승인하라는 메시지가 표시되면 해당 사용자는 승인을 다른 사람에게 다시 할당하도록 선택할 수 있습니다.
지금까지 이러한 작업은 감사 로그에 기록되지 않았습니다. 이 문제는 지금 해결되었습니다.
감사 로그에는 다음과 유사한 항목이 포함됩니다.
[
{
"Id": "2517368925862632546;00000264-0000-8888-8000-000000000000;839ad1ba-f72b-4258-bc3f-88be7a4553b5",
"CorrelationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
"ActivityId": "a298a06c-965f-4e60-9643-2593f2066e37",
"ActorCUID": "fe950802-bf07-755b-826d-e8dcc066252c",
"ActorUserId": "fe950802-bf07-755b-826d-e8dcc066252c",
"ActorUPN": "silviu@fabrikam.app",
"AuthenticationMechanism": "AAD_Cookie",
"Timestamp": "2022-10-10T11:26:53.7367453Z",
"ScopeType": "Organization",
"ScopeDisplayName": "Fabrikam (Organization)",
"ScopeId": "547a7316-cdf4-40d2-af16-3215f97d053e",
"ProjectId": "4bf16944-3595-421f-9947-79d9eb190284",
"ProjectName": "FabrikamFiber",
"IpAddress": "127.0.0.1",
"UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.37",
"ActionId": "ApproverReassigned",
"Data": {
"ApprovalId": "dae6e7c9-2a10-4cd8-b63a-579a6e7ba78d",
"OldApproverUserId": "692b6e2a-dd61-4872-866a-85498da390fc",
"OldApproverDisplayName": "[FabrikamFiber]\\Build Administrators",
"NewApproverUserId": "fe95080b-bf07-655b-226d-e8dcc066252c",
"NewApproverDisplayName": "Jack Fabrikam",
"Comment": "All admins are OOO"
},
"Details": "Reassigned approver of Approval dae6e7c9-9a10-4cd8-b63a-579a6e7ba78d in Project \"FabrikamFiber\" from \"[FabrikamFiber]\\Build Administrators\" to \"Jack Fabrikam\" with comment \"All admins are OOO\".",
"Area": "Checks",
"Category": "Modify",
"CategoryDisplayName": "Modify",
"ActorDisplayName": "Silviu"
}
]
또한 감사 UI에 표시됩니다.
작업 라이브러리는 에이전트 호스팅 모델을 노출합니다.
에이전트가 Microsoft 호스팅 풀에서 실행 중인지 여부를 확인하려는 작업 작성자는 이제 작업 라이브러리 함수 getAgentMode()
를 사용하여 호스팅 모델을 확인할 수 있습니다. 이는 태스크가 고객의 네트워크에 대한 액세스 여부에 따라 동작에 영향을 주려는 시나리오에서 유용합니다. 자체 호스팅 에이전트 또는 고객의 네트워크에 상주하는 확장 집합 에이전트에서 실행되는 경우 작업은 프라이빗 엔드포인트를 통해 Azure 서비스에 도달하려고 시도할 수 있습니다.
작업 참조를 참조하세요.
다음 단계
참고 항목
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
비제이 마키라주