서론
- Jenkins의 파이프라인을 만들었다. 그리고 이 파이프라인이 완료되는데 까지 무려 1시간이 걸린다고 가정해보자.
- 개발자 10명이 동일한 깃 프로젝트 레포지토리에 10번을 30분안에 커밋했다.
- 그럼 `Push Trigger`에 의해 Jenkins는 10번에 대한 파이프라인이 동작할 것이고 최종적으로 10시간이 걸리게 된다.
- 이는 파이프라인이 빈번한 push 이벤트에 의해 과도하게 트리거되어 비효율적으로 동작한다는 것이다.
- 이를 방지하기 위해서는 두가지 전략 방법이 있다.
- 하나는
Quiet Period설정과Throttle Builds가 있다 - 위 두 가지중에 대해서 집중적으로 알아보겠다.
Throttle Build
- Throttle Concurrent Builds 플러그인을 사용해 동시에 수행할 수 있는 빌드 수를 제한 할 수 있다.
- 설정을 한 번에 최대 2개의 빌드만 실행되도록 설정하여 서버의 부하를 줄여 각각 빌드시 충분한 리소스를 확보할 수 있도록 한다고 가정해보자.
- 시간 0분: 파이프라인 A가 트리거되어 빌드가 시작된다.
- 시간 1분: 파이프라인 B가 트리거된다. 이 빌드도 즉시 시작된다.
- 시간 2분: 파이프라인 C가 된다. 하지만, A와 B가 이미 실행 중이므로 C는 대기열에서 대기하게 된다.
- 시간 10분: 파이프라인 A가 완료되면 이 시점에서 대기 중이던 파이프라인 C가 실행을 시작한다.
Quiet Period
- Quiet Period 동안에는 여러 개의 푸시가 발생하면, Jenkins는 이 기간이 종료되는 시점에 가장 최신의 커밋의 빌드만을 수행한다.
- 예를 들어, Quiet Period를 10분으로 설정했다고 해보자.
- 시간 0분:
a라는 커밋(push)이 발생했다. 이때부터 Quiet Period가 시작되며, Jenkins는 10분 동안 추가 커밋(푸쉬)을 기다린다. - 시간 2분:
b하는 커밋(push)가 발생한다. 8분이 남았음으로 여전히 추가 커밋(푸쉬)을 기다린다. - 시간 7분:
c라는 커밋(push)이 발생한다. 3분이 남았음으로 여전히 추가 커밋(푸쉬)을 기다린다. - 시간 11분:
d라는 커밋(push)이 발생한다. 이미 10분이 지났음으로d라는 커밋(푸쉬)는 다시 10분을 카운팅하기 시작하며c커밋은a와b커밋을 포함한 가장 최신 상태의 커밋일 것임으로c푸쉬 시점 코드 상태를 기반으로 파이프라인을 실행한다.(따라서 a와 b의 커밋은 빌드는 실행되지 않는다)
적용 방법
나는 Quiet Period를 적용했으며 사용방법은 아래와 같다. 120초를 설정했음으로 2분안에 여러 커밋이 왔을때 가장 최신의 커밋을 빌드후 실행한다.
Comment