[DevOps] Release Pipeline에서 만난 지원 종료 에러와, Job 타입별 정리

두 달 전까지 잘 사용하던 Azure DevOps Release 파이프라인이 Dev 환경에 배포 테스트를 진행하던 중 에러가 발생했다. 오랬동안 파이프라인 설정을 손대지 않아 에러가 생소하게 느껴졌다.

 

[에러 내용]

설정한 에이전트 풀에서 windows-20190vs2019-ap-default가 더이상 지원되지 않음을 의미한다.

• windows-2019 이미지가 제거됨

Azure DevOps의 MS Hosted Agent는 주기적으로 이미지가 변경/종료되므로, 오래 유지한 파이프라인에서 이런 문제가 발생할 수 있다.

 

[해결 방법]

1. Agent Pool 변경

기존 Hosted Windows 2019 with VS2019 -> 변경 Azure Pipelines 

2. Agent Specification

환경에 맞는 os를 선택

Job 타입별 정리

이번 기회에 Release 파이프라인의 Job 구조도 다시 정리해보았다. 크게 두 가지 Job 타입이 있다.

1. Agent job

위 이미지에서 보이는 Add an agent job이다.

이 Job은 Azure Portal에서 제공하는 Hosted Agent(마이크로소프트가 관리하는 가상 머신) 혹은 직접 설치한 Self-hosted Agent 위에서 동작한다.

• 동작 방식
  • Microsoft Hosted Agent 또는 Self-hosted Agent 위에서 실행
  • 배포 대상은 Azure 리소스 (App Service 등)
  • 실제 서버에 Agent를 설치하지 않음

🔹PaaS 환경 배포 방식 ( 예: Azure App Service )

① App Service Scale-out 인스턴스

- App Service가 3개 인스턴스로 확장되어 있어도 Deploy Task는 1개만 추가하면 된다.

- App Service 내부에서 자동으로 모든 인스턴스에 배포된다.

 

② 서로 다른 App Service 리소스가 여러 개일 경우

- ex) 웹앱1, 웹앱2, 웹앱3

- 서로 다른 리소스라면 각각 Deploy Task를 추가해야 한다.

2. Deployment group job (IaaS 전용)

Azure App Service 같은 PaaS에는 Deployment Group Job을 사용할 수 없다. Agent를 설치할 수도 없고, 반드시 Agent job 방식으로 배포해야 한다.

• 동작 방식
  • VM 또는 물리 서버에 Azure DevOps Agent 직접 설치
  • 해당 서버를 Deployment Group에 등록
  • Release에서 해당 Group을 선택하여 배포
  • Group을 단일vm으로 구성해서 단일 서버 배포에도 사용함
• 사용 환경
  • Azure VM, 온프레미스 서버, 기타 IaaS 환경
• 이 방식은 레거시 방식으로 저물어가고 있다. 현재는 MS에서 YAML Multi-stage Pipeline 방식을 권장하고 있다.
  • 최신 권장 방식은 Environment 기반 배포 구조이다. 
  • YAML Multi-stage Pipeline → Environment → Virtual Machine Resource 등록 → Deployment Job