클래식 릴리스 파이프라인
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
클래식 릴리스 파이프라인은 여러 환경에 애플리케이션을 효율적이고 안전하게 배포하기 위한 프레임워크를 개발자에게 제공합니다. 클래식 릴리스 파이프라인을 사용하여 테스트 및 배포 프로세스를 자동화하고, 유연한 배포 전략을 설정하고, 승인 워크플로를 통합하고, 다양한 단계에서 원활한 애플리케이션 전환을 보장할 수 있습니다.
릴리스 파이프라인 작동 방법
모든 배포의 일부로 Azure Pipelines는 다음 단계를 실행합니다.
배포 전 승인:
새 배포 요청이 트리거되면 Azure Pipelines는 릴리스를 스테이지에 배포하기 전에 사전 배포 승인이 필요한지 확인합니다. 승인이 필요한 경우 관련 승인자에게 메일 알림 보냅니다.
큐 배포 작업:
Azure Pipelines는 사용 가능한 에이전트에서 배포 작업을 예약합니다.
에이전트 선택:
사용 가능한 에이전트가 배포 작업을 선택합니다. 런타임 중에 적합한 에이전트를 동적으로 선택하도록 릴리스 파이프라인을 구성할 수 있습니다.
아티팩트 다운로드:
에이전트는 릴리스에 지정된 모든 아티팩트 검색 및 다운로드합니다.
배포 작업을 실행합니다.
에이전트는 배포 작업의 모든 작업을 실행합니다.
진행률 로그 생성:
에이전트는 각 배포 단계에 대한 포괄적인 로그를 생성하고 Azure Pipelines로 다시 보냅니다.
배포 후 승인:
단계에 대한 배포가 완료되면 Azure Pipelines는 해당 특정 단계에 배포 후 승인이 필요한지 확인합니다. 승인이 필요하지 않거나 필요한 승인이 확보되면 다음 단계로 배포를 시작합니다.
배포 모델
Azure 릴리스 파이프라인은 Jenkins, Azure Artifacts 및 Team City를 비롯한 다양한 아티팩트 원본을 지원합니다. 다음 예제에서는 Azure 릴리스 파이프라인을 사용하는 배포 모델을 보여 줍니다.
다음 예제에서 파이프라인은 별도의 빌드 파이프라인에서 시작되는 두 개의 빌드 아티팩트로 구성됩니다. 애플리케이션은 처음에 개발 단계에 배포된 다음 두 개의 개별 QA 스테이지에 배포됩니다. 두 QA 단계에서 모두 배포에 성공하면 애플리케이션이 Prod 링 1 및 Prod 링 2에 배포됩니다. 각 프로덕션 링은 전 세계의 다른 위치에 배포된 동일한 웹앱의 여러 인스턴스를 나타냅니다.
릴리스 및 배포
릴리스는 CI/CD 파이프라인에 지정된 버전이 지정된 아티팩트 집합을 보유하는 구문입니다. 여기에는 단계, 작업, 정책(예: 트리거 및 승인자) 및 배포 옵션과 같은 릴리스 파이프라인의 모든 작업 및 작업을 수행하는 데 필요한 모든 정보의 스냅샷이 포함됩니다. 하나의 릴리스 파이프라인에서 여러 릴리스가 있을 수 있으며 각 릴리스에 대한 정보는 지정된 보존 기간 동안 Azure Pipelines에 저장되고 표시됩니다.
배포는 자동화된 테스트 실행, 빌드 아티팩트 배포 및 해당 단계에 대해 지정된 다른 작업을 포함할 수 있는 한 단계에 대한 작업을 실행하는 작업입니다. 릴리스를 시작하면 원래 릴리스 파이프라인에 정의된 설정 및 정책에 따라 각 배포가 시작됩니다. 한 단계에 대해서도 각 릴리스의 여러 배포가 있을 수 있습니다. 스테이지에 대한 릴리스 배포가 실패하면 동일한 릴리스를 해당 스테이지에 다시 배포할 수 있습니다. 릴리스를 다시 배포하려면 배포하려는 릴리스로 이동하여 배포를 선택하기만 하면 됩니다.
다음 다이어그램은 릴리스, 릴리스 파이프라인 및 배포 간의 관계를 보여 줍니다.
FAQ
Q: 배포가 트리거되지 않은 이유는 무엇인가요?
A: 릴리스 파이프라인을 만들면 배포가 자동으로 시작되지 않습니다. 이러한 일이 발생할 수 있는 몇 가지 이유는 다음과 같습니다.
배포 트리거: 정의된 배포 트리거로 인해 배포가 일시 중지될 수 있습니다. 이는 예약된 트리거 또는 다른 스테이지로의 배포가 완료될 때까지 지연이 있을 때 발생할 수 있습니다.
큐 정책: 이러한 정책은 실행 순서와 배포를 위해 릴리스가 큐에 대기되는 시기를 지정합니다.
배포 전 승인 또는 게이트: 특정 단계에서는 사전 배포 승인 또는 게이트가 필요할 수 있으므로 정의된 모든 조건이 충족될 때까지 배포를 방지할 수 있습니다.
Q: 릴리스 시 변수를 편집하려면 어떻게 해야 하나요?
A: 릴리스 파이프라인의 변수 탭에서 릴리스가 큐에 대기 중일 때 수정하려는 변수에 대한 릴리스 시 Settable 확인란을 선택합니다.
그 후 새 릴리스를 생성할 때 해당 변수의 값을 수정할 수 있습니다.
Q: 릴리스를 정의하는 파이프라인 대신 릴리스를 수정하는 것이 더 적절한 시기는 언제인가요?
A: 릴리스 인스턴스의 승인, 작업 및 변수를 편집할 수 있습니다. 그러나 이러한 편집 내용은 해당 인스턴스에만 적용됩니다. 변경 내용을 향후 모든 릴리스에 적용하려면 대신 릴리스 파이프라인을 편집합니다.
Q: "릴리스 중단" 기능이 유용한 시나리오는 무엇인가요?
A: 릴리스를 다시 사용할 계획이 없거나 릴리스가 사용되지 않도록 하려면 다음과 같이 릴리스를 중단하면 됩니다> (...) >포기하십시오. 배포가 진행 중인 경우 릴리스를 중단할 수 없습니다. 먼저 배포를 취소해야 합니다.
Q: 새 릴리스의 이름을 관리할 어떻게 할까요? 있나요?
A: 릴리스 파이프라인에 대한 기본 명명 규칙은 순차 번호 매기기이며, 여기서 릴리스의 이름은 Release-1, Release-2 등입니다. 그러나 릴리스 이름 형식 마스크를 수정하여 명명 체계를 유연하게 사용자 지정할 수 있습니다. 릴리스 파이프라인의 옵션 탭에서 일반 페이지로 이동하고 기본 설정에 맞게 릴리스 이름 형식 속성을 조정합니다.
서식 마스크를 지정할 때는 다음과 같은 미리 정의된 변수를 사용할 수 있습니다. 예: 다음 릴리스 이름 형식: 빌드 $(Build.BuildNumber) $(Build.DefinitionName)의 릴리스 $(Rev:rrr) 는 빌드 20170213.2 MySampleAppBuild용 릴리스 002를 만듭니 다.
| 변수 | 설명 |
|---|---|
| 수정 버전: rr | 지정된 숫자 개수 이상이 있는 자동 증가된 숫자입니다. |
| 날짜 / 날짜: MMddyy | 기본 형식이 MMddyy인 현재 날짜입니다. M/MM/MMM/MMMM, d/dd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/HH, m/mm, s/ss 등 모든 조합이 지원됩니다. |
| System.TeamProject | 이 빌드가 속하는 프로젝트의 이름입니다. |
| Release.ReleaseId | 프로젝트의 모든 릴리스에 대해 고유한 릴리스 ID입니다. |
| Release.DefinitionName | 현재 릴리스가 속한 릴리스 파이프라인의 이름입니다. |
| Build.BuildNumber | 릴리스에 포함된 빌드 번호입니다. 릴리스에 빌드가 여러 개 있는 경우에는 주 빌드의 번호입니다. |
| Build.DefinitionName | 릴리스에 포함된 빌드의 파이프라인 이름입니다. 릴리스에 빌드가 여러 개 있는 경우에는 주 빌드의 파이프라인 이름입니다. |
| Artifact.ArtifactType | 릴리스와 연결된 아티팩트 원본의 형식입니다. 예를 들어 Azure Pipelines 또는 Jenkins일 수 있습니다. |
| Build.SourceBranch | 기본 아티팩트 소스의 분기입니다. Git의 경우 분기가 refs/heads/main이면 이 중 형식은 main입니다. Team Foundation 버전 제어의 경우 작업 영역에 대한 루트 서버 경로가 $/teamproject/branch이면 이 중 형식은 branch입니다. 이 변수는 Jenkins 또는 다른 아티팩트 소스에 대해 설정되지 않습니다. |
| 사용자 지정 변수 | 릴리스 파이프라인에 정의된 전역 구성 속성의 값입니다. 릴리스 로깅 명령을 사용하여 릴리스 이름을 사용자 지정 변수로 업데이트할 수 있습니다. |
Q: 릴리스의 보존 기간을 정의하려면 어떻게 해야 하나요?
A: 릴리스 파이프라인에 대한 보존 정책을 설정하는 방법을 알아보려면 보존 정책을 참조하세요.