Slack용 새 분석 보고서 및 Azure Boards 앱 - 스프린트 155 업데이트

Azure DevOps의 스프린트 155 업데이트에서 새로운 Azure Boards 보고서를 도입하여 중요한 팀 메트릭을 더 쉽게 추적할 수 있게 되었습니다. 새로운 보고서는 보드, 백로그 및 스프린트 허브의 분석 탭에서 볼 수 있습니다. 이러한 보고서는 완전 대화형이며 필요에 맞춰 조정할 수 있습니다.

또한 Slack용 Azure Boards 앱도 새롭게 출시하게 되었습니다. 이 앱으로 Slack 채널에서 작업 항목 활동을 모니터링하고 작업 항목을 생성할 수 있습니다.

자세한 내용은 아래 기능 목록을 확인하세요.

Azure DevOps의 새로운 기능

기능

일반:

• GitHub 협력자를 Azure DevOps로 초대

Azure Boards:

• 세 가지 새로운 Azure Boards 보고서로 팀 현황에 대한 인사이트 얻기
• Slack용 Azure Boards 앱
• 작업 보드 열 사용자 지정
• 백로그에서 완료된 자식 작업 항목을 표시 또는 숨기도록 토글
• 보드, 백로그, 쿼리 및 스프린트를 빠른 검색 상자에서 검색
• 작업 항목을 태깅할 때 가장 최근 태그 표시

Azure Repos:

• 향상된 코드 검색 필터링 옵션
• 끌어오기 요청에 대한 코드 검사 메트릭 및 분기 정책
• 끌어오기 요청의 주석 알림 필터링
• 끌어오기 요청 주석용 서비스 후크

Azure Artifacts:

• 공개 피드에서 패키지를 공개 공유하기(미리 보기)

Azure Pipelines:

   다단계 YAML 파이프라인

• 다단계 YAML 파이프라인의 승인
• YAML 편집기의 파이프라인 변수 관리
• YAML 파이프라인의 새롭게 미리 정의된 변수
• 다단계 YAML 파이프라인 실행에서 단계 취소
• 각 작업에 정확한 풀 정보 표시
• 작업 항목을 다단계 YAML 파이프라인에 연결
• 새로운 분기용 CI 트리거
• 파이프라인 캐싱(공개 미리 보기)

  호스트된 VM

• 호스트된 파이프라인 이미지 업데이트
• 단일 호스트형 풀

Kubernetes

• KubernetesManifest 작업의 베이킹 옵션인 kustomize 및 kompose
• HelmDeploy 작업의 클러스터 관리 자격 증명 지원

테스트

• 신뢰도 낮음 테스트 관리를 제품에서 지원

  Azure 환경

• Azure Portal의 WebApp용 배포 센터 개선
• 가상 머신용 DevOps 프로젝트 개선

통합

• Azure Pipelines를 사용한 Terraform 통합
• Google Analytics와의 통합

일반

GitHub 협력자를 Azure DevOps로 초대

이제 GitHub ID로 로그인할 때 GitHub에서 Azure DevOps로 협력자를 초대할 수 있습니다. Project 홈페이지 및 조직 설정의 사용자 페이지에서 다른 GitHub 사용자를 검색하고 초대할 수 있습니다.

이 기능은 조직 설정의 정책 아래에 있는 설정을 통해 기존 조직에 대해 사용하도록 설정해야 합니다. 그러나 GitHub ID로 만든 조직에는 기본적으로 설정되어 있습니다.

참고 항목

정책이 켜져 있더라도 GitHub가 아닌 사용자는 이 기능을 사용할 수 없습니다.

팀 구성원을 초대하는 방법에 대한 자세한 내용은 여기에서 설명서를 참조하세요. GitHub를 사용하여 Azure DevOps에 연결하는 데 문제가 있는 경우 GitHub 사용자 FAQ 인증 및 초대 문제 해결을 참조 하세요.

Azure Boards

세 가지 새로운 Azure Boards 보고서로 팀 현황에 대한 인사이트 얻기

볼 수 없는 항목은 수정할 수 없습니다. 따라서 작업 프로세스의 상태와 상태를 주의 깊게 관찰하려고 합니다. 이러한 보고서를 사용하면 Azure Boards에서 최소한의 노력으로 중요한 메트릭을 더 쉽게 추적할 수 있습니다.

세 가지 새로운 대화형 보고서는 번다운, CFD(누적 흐름 다이어그램 ) 및 속도입니다. 새 분석 탭에서 보고서를 볼 수 있습니다.

스프린트 번다운, 작업 흐름 및 팀 속도와 같은 메트릭은 팀의 진행 상황을 파악하고 다음과 같은 질문에 답변하는 데 도움이 됩니다.

• 이 스프린트에서 남은 작업은 얼마인가요? 우리는 그것을 완료하기 위해 궤도에 있습니까?
• 개발 프로세스에서 가장 오래 걸리는 단계는 무엇인가요? 우리는 그것에 대해 뭔가를 할 수 있습니까?
• 이전 반복에 따라 다음 스프린트를 위해 얼마나 많은 작업을 계획해야 하나요?

참고 항목

헤더에 이전에 표시된 차트가 이러한 향상된 보고서로 대체되었습니다.

새 보고서는 완전히 대화형이며 필요에 맞게 조정할 수 있습니다. 각 허브의 분석 탭에서 새 보고서를 찾을 수 있습니다.

• 번다운 차트는 스프린트 허브에서 찾을 수 있습니다.

  

• CFD 및 속도 보고서는 관련 카드 클릭하여 보드 및 백로그 아래의 분석 탭에서 액세스할 수 있습니다.

  

새 보고서를 사용하면 팀에 대한 더 많은 제어 및 정보를 사용할 수 있습니다. 다음 몇 가지 예를 참조하세요.

• 스프린트 번다운 및 속도 보고서는 작업 항목 수 또는 재기본 작업 합계를 사용하도록 설정할 수 있습니다.
• 프로젝트 날짜에 영향을 주지 않고 스프린트 번다운의 기간을 조정할 수 있습니다. 따라서 팀에서 일반적으로 각 스프린트 계획의 첫 날을 보내는 경우 이제 차트를 일치하여 이를 반영할 수 있습니다.
• 이제 번다운 차트에는 주말을 보여 주는 워터마크가 있습니다.
• CFD 보고서를 사용하면 디자인과 같은 보드 열을 제거하여 팀이 제어할 수 있는 흐름에 더 집중할 수 있습니다.

다음은 스토리 백로그의 지난 30일 동안의 흐름을 보여 주는 CFD 보고서의 예입니다.

이제 모든 백로그 수준에 대해 속도 차트를 추적할 수 있습니다. 예를 들어 이제 기능과 에픽을 모두 추가할 수 있는 반면 이전 차트에서는 요구 사항만 지원했습니다. 다음은 기능 백로그의 마지막 6회 반복에 대한 속도 보고서의 예입니다.

Slack용 Azure Boards 앱

Slack용 새 Azure Boards 앱을 발표하게 되어 기쁩니다. 이 앱을 사용하면 작업 항목 활동을 모니터링하고 Slack 채널에서 작업 항목을 만들 수 있습니다.

이 앱을 사용하면 만들기 및 작업 항목 업데이트를 포함한 이벤트 구독을 설정 및 관리하고 Slack 채널에서 이러한 이벤트에 대한 알림을 받을 수 있습니다. Slack 채널의 대화를 사용하여 작업 항목을 만들 수 있습니다. 또한 작업 항목이 할당될 때 개인 알림이 표시됩니다. 또한 작업 항목 URL에 대한 미리 보기를 통해 토론을 시작할 수 있습니다.

Azure Boards 앱을 설치하려면 여기를 클릭합니다.

작업표 열 사용자 지정

작업 보드에서 열을 사용자 지정할 수 있는 옵션을 추가했음을 알려드리게 되어 기쁩니다. 이제 열을 추가, 제거, 이름 바꾸기 및 다시 정렬할 수 있습니다.

작업 보드에서 열을 구성하려면 열 옵션으로 이동합니다.

이 기능은 개발자 커뮤니티의 제안에 따라 우선 순위가 지정되었습니다.

백로그에서 완료된 자식 작업 항목을 표시 또는 숨기도록 토글

여러 번 백로그를 구체화할 때 완료되지 않은 항목만 보려고 합니다. 이제 백로그에서 완료된 자식 항목을 표시하거나 숨길 수 있습니다.

토글이 켜지면 모든 자식 항목이 완료된 상태로 표시됩니다. 토글이 꺼져 있으면 완료된 상태의 모든 자식 항목이 백로그에서 숨겨집니다.

보드, 백로그, 쿼리 및 스프린트를 빠른 검색 상자에서 검색

이제 Azure Boards에서 검색 상자를 활성화하여 검색 상자에서 최근에 방문한 보드, 백로그, 쿼리 및 스프린트에 쉽게 액세스할 수 있습니다.

또한 검색 상자에 보드 이름을 입력하여 프로젝트 전체에서 보드, 백로그, 쿼리 및 스프린트를 검색할 수 있습니다. 지금, 당신에게 가장 중요한 보드는 단지 클릭 거리에 있습니다.

작업 항목을 태깅할 때 가장 최근 태그 표시

작업 항목에 태그를 지정할 때 자동 완성 옵션은 이제 가장 최근에 사용한 태그를 최대 5개까지 표시합니다. 이렇게 하면 작업 항목에 올바른 정보를 더 쉽게 추가할 수 있습니다.

Azure Repos

향상된 코드 검색 필터링 옵션

이전에는 코드 검색에서 comment: 및 def:와 같은 39개의 코드 검색 필터를 지원했습니다. 데이터에는 사용되지 않는 필터가 많이 있으므로 몇 가지 필터를 제거하고 다른 필터를 병합하는 것이 좋습니다. 이 업데이트를 통해 필터 수를 19개로 줄입니다. 이렇게 하면 코드 검색 쿼리를 보다 효율적으로 만들고 인터페이스의 혼란을 줄이는 데 도움이 됩니다.

예를 들어, func: maps to method:, 즉 func:Account관리 검색하면 결과가 method:Account관리 매핑됩니다. 마찬가지로 macrodef: 및 macroref: 매크로에 매핑됩니다. 반면에 union: 및 org: 같은 필터는 사용 부족으로 인해 더 이상 사용되지 않습니다.

끌어오기 요청에 대한 코드 검사 메트릭 및 분기 정책

이제 PR(끌어오기 요청) 보기 내의 변경 내용에 대한 코드 검사 메트릭을 볼 수 있습니다. 이렇게 하면 자동화된 테스트를 통해 변경 내용을 적절하게 테스트할 수 있습니다. 적용 범위 상태 PR 개요에 주석으로 표시됩니다. 파일 차이 보기에서 변경된 모든 코드 줄에 대한 검사 정보의 세부 정보를 볼 수 있습니다.

또한 리포지토리 소유자는 이제 코드 검사 정책을 설정하고 테스트되지 않은 대규모 변경 내용이 분기에 병합되지 않도록 방지할 수 있습니다. 원하는 검사 임계값은 리포지토리의 루트에 azurepipelines-coverage.yml 검사 설정 파일에서 정의할 수 있으며, 적용 범위 정책은 Azure Repos의 추가 서비스 기능에 대한 기존 구성 분기 정책을 사용하여 정의할 수 있습니다.

끌어오기 요청의 주석 알림 필터링

끌어오기 요청의 주석은 종종 알림으로 인해 많은 노이즈를 생성할 수 있습니다. 댓글 사용 기간, 메모 작성자, 삭제된 메모, 멘션 사용자, 끌어오기 요청 작성자, 대상 분기 및 스레드 참가자별로 구독하는 댓글 알림을 필터링할 수 있는 사용자 지정 구독을 추가했습니다. 오른쪽 위 모서리에 있는 사용자 아이콘을 클릭하고 사용자 설정으로 이동하여 이러한 알림 구독을 만들 수 있습니다.

끌어오기 요청 주석용 서비스 후크

이제 리포지토리 및 대상 분기를 기반으로 끌어오기 요청에서 주석에 대한 서비스 후크를 만들 수 있습니다.

Azure Artifacts

공개 피드에서 패키지를 공개 공유하기(미리 보기)

이제 퍼블릭 피드 내에 패키지를 만들고 저장할 수 있습니다. 퍼블릭 피드 내에 저장된 패키지는 조직에 있든 아니든, Azure DevOps 조직에 로그인하든 관계없이 인증 없이 인터넷의 모든 사용자가 사용할 수 있습니다. 피드 설명서에서 퍼블릭 피드에 대해 자세히 알아보거나 패키지를 공개적으로 공유하기 위한 자습서로 바로 이동합니다.

Azure Pipelines

KubernetesManifest 작업의 베이킹 옵션인 kustomize 및 kompose

kustomize (Kubernetes sig-cli의 일부)를 사용하면 템플릿이 없는 원시 YAML 파일을 여러 용도로 사용자 지정할 수 있으며 원래 YAML은 그대로 유지됩니다. kubernetesManifest 작업의 배포 작업에 사용되는 매니페스트 파일을 생성하는 데 kustomization.yaml 파일이 포함된 폴더를 사용할 수 있도록 KubernetesManifest 작업의 베이킹 작업 아래에 kustomize 옵션이 추가되었습니다.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose 는 Docker Compose 파일을 Kubernetes 리소스로 변환합니다.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

HelmDeploy 작업의 클러스터 관리 자격 증명 지원

이전에는 HelmDeploy 작업에서 배포에 클러스터 사용자 자격 증명을 사용했습니다. 이로 인해 대화형 로그인 프롬프트가 표시되고 Azure Active Directory 기반 RBAC 사용 클러스터에 대한 파이프라인이 실패했습니다. 이 문제를 해결하기 위해 클러스터 사용자 자격 증명 대신 클러스터 관리자 자격 증명을 사용할 수 있는 검사box를 추가했습니다.

YAML 편집기의 파이프라인 변수 관리

YAML 편집기에서 파이프라인 변수를 관리하는 환경을 업데이트했습니다. YAML 파이프라인에서 변수를 추가하거나 업데이트하기 위해 더 이상 클래식 편집기로 이동하지 않아도 됩니다.

YAML 파이프라인의 새롭게 미리 정의된 변수

변수를 사용하면 주요 데이터 비트를 파이프라인의 다양한 부분에 편리하게 가져올 수 있습니다. 이 업데이트를 통해 배포 작업에 미리 정의된 몇 가지 변수를 추가했습니다. 이러한 변수는 시스템에서 자동으로 설정되고 특정 배포 작업으로 범위가 지정되며 읽기 전용입니다.

• Environment.Id - 환경의 ID입니다.
• Environment.Name - 배포 작업의 대상이 되는 환경의 이름입니다.
• Environment.ResourceId - 배포 작업의 대상이 되는 환경의 리소스 ID입니다.
• Environment.ResourceName - 배포 작업의 대상이 되는 환경의 리소스 이름입니다.

작업 항목을 다단계 YAML 파이프라인에 연결

현재 작업 항목을 클래식 빌드와 자동으로 연결할 수 있습니다. 그러나 YAML 파이프라인에서는 불가능했습니다. 이 업데이트를 통해 이 격차를 해결했습니다. 지정된 분기의 코드를 사용하여 파이프라인을 성공적으로 실행하면 Azure Pipelines는 해당 코드의 커밋을 통해 유추되는 모든 작업 항목과 실행을 자동으로 연결합니다. 작업 항목을 열면 해당 작업 항목에 대한 코드가 빌드된 실행을 볼 수 있습니다. 이를 구성하려면 파이프라인의 설정 패널을 사용합니다.

다단계 YAML 파이프라인 실행에서 단계 취소

다단계 YAML 파이프라인을 실행할 때 진행 중인 단계의 실행을 취소할 수 있습니다. 이는 스테이지가 실패할 것임을 알고 있거나 시작하려는 다른 실행이 있는 경우에 유용합니다. 또한 이 기능은 향후 실패한 스테이지 재시도를 지원하기 위한 필수 구성 요소이기도 합니다.

다단계 YAML 파이프라인의 승인

다단계 YAML 파이프라인을 계속 개선하고 있으며, 이제 이러한 파이프라인에 수동 승인을 추가할 수 있습니다. 인프라 소유자는 파이프라인의 단계가 배포되기 전에 환경을 보호하고 수동 승인을 요청할 수 있습니다. 인프라(환경)와 애플리케이션(파이프라인) 소유자 간의 역할을 완전히 분리하면 특정 파이프라인에서 배포에 대한 수동 로그오프를 보장하고 환경에 모든 배포에서 동일한 검사 적용하는 중앙 제어를 얻을 수 있습니다.

파이프라인이 개발 배포를 실행하면 단계 시작 시 승인이 중지됩니다.

호스트된 파이프라인 이미지 업데이트

여러 Azure Pipelines 호스팅 VM 이미지를 업데이트했습니다. 최신 릴리스에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 이 업데이트의 일부로 다음과 같은 변경 내용이 추가되었습니다.

• VS2017 및 VS2019의 경우:

  • Azul Java 7 추가됨
  • 호스트 커널 버전과 일치하도록 고정된 캐시된 Docker 이미지
  • Az PowerShell 모듈 v2.3.2 추가됨
  • v5.0.0에 고정된 Mercurial
  • Python을 버전 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4로 업데이트했습니다.
  • 이식 가능한 클래스 라이브러리가 추가됨(VS 2019에만 해당)
  • Rust 기본 경로 및 환경 변수 변경됨

• Ubuntu 16.04의 경우:

  • 항상 최신을 끌어오도록 helm이 업데이트됨(v2.14.0에서 더 이상 고정되지 않음)
  • 인기 있는 여러 Docker 컨테이너가 추가됨
  • Python을 버전 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4로 업데이트했습니다.
  • Rust 기본 경로 및 환경 변수 변경됨

• 모든 이미지에 대해 이미지 버전에 대한 환경 변수를 추가 ImageVersion 했습니다.

특정 이미지에 사용할 수 있는 도구의 전체 목록은 설정 > 에이전트 풀 > 세부 정보로 이동합니다.

가상 머신용 DevOps 프로젝트 개선

이 업데이트에서는 위치별 할당량 제한을 준수하지 않는 VM을 포함하도록 DevOps Projects VM(가상 머신) 워크플로를 향상시켰습니다. 이전에는 이름 및 제품별로 VM을 선택해야 했습니다. 이제 비용/월, RAM, 데이터 디스크 등과 같은 VM 제품에 대한 자세한 정보가 포함된 주문형 보기를 사용할 수 있습니다. 이렇게 하면 필요한 가상 머신을 더 쉽게 선택할 수 있습니다.

단일 호스트형 풀

마지막 스프린트에서는 호스트, 호스트된 VS2017, Hosted Ubuntu 1604, Hosted Windows 2019를 VS2019, Hosted macOS 및 Hosted macOS High Sierra와 같은 다른 모든 호스트된 풀을 대체하기 위해 Azure Pipelines라는 새 호스트 풀을 출시한다고 전달했습니다. 이 변경 내용은 이 릴리스에서 구현됩니다.

호스트된 풀이 여러 개 있으면 때때로 혼란스러울 수 있습니다. 동시성이 사용되는 위치를 정확하게 파악할 수 없습니다. 예를 들어 병렬 작업 10개의 동시성이 있는 경우 각 호스트된 풀에 10개의 가상 에이전트가 표시되며 이는 정확하지 않습니다. 작업이 모든 유휴 에이전트와 함께 특정 호스트된 풀(예: 호스트된 VS2017)에서 대기하는 경우 동시성이 다른 호스트된 풀(예: 호스트된 Ubuntu 1604)에서 사용된다는 사실을 깨닫지 못하고 Azure Pipelines 서비스가 손상되었다고 생각할 수 있습니다.

이 변경으로 해당 풀에서 실행 중인 작업 수를 정확하게 파악할 수 있는 호스트된 풀이 하나 표시됩니다. 앞으로 몇 번의 스프린트에서 이러한 변경 사항을 롤아웃할 계획입니다. 이전 호스팅 풀에서 새 통합 풀의 적절한 이미지로 작업을 자동으로 리디렉션하기 때문에 파이프라인을 변경할 필요가 없습니다.

각 작업에 정확한 풀 정보 표시

이전에는 행렬을 사용하여 작업 또는 변수를 확장하여 풀을 식별할 때 로그 페이지에 올바른 풀 정보를 표시하는 데 문제가 있었습니다. 이 업데이트를 통해 특정 작업에 대해 잘못된 풀 정보가 표시되는 문제를 해결했습니다.

신뢰도 낮음 테스트 관리를 제품에서 지원

테스트 실패는 테스트 중인 변경 내용과 관련이 없을 수 있으므로 Flaky 테스트는 개발자의 생산성에 영향을 줄 수 있습니다. 또한 배송된 코드의 품질에 영향을 미칠 수 있습니다. 이것이 바로 제품 내 지원에서 벗겨진 테스트 관리를 추가한 이유입니다. 이 기능은 검색, 보고 및 해결을 통해 종단 간 수명 주기를 지원합니다. Flaky 테스트 관리는 시스템 및 사용자 지정 검색을 지원합니다.

시스템 검색은 VSTest 작업 다시 실행 기능을 통해 사용할 수 있습니다. 가연성 테스트는 소스 코드 또는 실행 환경에 변경 내용이 없는 경우에도 통과 또는 실패와 같은 다양한 결과를 제공하는 테스트입니다. 동일한 분기에 대한 테스트의 모든 추가 실행도 확인되고 표시되지 않을 때까지 벗겨진 것으로 표시됩니다. API를 사용하여 사용자 지정 검색 메커니즘을 연결할 수도 있습니다. 테스트가 flaky로 식별되면 파이프라인의 컨텍스트 내 테스트 보고서에서 세부 정보를 가져올 수 있습니다. 그런 다음, 벗겨진 테스트가 파이프라인 오류에 영향을 주는지 여부를 결정할 수 있습니다. 기본적으로 벗겨진 테스트 정보는 추가 메타 데이터로 사용할 수 있습니다.

다음은 테스트 요약이 포함된 보고서의 예입니다.

벗겨진 테스트 관리에 대한 자세한 내용은 여기 설명서를 참조하세요.

Azure Portal의 WebApp 배포 센터 개선 사항

여러 아티팩트가 있는 파이프라인을 지원하여 Azure Portal에서 WebApp용 배포 센터를 개선했습니다. 이제 Azure Pipelines의 기본이 아닌 아티팩트가 웹앱에 배포되면 Azure Portal에서 관련 세부 정보를 가져옵니다. 또한 배포된 리포지토리에 대한 딥 링크를 통해 Azure Portal에서 리포지토리로 직접 이동합니다. 리포지토리는 Azure Repos 또는 GitHub에서 호스트할 수 있습니다.

새로운 분기용 CI 트리거

새 분기가 만들어지고 분기가 변경되지 않을 때 CI 빌드를 트리거하지 않는 긴 보류 중인 요청이었습니다. 다음 예를 살펴 보십시오.

• 웹 인터페이스를 사용하여 기존 분기를 기반으로 새 분기를 만듭니다. 그러면 분기 필터가 새 분기의 이름과 일치하는 경우 새 CI 빌드가 즉시 트리거됩니다. 기존 분기와 비교할 때 새 분기의 콘텐츠가 동일하기 때문에 원치 않습니다.
• 앱과 문서라는 두 개의 폴더가 있는 리포지토리가 있습니다. "앱"에 맞게 CI에 대한 경로 필터를 설정합니다. 즉, 변경 내용이 문서에 푸시된 경우 새 빌드를 만들지 않습니다. 로컬로 새 분기를 만들고, 문서를 변경한 다음, 해당 분기를 서버로 푸시합니다. 새 CI 빌드를 트리거하는 데 사용했습니다. docs 폴더에서 변경 내용을 찾지 말라고 명시적으로 요청했으므로 이는 원치 않습니다. 그러나 새 분기 이벤트를 처리하는 방식 때문에 앱 폴더도 변경된 것처럼 보입니다.

이제 이러한 문제를 해결하기 위해 새 분기의 CI를 처리하는 더 나은 방법이 있습니다. 새 분기를 게시할 때 해당 분기에서 새 커밋을 명시적으로 찾고 경로 필터와 일치하는지 여부를 검사.

Azure Pipelines를 사용한 Terraform 통합

Terraform은 인프라를 안전하고 효율적으로 개발, 변경 및 버전 관리하기 위한 오픈 소스 도구입니다. Terraform은 API를 선언적 구성 파일로 코딩하여 고급 구성 언어를 사용하여 인프라를 정의하고 프로비전할 수 있도록 합니다. Terraform 확장을 사용하여 Azure, AWS(Amazon Web Services) 및 GCP(Google Cloud Platform)와 같은 모든 주요 인프라 공급자에서 리소스를 만들 수 있습니다.

Terraform 확장에 대한 자세한 내용은 여기 설명서를 참조하세요.

Google Analytics와의 통합

Google Analytics 실험 프레임워크를 사용하면 웹 사이트 또는 앱에 대한 거의 모든 변경 또는 변형을 테스트하여 특정 목표에 미치는 영향을 측정할 수 있습니다. 예를 들어 사용자가 완료하려는 활동(예: 구매, 뉴스레터 등록) 및/또는 개선하려는 메트릭(예: 수익, 세션 기간, 반송률)이 있을 수 있습니다. 이러한 활동을 통해 기능 성능에 미치는 직접적인 영향을 기반으로 구현할 가치가 있는 변경 내용을 식별할 수 있습니다.

Azure DevOps에 대한 Google Analytics 실험 확장은 빌드 및 릴리스 파이프라인에 실험 단계를 추가하므로 Azure Pipelines의 모든 DevOps 이점을 확보하면서 지속적으로 실험을 관리하여 빠른 속도로 지속적으로 반복, 학습 및 배포할 수 있습니다.

Marketplace에서 Google Analytics 실험 확장을 다운로드할 수 있습니다.

파이프라인 캐싱(공개 미리 보기)

파이프라인 캐싱을 사용하면 패키지 복원 또는 종속성 컴파일과 같은 장기 실행 작업의 결과를 저장하고 파이프라인의 다음 실행 중에 다시 복원할 수 있습니다. 이로 인해 빌드 속도가 빨라질 수 있습니다.

자세한 내용은 여기에서 전체 공지 사항과 함께 블로그 게시물을 참조하세요.

파이프라인 변수 그룹 및 변수 관리 명령

파이프라인 변수 및 변수 그룹을 수동으로 설정해야 하므로 YAML 기반 파이프라인을 한 프로젝트에서 다른 프로젝트로 이식하는 것은 어려울 수 있습니다. 그러나 파이프라인 변수 그룹 및 변수 관리 명령을 사용하면 이제 파이프라인 변수 및 변수 그룹의 설정 및 관리를 스크립팅할 수 있으며, 이를 통해 버전을 제어할 수 있으므로 한 프로젝트에서 다른 프로젝트로 파이프라인을 이동하고 설정하는 지침을 쉽게 공유할 수 있습니다.

PR 분기에 대해 파이프라인 실행

PR을 만들 때 변경 내용이 대상 분기에서 파이프라인 실행을 중단시킬 수 있는지 확인하는 것이 어려울 수 있습니다. 그러나 파이프라인 실행을 트리거하거나 PR 분기에 대한 빌드를 큐에 대기하는 기능을 사용하면 이제 대상 파이프라인에 대해 실행하여 변경 내용의 유효성을 검사하고 시각화할 수 있습니다. 자세한 내용은 az pipelines run 및 az pipelines build queue 명령 설명서를 참조하세요.

첫 번째 파이프라인 실행 건너뛰기

파이프라인을 만들 때 인프라가 준비되지 않았거나 변수/변수 그룹을 만들고 업데이트해야 하는 등 다양한 이유로 인해 오류가 발생할 수 있으므로 YAML 파일을 만들고 커밋하고 파이프라인 실행을 트리거하지 않으려는 경우가 있습니다. 이제 Azure DevOps CLI를 사용하여 --skip-first-run 매개 변수를 포함하여 파이프라인을 만들 때 첫 번째 자동화된 파이프라인 실행을 건너뛸 수 있습니다. 자세한 내용은 az pipeline create 명령 설명서를 참조하세요.

서비스 엔드포인트 명령 향상

서비스 엔드포인트 CLI 명령은 Azure rm 및 github 서비스 엔드포인트 설정 및 관리만 지원합니다. 그러나 이 릴리스에서 서비스 엔드포인트 명령을 사용하면 파일을 통해 구성을 제공하여 서비스 엔드포인트를 만들 수 있으며, 이러한 유형의 서비스 엔드포인트를 만드는 데 일류 지원을 제공하는 az devops service-endpoint github 및 az devops service-endpoint azurerm과 같은 최적화된 명령을 제공합니다. 자세한 내용은 명령 설명서를 참조하세요.

다음 단계

참고 항목

이러한 기능은 향후 2~3주 동안 출시될 예정입니다.

Azure DevOps로 이동하여 살펴보세요.

Azure DevOps로 이동

피드백을 제공하는 방법

이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 피드백 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.

Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.

감사합니다,

샘 구켄하이머