트리거를 사용하여 워크플로가 실행되는 시점 제어
이제 Azure 환경에 Bicep 파일을 배포하는 작업 워크플로가 있습니다. 그러나 파일을 변경할 때마다 워크플로를 수동으로 실행해야 합니다. 이 단원에서는 Bicep 코드가 변경될 때마다 워크플로가 자동으로 실행되도록 트리거하는 방법을 알아봅니다.
참고
이 단원의 명령은 개념을 설명하기 위해 표시된 것입니다. 명령을 아직 실행하지 마세요. 여기에서 학습하는 내용을 곧 연습할 예정입니다.
워크플로 트리거란 무엇인가요?
워크플로 트리거는 충족될 경우 사용자가 만든 규칙에 따라 워크플로를 자동으로 실행하는 조건입니다. 예약된 간격으로 워크플로를 실행하도록 설정할 수 있습니다. 리포지토리의 파일이 변경될 때마다 워크플로를 실행하도록 트리거를 구성할 수도 있습니다. 다른 사용자가 코드를 변경할 때마다 모든 테스트 및 배포 단계를 실행하는 것이 좋습니다.
자동 트리거를 사용하지 않는 경우 누군가가 Bicep 파일을 변경하고 커밋하여 리포지토리에 푸시할 수도 있지만 워크플로를 실행하는 것을 잊어버린 경우 Bicep 파일의 리소스 정의와 Azure 환경에 배포된 리소스 간에 차이가 있습니다. 커밋 및 푸시가 몇 개 더 만들어졌지만 배포되지 않았다고 가정해 보겠습니다. 이러한 변경 중 하나에서 Bicep 파일에 오류 또는 잘못된 구성을 제공하는 경우 나중에 한 번에 배포되는 여러 커밋에서 오류를 추적하는 것이 어려울 수 있습니다. 시간이 지나면 Bicep 코드가 인프라를 실제로 나타낸다는 것을 신뢰하지 않을 것이고, 그 값이 훼손될 것입니다.
파일을 업데이트할 때마다 실행되도록 워크플로를 설정하면 변경 내용이 푸시되는 순간 워크플로가 실행되기 시작합니다. 변경의 유효성에 대한 즉각적인 피드백을 받고 프로덕션 환경이 항상 최신 상태인지 확인할 수 있습니다.
이벤트 푸시 트리거
일반적인 유형의 트리거는 이벤트 푸시 트리거, 연속 통합 트리거 또는 CI 트리거라고도 합니다. 이벤트 푸시 트리거를 사용하면 지정된 분기를 변경할 때마다 워크플로가 실행됩니다. 변경 내용을 다른 분기에 커밋하고 푸시하는 경우 워크플로는 이를 무시하여 실행되지 않습니다. 다음 코드를 사용하여 기본 또는 main 분기에 대해 이 유형의 트리거를 사용하는 것이 일반적입니다.
on:
push:
branches:
- main
여러 분기가 변경되었을 때 트리거
특정 분기 또는 분기 집합에서 워크플로를 실행하도록 트리거를 설정할 수 있습니다. 예를 들어 프로젝트의 특정 릴리스에 대해 배포할 코드가 포함된 릴리스 분기를 만든다고 가정하겠습니다. release/v1, release/v2 등과 같은 분기 이름을 사용할 수 있습니다. 이름이 release/로 시작하는 분기에서 코드가 변경될 때마다 워크플로를 실행하려고 합니다. ** 와일드카드를 사용할 수 있습니다.
on:
push:
branches:
- main
- 'release/**'
특정 분기를 제외할 수도 있습니다. 프로젝트에서 팀 구성원과 공동 작업을 하고 있다고 가정하겠습니다. 동료는 Bicep 파일에서 아이디어를 시험하기 위해 기능 분기를 만듭니다. 모든 기능 분기는 feature/add-database, feature/improve-performance 등과 같은 이름이 지정됩니다. 동료가 만드는 기능 분기를 제외한 모든 분기에서 워크플로를 자동으로 실행하려고 합니다. exclude 속성을 사용하면 워크플로가 기능 분기의 변경에 대해 자동으로 트리거되지 않게 할 수 있습니다.
on:
push:
branches-ignore:
- 'feature/**'
참고
! 문자를 사용하여 특정 분기를 제외할 수 있습니다. 알파 릴리스를 제외한 main 분기 및 모든 릴리스 분기에 대해 워크플로를 트리거한다고 가정합니다. ! 문자를 사용하여 다음을 표현할 수 있습니다.
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
branches 및 branches-ignore를 한 분기에서 사용할 수 없으므로 ! 문자를 사용하면 트리거 동작을 유연하게 제어할 수 있습니다.
패스 필터
경우에 따라 리포지토리에 배포와 관련이 없는 파일이 있습니다. 예를 들어 리포지토리에 Bicep 코드가 포함된 deploy 폴더와 설명서 파일이 포함된 docs 하위 폴더가 있을 수 있습니다. 배포 폴더의 Bicep 파일을 변경하는 사람이 있을 때 워크플로를 트리거하려고 하지만 설명서 파일만 변경하는 경우에는 워크플로를 트리거하지 않으려는 것입니다. 리포지토리에서 특정 폴더의 변경 내용에 응답하도록 트리거를 설정하려면 경로 필터를 사용할 수 있습니다.
on:
push:
paths:
- 'deploy/**'
- '!deploy/docs/**'
누군가 설명서 파일만 업데이트하는 변경 내용을 커밋하는 경우 워크플로는 실행되지 않습니다. 그러나 Bicep 파일을 변경하거나 설명서 파일과 Bicep 파일을 변경하는 경우에는 트리거가 워크플로를 실행합니다.
참고
paths-ignore도 사용할 수 있으며 이는 branches-ignore 키워드와 비슷한 방식으로 작동합니다. 하지만 paths와 paths-ignore를 같은 트리거에서 사용할 수는 없습니다.
워크플로 자동 실행 예약
파일 변경에 대한 응답이 아니라 설정된 일정에 따라 워크플로를 실행할 수 있습니다. 예를 들어 Bicep 코드의 야간 릴리스를 실행하거나 매일 아침마다 테스트 환경을 자동으로 배포할 수 있습니다. schedule 키워드를 사용하고 cron 식을 사용하여 빈도를 설정합니다.
on:
schedule:
- cron: '0 0 * * *'
참고
cron 식은 발생 빈도를 지정하는 특수 형식의 문자 시퀀스입니다. 이 예제에서 0 0 * * *은 매일 자정(UTC)에 실행을 의미합니다.
YAML 파일에서 cron 식과 같이 * 문자를 포함하는 문자열 앞뒤로 따옴표를 추가해야 합니다.
일정 이벤트는 항상 리포지토리의 기본 분기에서 워크플로를 실행합니다.
다중 트리거 사용
다음 예제와 같이 트리거와 일정을 결합할 수 있습니다.
on:
push:
branches:
- main
schedule:
- cron: '0 0 * * *'
동일한 워크플로에서 분기 트리거 및 일정 트리거를 만들면 트리거에서 설정된 분기에서 파일이 변경될 때마다 그리고 사용자가 설정한 일정에 따라 워크플로가 실행됩니다. 이 예제에서 워크플로는 매일 자정(UTC)과 main 분기에 변경이 푸시될 때마다 실행됩니다.
팁
각 워크플로에 대해 트리거를 설정하는 것이 좋습니다. 트리거를 설정하지 않으면 기본값으로 모든 분기에서 파일이 변경될 때마다 자동으로 워크플로가 실행되는데 이는 필요하지 않은 경우가 많습니다.
웹후크 트리거
또한 GitHub는 리포지토리에서 특정 이벤트가 발생할 때 자동으로 실행되는 웹후크 이벤트도 제공합니다. 이러한 이벤트에는 분기를 만드는 사람, GitHub 문제에 대한 업데이트 또는 끌어오기 요청에 대한 변경 내용이 포함됩니다. 일반적으로 이러한 이벤트에서는 Bicep 배포 워크플로를 실행하지 않아도 되지만 다른 자동화를 대신 실행할 수도 있습니다.
동시성 제어
기본적으로 GitHub Actions를 사용하면 여러 인스턴스의 워크플로를 동시에 실행할 수 있습니다. 이는 짧은 시간 내에 한 분기에 여러 커밋을 수행하거나, 다음에 예약이 트리거될 때 이전 실행이 완료되지 않은 경우에 발생할 수 있습니다.
일부 상황에서는 워크플로의 동시 실행이 여러 개 있는 것이 문제가 되지 않습니다. 그러나 배포 워크플로를 사용하는 경우 워크플로 실행이 예상하지 못한 방식으로 Azure 리소스 또는 구성을 덮어쓰지 않도록 하는 것이 어려울 수 있습니다.
이러한 문제를 방지하기 위해 동시성 제어를 적용할 수 있습니다. concurrency 키워드(keyword) 사용한 다음 워크플로에 대한 모든 실행에서 일관된 문자열을 지정합니다. 일반적으로 이 예제와 같이 하드 코딩된 문자열입니다.
concurrency: MyWorkflow
그러면 GitHub Actions가 새 실행을 시작하기 전에 모든 활성 워크플로 실행이 완료될 때까지 대기하도록 합니다.