파이프라인 및 버전 관리 전략 설계
여러분은 재사용 가능한 Bicep 코드를 게시하기 시작할 때 아마도 수동 접근 방식을 사용할 것입니다. 게시해야 하는 Bicep 파일을 쉽게 확인할 수 있으며, 아마도 버전 번호를 높이는 프로세스가 수동일 것입니다.
게시 프로세스를 자동화할 때 이러한 단계를 자동화하는 방법을 고민해야 합니다. 이 단원에서는 코드 변경 내용을 전달하는 버전 관리 시스템을 채택하는 방법을 알아봅니다. 파이프라인의 범위를 지정하여 필요한 코드만 게시하는 방법도 알아봅니다.
버전 번호
이전 Microsoft Learn 학습 모듈에서는 템플릿 사양 및 Bicep 모듈의 버전 관리가 중요한 이유를 알아보았습니다. 다양한 버전 관리 방법 중에서 선택할 수 있습니다. 다중 파트 버전 관리 시스템을 사용하는 것이 좋은 경우가 많습니다. 다중 파트 버전 관리 시스템은 다음 예제와 유사하게 주 버전, 부 버전 및 수정 번호로 구성됩니다.
앞의 예제에서 주 버전은 1, 부 버전은 4, 수정 번호는 106입니다.
버전 번호의 여러 부분을 변경하면 코드의 변경 유형에 대한 중요한 정보가 전달됩니다.
호환성이 손상되는 변경을 수행할 때마다 주 버전 번호를 높여야 합니다. 예를 들어 새로운 필수 매개 변수를 추가하거나 Bicep 파일에서 매개 변수를 제거한다고 가정하겠습니다. 이 경우 Bicep은 배포 시 필수 매개 변수를 지정해야 하며 존재하지 않는 매개 변수에 대한 값을 설정할 수 없으므로 호환성이 손상되는 변경의 예입니다. 따라서 주 버전 번호를 업데이트해야 합니다.
코드에 새로운 내용을 추가하지만 호환성이 손상되는 변경이 아닌 경우 부 버전 번호를 높여야 합니다. 예를 들어 새로운 선택적 매개 변수를 기본값으로 추가한다고 가정하겠습니다. 선택적 매개 변수는 호환성을 손상시키지 않으므로 부 버전 번호를 업데이트해야 합니다.
이전 버전과 호환되는 버그 수정 또는 코드 작동 방식에 영향을 주지 않는 기타 변경을 수행할 때마다 수정 번호를 높여야 합니다. 예를 들어 변수와 식을 더 잘 사용하기 위해 Bicep 코드를 리팩터링한다고 가정하겠습니다. 리팩터링에서 Bicep 코드 동작을 전혀 변경하지 않는 경우 수정 번호를 업데이트해야 합니다.
파이프라인에서 수정 번호를 자동으로 설정할 수도 있습니다. 파이프라인의 빌드 번호를 수정 번호로 사용할 수 있습니다. 이 규칙은 버전 번호의 다른 구성 요소를 업데이트하지 않더라도 버전 번호가 항상 고유하도록 유지하는 데 도움이 됩니다.
예를 들어, 버전 번호가 2.0.496인 이전에 게시된 Bicep 모듈을 사용하고 있다고 가정하겠습니다. 버전 번호가 2.1.502인 새 버전의 모듈을 사용할 수 있게 되었습니다. 유일하게 중요한 변경은 새 버전을 사용할 때 호환성이 손상되는 변경이 없음을 나타내는 부 버전 번호입니다.
참고
의미 체계 버전 관리는 다중 파트 버전 관리와 비슷한 공식화된 버전 관리 구조입니다. 의미 체계 버전 관리에서는 각 구성 요소를 설정하거나 다시 설정해야 하는 시기에 대한 엄격한 규칙과 함께 버전 번호에 추가 구성 요소가 있습니다. 의미 체계 버전 관리에 대한 자세한 내용은 요약 단원에서 링크를 통해 제공됩니다.
팀에서는 버전 관리에 대한 호환성이 손상되는 변경을 정의하는 방법을 결정해야 합니다. 예를 들어, 스토리지 계정을 배포하는 Bicep 모듈을 빌드한다고 가정하겠습니다. 여러분은 현재 스토리지 계정에서 프라이빗 엔드포인트를 사용하도록 Bicep 파일을 업데이트하고 있습니다. 동시에 Bicep 파일에 프라이빗 DNS 영역을 추가하고 있습니다.
이 예제에서는 Bicep 파일의 매개 변수 또는 출력에 영향을 주지 않고 변경 작업을 수행할 수 있습니다. 이처럼 파일을 배포하는 사람이 차이점을 인지하지 못할 수 있습니다. 그러나 이 변경으로 인해 리소스 동작에 상당한 차이가 발생하므로 주 버전 업데이트로 처리하기로 결정할 수 있습니다.
파이프라인의 빌드 번호를 버전 번호로 사용하는 방법처럼 더 간단한 버전 관리 전략을 사용하도록 선택할 수도 있습니다. 이 방법은 구현하기 쉽지만, 코드를 사용하는 사람에게 버전 간의 차이점을 효과적으로 전달할 수 없습니다.
버전 및 파이프라인
Azure CLI를 사용하는 등 대화형으로 코드를 게시하는 경우 아마도 코드를 게시할 때 템플릿 사양 또는 모듈에 할당하는 버전 번호에 대해 생각할 것입니다. 하지만 자동화된 배포 파이프라인에서는 버전 번호를 할당하는 접근 방식을 변경해야 합니다. 파이프라인에서는 호환성이 손상되는 변경을 자동으로 탐지하거나 주 버전 또는 부 버전 번호를 언제 높여야 하는지 조언할 수 없습니다. 템플릿 사양 또는 모듈을 게시하기 전에 버전 관리에 대해 신중하게 고민해야 합니다.
한 가지 방법은 다음 다이어그램처럼 메타데이터 파일을 Bicep 코드와 함께 저장하는 것입니다.
Bicep 코드를 업데이트할 때마다 해당 메타데이터 파일에서 버전 정보를 업데이트합니다. 버전 번호를 올바르게 높일 수 있도록 호환성이 손상되는 변경과 손상되지 않는 변경을 올바르게 파악해야 합니다.
팁
팀에서 끌어오기 요청을 사용하여 Bicep 코드를 검토할 때 검토자에게 코드를 변경하면 주 버전 또는 부 버전 번호를 변경해야 하는지 확인하라고 요청하세요.
다음 연습에서 메타데이터 파일을 사용하는 방법을 보여줍니다.
파이프라인은 몇 개입니까?
템플릿 사양 및 모듈 컬렉션을 빌드하는 것이 일반적입니다. 이 코드를 동일한 Git 리포지토리에 보관하는 것이 좋을 때가 많습니다.
Azure Pipelines의 경로 필터를 사용하면 리포지토리 내의 각 모듈 또는 템플릿 사양에 대한 별도의 파이프라인을 만들 수 있습니다. 이 방법을 사용하면 파일 하나를 변경할 때마다 리포지토리 내 모든 Bicep 파일의 새 버전을 게시하지 않아도 됩니다. 파이프라인 템플릿을 사용하여 중앙 집중식 파일에 파이프라인의 단계를 정의할 수 있습니다. 이렇게 하면 각 모듈과 템플릿 사양의 파이프라인이 가볍게 유지됩니다.
예를 들어 파일 구조가 앞에서 설명한 구조와 비슷하다고 가정하겠습니다. Bicep 파일마다 하나씩 3개의 개별 파이프라인을 구성할 수 있습니다. 다음과 같이 각 탭을 선택하면 해당 파이프라인 정의 및 해당 경로 필터를 볼 수 있습니다.
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
module-2/main.bicep 파일만 변경한다고 가정하겠습니다. 모듈 2에 대한 파이프라인만 실행됩니다. 그러나 동일한 커밋의 여러 파일을 변경하면 관련된 각 파이프라인이 트리거됩니다.
참고
재사용 가능한 각 Bicep 파일에 대한 파이프라인을 만드는 방법은 간단하고 유연합니다. 그러나 Bicep 파일이 많거나 각 모듈 및 템플릿 사양에 대한 별도의 파이프라인을 유지 관리하는 것을 원치 않을 때에는 번거로울 수 있습니다.
파이프라인 내에서 스크립트를 작성하여 변경된 코드를 찾고 해당 파일만 게시할 수도 있습니다. 이 방법은 좀 더 복잡하며, 이 Microsoft Learn 모듈의 범위를 벗어납니다.
재사용 가능한 Bicep 코드에 사용되는 환경
Bicep을 사용하여 Azure에 배포하는 경우 프로덕션 환경에 코드가 게시되기 전에 코드의 유효성을 검사하고 테스트하는 데 도움이 되는 여러 환경을 사용하는 것이 일반적입니다. 이전 Microsoft Learn 학습 모듈에서는 배포 파이프라인에서 여러 환경을 작업하는 방법을 알아보았습니다.
일부 조직에서는 Bicep 모듈과 템플릿 사양에 동일한 원칙을 적용합니다. 예를 들어 각 모듈의 사용자가 새 버전을 사용해 볼 수 있도록 새 버전의 모듈을 비프로덕션 레지스트리에 먼저 게시할 수 있습니다. 이런 경우에는 변경 내용을 승인한 후 조직의 프로덕션 레지스트리에 모듈을 게시할 수 있습니다.
일반 배포와 마찬가지로 작업 및 파이프라인 템플릿을 사용하여 환경 전체에서 배포 순서를 정의할 수 있습니다. 이 Microsoft Learn 모듈에서는 파이프라인을 단순하게 유지하기 위해 단일 환경에 게시합니다.
레지스트리의 모듈을 사용하거나 템플릿 사양을 Bicep 모듈로 사용하는 경우 별칭을 사용할 수 있습니다. 모듈을 정의할 때마다 레지스트리 이름 또는 템플릿 사양의 위치를 지정하는 대신 별칭을 사용합니다.
별칭을 사용하면 여러 환경에서 배포 프로세스가 쉽게 작동할 수 있습니다. 예를 들어 모듈을 정의할 때 레지스트리 이름 대신 별칭을 사용할 수 있습니다. 그런 다음, 다음 항목으로 매핑할 별칭을 구성하도록 배포 파이프라인을 디자인할 수 있습니다.
- 샌드박스 환경에 배포할 때 개발 모듈 레지스트리
- 다른 환경에 배포하는 경우 프로덕션 레지스트리
참고
별칭은 게시할 때 적용되지 않습니다. 별칭은 Bicep 파일 내에서 템플릿 사양 또는 모듈을 사용하는 경우에만 작동합니다.