작업 항목 상태 전환 제한
미리 보기에서 여러 스프린트를 마친 후 이제 스프린트 172 업데이트의 일환으로 모든 고객에게 상태 전환 제한 규칙의 일반 릴리스를 발표합니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
Azure Boards
Azure Pipelines
- 배타적 배포 잠금 정책
- 파이프라인 리소스 트리거에 대한 단계 필터
- YAML 파이프라인에 대한 일반 웹후크 기반 트리거
- YAML 리소스 트리거 문제 지원 및 추적 가능성
- 파이프라인에 영향을 주는 라이브 사이트 인시던트에 대한 배너
Azure Artifacts
Azure Boards
상태 전환 제한 규칙
프라이빗 미리 보기의 여러 스프린트 후에는 이제 모든 고객에게 상태 전환 제한 규칙을 일반 공급할 수 있습니다. 이 새로운 작업 항목 유형 규칙을 사용하면 작업 항목이 한 상태에서 다른 상태로 이동되지 않도록 제한할 수 있습니다. 예를 들어 버그가 새로 만들기에서 해결됨으로 전환되지 않도록 제한할 수 있습니다. 대신 새로 만들기 - 활성 ->> 해결됨에서 이동해야 합니다.
그룹 멤버 자격으로 상태 전환을 제한하는 규칙을 만들 수도 있습니다. 예를 들어 "승인자" 그룹의 사용자만 New -> Approved에서 사용자 스토리를 이동할 수 있습니다.
작업 항목을 복사하여 자식 복사
Azure Boards에서 가장 많이 요청한 기능 중 하나는 자식 작업 항목도 복사하는 작업 항목을 복사하는 기능입니다. 이 스프린트에서는 작업 항목 복사 대화 상자에 "자식 작업 항목 포함"에 대한 새 옵션을 추가했습니다. 이 옵션을 선택하면 작업 항목을 복사하고 모든 자식 작업 항목(최대 100개)을 복사합니다.
활성화 및 해결된 필드에 대한 향상된 규칙
지금까지 활성화된 날짜, 활성화된 날짜, 해결한 날짜 및 해결된 날짜에 대한 규칙은 미스터리였습니다. 시스템 작업 항목 유형에 대해서만 설정되며 "활성" 및 "해결됨"의 상태 값과 관련이 있습니다. 스프린트 172에서는 이러한 규칙이 더 이상 특정 상태에 적용되지 않도록 논리를 변경했습니다. 대신 상태가 상주하는 범주(상태 범주)에 의해 트리거됩니다. 예를 들어 해결된 범주에 "테스트 필요"라는 사용자 지정 상태가 있다고 가정해 보겠습니다. 작업 항목이 "활성"에서 "테스트 필요" 로 변경되면 해결된 날짜 및 확인된 날짜 규칙이 트리거됩니다.
이를 통해 고객은 사용자 지정 규칙을 사용할 필요 없이 사용자 지정 상태 값을 만들고 활성화된 날짜, 정품 인증 날짜, 해결된 날짜 및 해결된 날짜 필드를 계속 생성할 수 있습니다.
백로그 및 보드의 시스템 작업 항목 유형(프라이빗 미리 보기)
상속 프로세스 모델이 시작된 이래로 여러 작업 항목 유형이 보드 및 백로그에 추가되지 않도록 제외되었습니다. 이러한 작업 항목 유형은 다음과 같습니다.
| Process | 작업 항목 형식 |
|---|---|
| 애자일. | 문제 |
| 스크럼 | 장애 |
| CMMI | 변경 요청 |
| 문제 | |
| 검토 | |
| 위험 |
이 스프린트를 시작하여 이러한 작업 항목 유형을 모든 백로그 수준에서 사용할 수 있도록 하려는 고객을 위한 프라이빗 미리 보기를 허용합니다.
이 기능을 미리 보려면 조직 이름으로 이메일을 보내주시면 액세스 권한을 부여해 주세요.
Azure Pipelines
배타적 배포 잠금 정책
이 업데이트를 사용하면 한 번에 하나의 실행만 환경에 배포되도록 할 수 있습니다. 환경에서 "배타적 잠금" 검사를 선택하면 하나의 실행만 진행됩니다. 해당 환경에 배포하려는 후속 실행은 일시 중지됩니다. 배타적 잠금이 있는 실행이 완료되면 최신 실행이 진행됩니다. 중간 실행은 취소됩니다.
파이프라인 리소스 트리거에 대한 단계 필터
이 스프린트에서는 YAML의 파이프라인 리소스에 대한 필터로 '단계'에 대한 지원을 추가했습니다. 이 필터를 사용하면 CD 파이프라인을 트리거하기 위해 전체 CI 파이프라인이 완료될 때까지 기다릴 필요가 없습니다. 이제 CI 파이프라인에서 특정 단계가 완료되면 CD 파이프라인을 트리거하도록 선택할 수 있습니다.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages: ### This stage filter is used when evaluating conditions for triggering your CD pipeline
- PreProduction ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered.
- Production
트리거 필터에 제공된 단계가 CI 파이프라인에서 성공적으로 완료되면 CD 파이프라인에 대해 새 실행이 자동으로 트리거됩니다.
YAML 파이프라인에 대한 일반 웹후크 기반 트리거
현재 아티팩트 사용 및 자동화된 트리거를 사용할 수 있는 다양한 리소스(예: 파이프라인, 컨테이너, 빌드 및 패키지)가 있습니다. 그러나 지금까지는 다른 외부 이벤트 또는 서비스를 기반으로 배포 프로세스를 자동화할 수 없었습니다. 이 릴리스에서는 외부 서비스와 파이프라인 자동화를 통합할 수 있도록 YAML 파이프라인에서 웹후크 트리거 지원을 도입했습니다. 웹후크(GitHub, GitHub Enterprise, Nexus, Artifactory 등)를 통해 외부 이벤트를 구독하고 파이프라인을 트리거할 수 있습니다.
웹후크 트리거를 구성하는 단계는 다음과 같습니다.
외부 서비스에 웹후크를 설정합니다. 웹후크를 만들 때 다음 정보를 제공해야 합니다.
- 요청 URL - "https://dev.azure.com/<ADO 조직>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
- 비밀 - 선택 사항입니다. JSON 페이로드를 보호해야 하는 경우 비밀 값을 제공합니다.
새 "들어오는 웹후크" 서비스 연결을 만듭니다. 세 가지 중요한 정보를 정의할 수 있는 새로 도입된 서비스 연결 유형입니다.
- 웹후크 이름: 웹후크의 이름은 외부 서비스에서 만든 웹후크와 일치해야 합니다.
- HTTP 헤더 - 요청 확인을 위한 페이로드 해시 값을 포함하는 요청의 HTTP 헤더 이름입니다. 예를 들어 GitHub의 경우 요청 헤더는 "X-Hub-Signature"입니다.
- 비밀 - 비밀은 들어오는 요청을 확인하는 데 사용되는 페이로드 해시를 구문 분석하는 데 사용됩니다(선택 사항임). 웹후크를 만드는 데 비밀을 사용한 경우 동일한 비밀 키를 제공해야 합니다.
YAML 파이프라인에 호출
webhooks된 새 리소스 종류가 도입되었습니다. 웹후크 이벤트를 구독하려면 파이프라인에서 웹후크 리소스를 정의하고 들어오는 웹후크 서비스 연결을 가리킵니다. 또한 JSON 페이로드 데이터를 기반으로 웹후크 리소스에 대한 추가 필터를 정의하여 각 파이프라인에 대한 트리거를 추가로 사용자 지정할 수 있으며 작업에서 변수 형식으로 페이로드 데이터를 사용할 수 있습니다.
resources:
webhooks:
- webhook: MyWebhookTrigger ### Webhook alias
connection: MyWebhookConnection ### Incoming webhook service connection
filters:
- path: repositoryName ### JSON path in the payload
value: maven-releases ### Expected value in the path provided
- path: action
value: CREATED
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
script: |
Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
- 들어오는 웹후크 서비스 연결에서 웹후크 이벤트를 수신할 때마다 웹후크 이벤트를 구독하는 모든 파이프라인에 대해 새 실행이 트리거됩니다.
YAML 리소스 트리거 문제 지원 및 추적 가능성
파이프라인 트리거가 예상대로 실행되지 않을 때 혼동될 수 있습니다. 이를 더 잘 이해하기 위해 파이프라인 정의 페이지에 트리거가 실행되지 않는 이유에 대한 정보가 표시되는 '트리거 문제'라는 새 메뉴 항목을 추가했습니다.
리소스 트리거는 두 가지 이유로 실행되지 못할 수 있습니다.
제공된 서비스 연결의 원본이 잘못되었거나 트리거에 구문 오류가 있는 경우 트리거가 전혀 구성되지 않습니다. 오류로 표시됩니다.
트리거 조건이 일치하지 않으면 트리거가 실행되지 않습니다. 이 경우 조건이 일치하지 않는 이유를 이해할 수 있도록 경고가 표시됩니다.
파이프라인에 영향을 주는 라이브 사이트 인시던트에 대한 배너
파이프라인 페이지에 파이프라인에 영향을 미칠 수 있는 지역에서 진행 중인 인시던트를 사용자에게 경고하는 경고 배너를 추가했습니다.
Azure Artifacts
UI에서 조직 범위 피드를 만드는 기능
고객이 온-프레미스 및 호스티드 서비스 모두에 대한 웹 UI를 통해 조직 범위 피드를 만들고 관리할 수 있는 기능을 다시 제공하고 있습니다.
이제 아티팩> 트 - 피드 만들기로 이동하고 범위 내에서 피드 유형을 선택하여 UI를 통해 조직 범위 피드를 만들 수 있습니다.
나머지 Azure DevOps 제품에 맞춰 프로젝트 범위 피드를 사용하는 것이 좋지만 UI 및 다양한 REST API를 통해 조직 범위 피드를 다시 만들고, 관리하고, 사용할 수 있습니다. 자세한 내용은 피드 설명서를 참조하세요.
다음 단계
참고 항목
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
아론 할버그