다음을 통해 공유

단독 잠금 검사를 사용할 때 순차적 배포 지원

  • 아티클

이 스프린트에서는 순차적 배포를 지원하도록 Azure Pipelines에서 단독 잠금 검사 기능을 확장했습니다. 이제 한 환경에서 여러 실행을 큐에 대기하여 한 번에 하나만 실행할 수 있습니다.

자세한 내용은 다음 기능 설명을 확인하세요.

Azure Boards

Azure Pipelines

Azure Boards

작업 항목의 개발 섹션 에는 관련 커밋 및 끌어오기 요청 목록이 표시됩니다. 연결된 시간과 함께 커밋 또는 끌어오기 요청의 작성자를 볼 수 있습니다. 이 업데이트를 통해 작성자의 아바타가 보기에 잘못 표시되는 문제를 해결했습니다.

Azure Pipelines

단독 잠금 검사를 사용하는 경우에만 최신이 아닌 순차 배포 지원

YAML 파이프라인에서 검사는 보호된 리소스에 대한 단계 실행을 제어하는 데 사용됩니다. 사용할 수 있는 일반적인 검사 중 하나는 전용 잠금 검사. 이 검사 파이프라인에서 한 번만 실행할 수 있습니다. 여러 실행이 동시에 환경에 배포하려고 하면 검사 모든 이전 실행을 취소하고 최신 실행을 배포하도록 허용합니다.

이전 실행을 취소하는 것은 릴리스가 누적되고 이전 실행의 모든 코드 변경 내용을 포함하는 경우에 좋은 방법입니다. 그러나 코드 변경이 누적되지 않는 일부 파이프라인이 있습니다. 이 새로운 기능을 사용하면 모든 실행이 환경에 순차적으로 진행 및 배포되도록 허용하거나 이전 실행을 취소하고 최신 실행만 허용하는 이전 동작을 유지하도록 선택할 수 있습니다. 파이프라인 YAML 파일에서 라는 lockBehavior 새 속성을 사용하여 이 동작을 지정할 수 있습니다. 값은 sequential 모든 실행이 보호된 리소스에 대한 잠금을 순차적으로 획득한다는 것을 의미합니다. 값은 runLatest 최신 실행만 리소스에 대한 잠금을 획득한다는 것을 의미합니다.

배포 또는 runLatest에서 배타적 잠금 검사 sequential 사용하려면 다음 단계를 수행합니다.

  1. 환경(또는 다른 보호된 리소스)에서 배타적 잠금 검사 사용하도록 설정합니다.
  2. 파이프라인에 대한 YAML 파일에서 라는 lockBehavior새 속성을 지정합니다. 전체 파이프라인 또는 지정된 단계에 대해 지정할 수 있습니다.

스테이지에서 설정:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

파이프라인에서 다음을 설정합니다.

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

를 지정하지 않으면 로 lockBehavior간주됩니다 runLatest.

퀘벡 버전의 ServiceNow 지원

Azure Pipelines에는 ServiceNow와 기존 통합이 있습니다. 통합은 ServiceNow의 앱 과 Azure DevOps의 확장 에 의존합니다. 이제 퀘벡 버전의 ServiceNow와 함께 작동하도록 앱을 업데이트했습니다. 클래식 및 YAML 파이프라인은 이제 퀘벡에서 작동합니다. 이 통합이 작동하는지 확인하려면 Service Now 저장소에서 앱의 새 버전(4.188.0)으로 업그레이드합니다. 자세한 내용은 ServiceNow 변경 관리와 통합을 참조하세요.

Microsoft 호스팅 Windows 및 macOS 에이전트에 대한 .NET SDK 사전 설치 정책 변경

최근에 Microsoft 호스팅 Ubuntu 에이전트에 대한 .NET SDK 사전 설치 정책의 변경 사항을 발표 했습니다. 이제 Microsoft에서 호스팅하는 Windows 및 macOS 에이전트에 대해 동일한 변경을 수행하고 있습니다.

현재 Microsoft 호스팅 Windows 및 macOS 에이전트에 사용 가능하고 지원되는 모든 버전의 .NET SDK(2.1.x, 3.1.x, 5.0.x)를 설치합니다. 이 방법은 모든 기능 버전에 대한 최신 패치 버전을 설치하기 위해 변경됩니다. 이 변경은 더 많은 여유 공간과 새 도구 요청을 제공하기 위해 수행되고 있습니다.

무엇을 의미하나요?

SDK 버전은 다음과 같은 부분으로 x.y.znn구성됩니다. z 는 기능 버전이며 nn 패치 버전입니다. 예를 들어 2.1.302의 경우 기능 버전은 3이고 02는 패치 버전입니다. 새로운 접근 방식에 따라 모든 기능 버전에 대한 최신 패치 버전만 설치합니다. 즉, 2.1.3x에는 2.1.32만 설치되고 2.1.4x에는 2.1.403만 설치됩니다. 최신 패치 버전이 아닌 .NET SDK의 모든 버전은 9월 6일에 Windows 및 macOS 이미지에서 제거됩니다. 이 변경 내용은 Microsoft 호스팅 에이전트의 모든 Windows 및 macOS 버전에 영향을 줍니다.

대상 날짜

업데이트된 이미지 배포는 9월 6일에 시작되며 3~4일이 소요됩니다.

가능한 영향

global.json 파일을 사용하는 경우 빌드는 다음과 같은 경우에 영향을 받습니다.

global.json 파일에 최신 패치 버전이 아닌 속성 및 SDK 버전이 포함되어 rollForward: disable 있으면 빌드가 실패합니다. 예를 들면 다음과 같습니다.

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

global.json 파일에 속성이 포함된 경우 .NET SDK 버전이 자동으로 최신 패치로 rollForward: patch 변경됩니다. 예를 들면 다음과 같습니다.

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

rollForward global.json 파일에 필드를 지정하지 않으면 변경 내용이 없습니다. 설치된 최신 패치 수준이 사용됩니다.

최신 패치가 아닌 정확한 .NET SDK 버전을 사용해야 하는 경우 작업을 사용하여 UseDotNet 빌드의 일부로 설치하세요.

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

PublishBuildArtifacts 및 DownloadBuildArtifacts 작업의 변경 내용

Azure Pipelines는 아티팩트 게시/다운로드를 위한 두 가지 작업 집합을 지원합니다. PublishPipelineArtifact 및 DownloadPipelineArtifact 는 이러한 단계를 수행하는 데 권장되는 최신 작업입니다.

PublishBuildArtifacts 및 DownloadBuildArtifacts는 이전 작업이며 해당 PipelineArtifact 작업에 있는 것과 동일한 성능 및 스토리지 최적화가 없습니다. 이러한 이전 작업에는 구현 방법 측면에서도 크기 제한이 있었습니다. 일부 대규모 고객은 이러한 제한에 빠졌습니다.

모든 고객이 PipelineArtifact 작업으로 이동하도록 하려면 이전 BuildArtifact 작업의 확장성을 해결하기 위해 몇 가지 단계를 수행해야 했습니다. 확장성을 개선하기 위한 최근 업데이트의 일환으로 Azure Pipelines 에이전트는 이제 tfs 도메인을 통해 라우팅하는 대신 Blobstore 도메인을 통해 빌드 아티팩트와 직접 상호 작용합니다. 이러한 파이프라인은 오랫동안 Azure DevOps 허용 목록에 있었지만 특정 파이프라인에서 이전에 사용되지 않았을 수 있는 IP 주소 및 도메인에 액세스하기 시작합니다.

BuildArtifact 작업의 업데이트된 구현에는 에이전트 업그레이드가 필요하며, 자동 업그레이드가 특별히 사용하지 않도록 설정되었거나 방화벽이 잘못 구성되지 않은 한 자동으로 수행되어야 합니다.

에이전트가 연결된 지침을 따르지 않는 방화벽 환경에서 실행되는 경우 방화벽 구성이 수정될 때까지 에이전트를 업데이트할 때 또는 PublishBuildArtifacts 또는 DownloadBuildArtifacts 작업에서 오류가 표시될 수 있습니다.

이 문제의 일반적인 증상은 ssl 핸드셰이크 또는 아티팩트 다운로드 실패와 관련된 갑작스러운 오류이며, 일반적으로 Release Management 정의가 대상으로 하는 배포 풀에서 발생합니다. 또는 에이전트 업그레이드가 차단된 경우 릴리스가 도착하지 않는 풀의 에이전트를 기다리고 있거나 에이전트가 업데이트를 통해 오프라인으로 전환되는 것을 관찰할 수 있습니다(이 후자는 에이전트 CDN을 잘못 차단하는 환경과 관련이 있습니다).

다음 단계

참고

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

Azure DevOps로 이동하여 살펴보겠습니다.

Azure DevOps로 이동

피드백을 제공하는 방법

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

제안하기

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

감사합니다,

아론 할버그