새로운 스프린트 번다운 위젯 및 향상된 파이프라인 보안 - 스프린트 160 업데이트
Azure DevOps의 스프린트 160 업데이트 에서 스토리 포인트, 작업 수 및 사용자 지정 필드를 합산하여 불타는 것을 지원하는 새로운 스프린트 번다운 위젯을 추가했습니다. 또한 액세스 토큰의 scope 제한하여 파이프라인 보안을 개선했습니다.
자세한 내용은 아래 기능 목록을 확인하세요.
Azure DevOps의 새로운 기능
기능
Azure Repos:
Azure Pipelines:
- 다단계 파이프라인 UX
- Kubernetes 환경에 대한 카나리아 배포 전략 오케스트레이션
- YAML 파이프라인에 대한 승인 정책
- ACR을 일류 파이프라인 리소스로
- 파이프라인 리소스 메타 데이터를 미리 정의된 변수로
- 파이프라인 및 ACR 리소스에 대한 추적 가능성
- YAML 파이프라인에서 간소화된 리소스 권한 부여
- 액세스 토큰의 scope 제한하여 파이프라인 보안 개선
- 아티팩트 검사 평가
- 자동화된 테스트 오류 메시지의 Markdown 지원
- YAML에서 cron 일정 진단
- ARM 템플릿 배포 작업으로 업데이트
- 서비스 연결에 대한 프로젝트 수준 보안
- Ubuntu 18.04 풀
- KubernetesManifest 작업의 서비스 메시 인터페이스 기반 카나리아 배포
- 환경의 ReviewApp
Azure Artifacts:
보고:
Wiki:
Azure Repos
리포지토리 간 분기 정책 관리
분기 정책은 중요한 분기를 보호하는 데 도움이 되는 Azure Repos 강력한 기능 중 하나입니다. 프로젝트 수준에서 정책을 설정하는 기능은 REST API에 있지만 이에 대한 사용자 인터페이스는 없습니다. 이제 관리자는 프로젝트의 모든 리포지토리에서 특정 분기 또는 기본 분기 정책을 설정할 수 있습니다. 예를 들어 관리자는 프로젝트의 모든 리포지토리에 있는 모든 기본 분기에 대해 수행된 모든 끌어오기 요청에 대해 최소 검토자 2명이 필요할 수 있습니다. 리포지토리 프로젝트 설정에서 분기 보호 추가 기능을 찾을 수 있습니다.
Azure Pipelines
다단계 파이프라인 UX
파이프라인을 관리하기 위해 업데이트된 사용자 환경에 대해 작업해 왔습니다. 이러한 업데이트를 통해 파이프라인은 Azure DevOps의 방향과 최신의 일관성을 경험할 수 있습니다. 또한 이러한 업데이트는 클래식 빌드 파이프라인과 다단계 YAML 파이프라인을 단일 환경으로 결합합니다. 예를 들어 다음 기능이 새 환경에 포함됩니다. 여러 단계 보기 및 관리, 파이프라인 실행 승인, 파이프라인이 아직 진행 중인 동안 로그에서 다시 스크롤하는 기능 및 파이프라인의 분기별 상태.
새로운 경험을 해 주신 모든 분들께 감사드립니다. 시도하지 않은 경우 미리 보기 기능에서 다단계 파이프라인 을 사용하도록 설정합니다. 다단계 파이프라인에 대한 자세한 내용은 여기 설명서를 참조 하세요 .
피드백 덕분에 지난 두 번의 업데이트에서 다음 사항을 해결했습니다.
- 폴더 보기의 검색 가능성.
- 로그 보기의 점프.
- 실행이 진행 중인 경우에도 이전 및 현재 작업의 로그를 쉽게 표시합니다.
- 로그를 검토할 때 작업 간을 더 쉽게 탐색할 수 있습니다.
참고
다음 업데이트에서는 모든 사용자에 대해 기본적으로 이 기능을 켤 계획입니다. 미리 보기를 옵트아웃할 수 있는 옵션이 계속 제공됩니다. 그 후 몇 주 후에 이 기능이 일반 공급됩니다.
Kubernetes 환경에 대한 카나리아 배포 전략 오케스트레이션
애플리케이션 업데이트를 지속적으로 업데이트할 때의 주요 이점 중 하나는 특정 마이크로 서비스에 대한 업데이트를 프로덕션으로 신속하게 푸시하는 기능입니다. 이를 통해 비즈니스 요구 사항의 변화에 신속하게 대응할 수 있습니다. 환경 은 배포 전략을 오케스트레이션하고 가동 중지 시간 릴리스를 용이하게 하는 일류 개념으로 도입되었습니다. 이전에는 단계를 한 번 순차적으로 실행하는 runOnce 전략을 지원했습니다. 다단계 파이프라인에서 카나리아 전략을 지원하면 이제 변경 내용을 작은 하위 집합으로 천천히 롤아웃하여 위험을 줄일 수 있습니다. 새 버전에 대한 신뢰도가 높아짐에 따라 인프라의 더 많은 서버에 배포를 시작하고 더 많은 사용자를 라우팅할 수 있습니다.
jobs:
- deployment:
environment: musicCarnivalProd
pool:
name: musicCarnivalProdPool
strategy:
canary:
increments: [10,20]
preDeploy:
steps:
- script: initialize, cleanup....
deploy:
steps:
- script: echo deploy updates...
- task: KubernetesManifest@0
inputs:
action: $(strategy.action)
namespace: 'default'
strategy: $(strategy.name)
percentage: $(strategy.increment)
manifests: 'manifest.yml'
postRouteTaffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Kuberenetes에 대한 카나리아 전략은 먼저 10% Pod를 사용하여 변경 내용을 배포한 다음, 20%로 변경한 후 RouteTraffic 이후 상태를 모니터링합니다. 모든 것이 잘되면 100 %로 승격됩니다.
환경에서 VM 리소스를 지원하고 여러 컴퓨터에서 롤링 배포 전략을 수행하는 방법에 대한 초기 피드백을 찾고 있습니다. 등록하려면 문의하세요.
YAML 파이프라인에 대한 승인 정책
YAML 파이프라인에서는 리소스 소유자가 제어하는 승인 구성을 따릅니다. 리소스 소유자는 리소스를 사용하는 단계가 시작되기 전에 리소스 및 승인을 위해 리소스 일시 중지를 사용하는 모든 파이프라인에 대한 승인을 구성합니다. SOX 기반 애플리케이션 소유자는 배포 요청자가 자체 배포를 승인하지 못하도록 제한하는 것이 일반적입니다.
이제 고급 승인 옵션을 사용하여 요청자가 승인하지 않아야 함, 사용자 하위 집합의 승인 필요 및 승인 시간 제한과 같은 승인 정책을 구성할 수 있습니다.
ACR을 일류 파이프라인 리소스로
파이프라인의 일부로 ACR(Azure Container Registry)에 게시된 컨테이너 이미지를 사용하고 새 이미지가 게시될 때마다 파이프라인을 트리거해야 하는 경우 ACR 컨테이너 리소스를 사용할 수 있습니다.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
또한 미리 정의된 변수를 사용하여 ACR 이미지 메타 데이터에 액세스할 수 있습니다. 다음 목록에는 파이프라인에서 ACR 컨테이너 리소스를 정의하는 데 사용할 수 있는 ACR 변수가 포함되어 있습니다.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
파이프라인 리소스 메타 데이터를 미리 정의된 변수로
파이프라인에서 YAML 파이프라인 리소스에 대해 미리 정의된 변수를 추가했습니다. 다음은 사용할 수 있는 파이프라인 리소스 변수 목록입니다.
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
파이프라인 및 ACR 리소스에 대한 추적 가능성
파이프라인 및 ACR 컨테이너 리소스가 파이프라인에서 사용될 때 전체 E2E 추적 가능성을 보장합니다. YAML 파이프라인에서 사용하는 모든 리소스에 대해 커밋, 작업 항목 및 아티팩트로 다시 추적할 수 있습니다.
파이프라인 실행 요약 보기에서 다음을 확인할 수 있습니다.
실행을 트리거한 리소스 버전입니다. 이제 다른 Azure 파이프라인 실행이 완료되거나 컨테이너 이미지가 ACR로 푸시될 때 파이프라인을 트리거할 수 있습니다.
파이프라인 에서 사용하는 커밋 입니다. 파이프라인에서 사용하는 각 리소스에 의한 커밋 분석도 확인할 수 있습니다.
파이프라인에서 사용하는 각 리소스와 연결된 작업 항목 입니다.
실행에서 사용할 수 있는 아티팩 트입니다.
환경의 배포 보기에서 환경에 배포된 각 리소스에 대한 커밋 및 작업 항목을 볼 수 있습니다.
YAML 파이프라인에서 간소화된 리소스 권한 부여
리소스는 파이프라인 외부에 있는 파이프라인에서 사용하는 모든 항목입니다. 리소스를 사용하려면 먼저 권한을 부여해야 합니다. 이전에는 YAML 파이프라인에서 권한 없는 리소스를 사용할 때 리소스 권한 부여 오류로 실패했습니다. 실패한 실행의 요약 페이지에서 리소스에 권한을 부여해야 했습니다. 또한 권한이 없는 리소스를 참조하는 변수를 사용하는 경우 파이프라인이 실패했습니다.
이제 리소스 권한 부여를 더 쉽게 관리할 수 있습니다. 실행에 실패하는 대신, 실행은 리소스를 사용하는 단계의 시작 부분에 있는 리소스에 대한 권한을 기다립니다. 리소스 소유자는 파이프라인을 보고 보안 페이지에서 리소스에 권한을 부여할 수 있습니다.
액세스 토큰의 scope 제한하여 파이프라인 보안 개선
Azure Pipelines에서 실행되는 모든 작업은 액세스 토큰을 가져옵니다. 액세스 토큰은 태스크 및 스크립트에서 Azure DevOps로 다시 호출하는 데 사용됩니다. 예를 들어 액세스 토큰을 사용하여 소스 코드를 얻거나, 로그를 업로드하거나, 결과, 아티팩트 테스트를 하거나, Azure DevOps에 REST를 호출합니다. 각 작업에 대해 새 액세스 토큰이 생성되고 작업이 완료되면 만료됩니다. 이 업데이트를 통해 다음과 같은 향상된 기능을 추가했습니다.
토큰이 팀 프로젝트 외부의 리소스에 액세스하지 못하도록 방지
지금까지 모든 파이프라인의 기본 scope 팀 프로젝트 컬렉션이었습니다. scope 클래식 빌드 파이프라인의 팀 프로젝트로 변경할 수 있습니다. 그러나 클래식 릴리스 또는 YAML 파이프라인에 대한 컨트롤이 없습니다. 이 업데이트를 통해 파이프라인에 구성된 내용에 관계없이 모든 작업이 프로젝트 범위 토큰을 받도록 강제하는 organization 설정이 도입되었습니다. 또한 프로젝트 수준에서 설정을 추가했습니다. 이제 만든 모든 새 프로젝트 및 organization 이 설정이 자동으로 설정됩니다.
참고
organization 설정은 프로젝트 설정을 재정의합니다.
기존 프로젝트 및 조직에서 이 설정을 설정하면 파이프라인이 액세스 토큰을 사용하여 팀 프로젝트 외부의 리소스에 액세스하는 경우 특정 파이프라인이 실패할 수 있습니다. 파이프라인 오류를 완화하려면 Project Build Service 계정에 원하는 리소스에 대한 액세스 권한을 명시적으로 부여할 수 있습니다. 이러한 보안 설정을 켜는 것이 좋습니다.
액세스 토큰에 대한 특정 권한 제거
기본적으로 액세스 토큰에 대한 여러 권한을 부여합니다. 이 권한 중 하나는 큐 빌드입니다. 이 업데이트를 통해 액세스 토큰에 대한 이 권한을 제거했습니다. 파이프라인에 이 권한이 필요한 경우 사용하는 토큰에 따라 프로젝트 빌드 서비스 계정 또는 프로젝트 컬렉션 빌드 서비스 계정에 명시적으로 부여할 수 있습니다.
아티팩트 검사 평가
이제 정책 집합을 정의하고 컨테이너 이미지 아티팩트를 위한 환경에서 정책 평가를 검사 추가할 수 있습니다. 파이프라인이 실행되면 환경을 사용하는 단계를 시작하기 전에 실행이 일시 중지됩니다. 지정된 정책은 배포되는 이미지에 대해 사용 가능한 메타데이터에 대해 평가됩니다. 정책이 성공하면 검사 통과하고 검사 실패하면 스테이지를 실패로 표시합니다.
자동화된 테스트 오류 메시지의 Markdown 지원
이제 자동화된 테스트에 대한 오류 메시지에서 Markdown을 지원합니다. 테스트 실행 및 테스트 결과 모두에 대한 오류 메시지의 서식을 쉽게 지정하여 가독성을 개선하고 Azure Pipelines의 오류 문제를 쉽게 해결할 수 있습니다. 지원되는 Markdown 구문은 여기에서 찾을 수 있습니다.
YAML에서 cron 일정 진단
YAML 파이프라인에서 일정을 지정하기 위한 cron 구문의 사용이 꾸준히 증가했습니다. 피드백을 들으면서 Azure Pipelines가 구문을 올바르게 처리했는지 여부를 확인하기가 어렵다고 들었습니다. 이전에는 예약된 실행의 실제 시간이 일정 문제를 디버그할 때까지 기다려야 했습니다. 분기/구문 오류를 진단하는 데 도움이 되도록 파이프라인에 대한 새 작업 메뉴를 추가했습니다. 실행 파이프라인 메뉴의 예약된 실행 은 cron 일정으로 오류를 진단하는 데 도움이 되도록 파이프라인에 대해 예정된 몇 가지 예약된 실행의 미리 보기를 제공합니다.
ARM 템플릿 배포 작업으로 업데이트
이전에는 ARM 템플릿 배포 작업에서 서비스 연결을 필터링하지 않았습니다. 더 광범위한 scope ARM 템플릿 배포를 수행하기 위해 더 낮은 scope 서비스 연결을 선택하는 경우 배포가 실패할 수 있습니다. 이제 선택한 배포 scope 따라 범위가 낮은 서비스 연결을 필터링하기 위해 서비스 연결 필터링을 추가했습니다.
서비스 연결에 대한 프로젝트 수준 보안
이 업데이트를 통해 서비스 연결에 대한 허브 수준 보안을 추가했습니다. 이제 사용자를 추가/제거하고, 역할을 할당하고, 모든 서비스 연결에 대한 중앙 집중식 위치에서 액세스를 관리할 수 있습니다.
Ubuntu 18.04 풀
이제 Azure Pipelines는 Ubuntu 18.04에서 작업 실행을 지원합니다. Ubuntu-18.04 이미지를 포함하도록 Microsoft 호스팅 Azure Pipelines 풀을 업데이트했습니다. 이제 YAML 파이프라인에서 풀을 참조 ubuntu-latest 할 때는 가 아니라 ubuntu-16.04를 의미 ubuntu-18.04 합니다. 명시적으로 사용하여 ubuntu-16.04 작업에서 16.04개의 이미지를 대상으로 지정할 수 있습니다.
KubernetesManifest 작업의 서비스 메시 인터페이스 기반 카나리아 배포
이전에는 KubernetesManifest 태스크에서 카나리아 전략을 지정했을 때 복제본이 안정적인 워크로드에 사용되는 복제본의 백분율과 같은 기준 및 카나리아 워크로드를 만듭니다. 이는 요청 수준에서 트래픽을 원하는 백분율로 분할하는 것과 정확히 동일하지 않았습니다. 이 문제를 해결하기 위해 KubernetesManifest 작업에 서비스 메시 인터페이스 기반 카나리아 배포에 대한 지원을 추가했습니다.
서비스 메시 인터페이스 추상화는 링커드 및 Istio와 같은 서비스 메시 공급자를 사용한 플러그 앤 플레이 구성을 허용합니다. 이제 KubernetesManifest 작업은 배포 전략의 수명 주기 동안 SMI의 TrafficSplit 개체를 안정적인 기준 및 카나리아 서비스에 매핑하는 작업을 제거합니다. 서비스 메시 평면의 요청에 따라 트래픽 분할 비율이 제어되므로 안정적인 기준선과 카나리아 간 트래픽의 원하는 백분율 분할이 더 정확합니다.
다음은 롤링 방식으로 SMI 기반 카나리아 배포를 수행하는 샘플입니다.
- deployment: Deployment
displayName: Deployment
pool:
vmImage: $(vmImage)
environment: ignite.smi
strategy:
canary:
increments: [25, 50]
preDeploy:
steps:
- task: KubernetesManifest@0
displayName: Create/update secret
inputs:
action: createSecret
namespace: smi
secretName: $(secretName)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy canary
inputs:
action: $(strategy.action)
namespace: smi
strategy: $(strategy.name)
trafficSplitMethod: smi
percentage: $(strategy.increment)
baselineAndCanaryReplicas: 1
manifests: |
manifests/deployment.yml
manifests/service.yml
imagePullSecrets: $(secretName)
containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
postRouteTraffic:
pool: server
steps:
- task: Delay@1
inputs:
delayForMinutes: '2'
환경의 ReviewApp
ReviewApp은 Git 리포지토리의 모든 끌어오기 요청을 동적 환경 리소스에 배포합니다. 검토자는 이러한 변경 내용이 기본 분기에 병합되고 프로덕션에 배포되기 전에 다른 종속 서비스와 함께 작동하는 방식을 확인할 수 있습니다. 이렇게 하면 reviewApp 리소스를 쉽게 만들고 관리하고 환경 기능의 모든 추적 가능성 및 진단 기능을 활용할 수 있습니다. reviewApp 키워드(keyword) 사용하여 리소스의 복제본을 만들고(환경의 기존 리소스를 기반으로 동적으로 새 리소스 만들기) 환경에 새 리소스를 추가할 수 있습니다.
다음은 환경에서 reviewApp을 사용하는 샘플 YAML 코드 조각입니다.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
피드 환경에 연결 업데이트됨
피드에 연결 대화 상자는 Azure Artifacts를 사용하는 진입로입니다. Azure DevOps의 피드에서 패키지를 푸시하고 끌어오도록 클라이언트 및 리포지토리를 구성하는 방법에 대한 정보가 포함되어 있습니다. 자세한 설정 정보를 추가하도록 대화 상자를 업데이트하고 지침을 제공하는 도구를 확장했습니다.
퍼블릭 피드는 이제 업스트림 지원과 함께 일반 공급됩니다.
공개 피드의 공개 미리 보기는 훌륭한 채택 및 피드백을 받았습니다. 이 업데이트에서는 추가 기능을 일반 공급으로 확장했습니다. 이제 프라이빗 피드에서 퍼블릭 피드를 업스트림 원본으로 설정할 수 있습니다. 프라이빗 피드와 프로젝트 범위 피드를 모두 업스트림 구성 파일을 간단하게 유지할 수 있습니다.
포털에서 프로젝트 범위 피드 만들기
퍼블릭 피드를 릴리스할 때 프로젝트 범위 피드도 릴리스했습니다. 지금까지는 REST API를 통해 또는 퍼블릭 피드를 만든 다음 프로젝트를 비공개로 설정하여 프로젝트 범위 피드를 만들 수 있습니다. 이제 필요한 권한이 있는 경우 모든 프로젝트에서 포털에서 직접 프로젝트 범위 피드를 만들 수 있습니다. 프로젝트인 피드와 피드 선택기에서 organization 범위가 지정된 피드를 확인할 수도 있습니다.
보고
요구한 모든 항목이 포함된 스프린트 번다운 위젯
새 스프린트 번다운 위젯은 스토리 포인트, 작업 수 또는 사용자 지정 필드의 합계를 합산하여 굽기를 지원합니다. 기능 또는 에픽에 대한 스프린트 번다운을 만들 수도 있습니다. 위젯은 평균 번다운, 완료율 및 증가 scope 표시합니다. 팀을 구성하여 동일한 dashboard 여러 팀의 스프린트 번다운을 표시할 수 있습니다. 이 모든 유용한 정보를 표시하면 dashboard 최대 10x10까지 크기를 조정할 수 있습니다.
이를 시도하려면 위젯 카탈로그에서 추가하거나 기존 스프린트 번다운 위젯에 대한 구성을 편집하고 지금 새 버전 사용해 보기 상자를 선택하여 추가할 수 있습니다.
참고
새 위젯은 분석을 사용합니다. Analytics에 액세스할 수 없는 경우 레거시 스프린트 번다운을 유지했습니다.
Wiki
위키 페이지를 편집하기 위한 동기 스크롤
이제 편집 창과 미리 보기 창 간에 동기 스크롤을 사용하여 위키 페이지를 더 쉽게 편집할 수 있습니다. 한쪽을 스크롤하면 자동으로 다른 쪽으로 스크롤하여 해당 섹션을 매핑합니다. 토글 단추를 사용하여 동기 스크롤을 사용하지 않도록 설정할 수 있습니다.
참고
동기 스크롤 토글의 상태는 사용자별로 저장되고 organization.
위키 페이지에 대한 페이지 방문
이제 위키 페이지의 페이지 방문에 대한 인사이트를 얻을 수 있습니다. REST API를 사용하면 지난 30일 동안 페이지 방문 정보에 액세스할 수 있습니다. 이 데이터를 사용하여 위키 페이지에 대한 보고서를 만들 수 있습니다. 또한 이 데이터를 데이터 원본에 저장하고 대시보드를 만들어 가장 많이 본 상위 n개 페이지와 같은 특정 인사이트를 얻을 수 있습니다.
또한 모든 페이지에서 지난 30일 동안 집계된 페이지 방문 횟수가 표시됩니다.
참고
페이지 방문은 지정된 사용자가 15분 간격으로 페이지 보기로 정의합니다.
다음 단계
참고
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
제프 비엘러
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기