두 개의 빌드를 순차적으로 실행하는 Azure Devops
Azure Devops 설정이 있습니다. 지금 우리 프로젝트는 두 번 빌드됩니다.
YAML 파일에서 Pull Request Checkin 중에 한 번, 빌드 설정으로 인해 다른 한 번 (아래 그림).
이로 인해 두 개의 빌드가 트리거되고 빌드 시간이 두 배가됩니다. Devops 팀은 이것이 일반적인 관행이라고 언급했습니다. Azure Devops가 하나의 빌드 만 트리거하지 않는 이유는 무엇입니까? 아니면 두 개의 빌드로 더 안전한 방법인가요?
답변
Azure Devops가 하나의 빌드 만 트리거하지 않는 이유는 무엇입니까? 아니면 두 개의 빌드로 더 안전한 방법인가요?
내가 아는 한 이것은 Azure Devops의 예상 워크 플로입니다.
빌드 설정으로 인해
이것은 Pull Request 트리거 입니다.
이 트리거는 Pull Request 과정에서 발생하며 PR 트리거는 PR이 생성 될 때마다 실행됩니다.
이 트리거는 확인 단계와 동일하며 파일이 실제로 대상 브랜치 (타거 브랜치에 사전 병합 됨)에 커밋되지 않습니다.
빌드 결과를 확인하여 소스 분기 코드가 유효한지 확인할 수 있습니다.
예 :
풀 요청 트리거가 실패하면 풀 요청을 거부 할 수 있습니다. 대상 분기에는 영향을주지 않으며 대상 분기는 원래 상태로 유지됩니다.
YAML 파일의 Pull Request Checkin
이것은 CI 트리거 일 수 있습니다 .
이 트리거는 풀 요청이 완료 될 때 발생합니다.
이 경우 대상 분기가 변경되었습니다. 대상 분기가 변경되면 CI 트리거가 트리거됩니다. 이것은 코드가 유효한지 다시 확인할 수 있습니다.
워크 플로우 요약 :
Pull Request 생성-> Pull Request Trigger (Pre-merged and firest check)-> Complete Pull Request-> CI trigger (Complete the branch merge and second check).
그런데 일부 파일을 제외하여 Pull Request 트리거를 트리거하지 않으려면 경로 필터를 추가 할 수 있습니다.
예를 들면 :
기능적으로 두 빌드가 항상 동일하지는 않을 수 있습니다.
아래 예가 있다고 가정 해 봅시다. 대문자는 커밋이고 소문자는 잠재적 인 커밋입니다.
e e'
/ \
| | D
C | B
\ | /
A
이것은 A 커밋 (마스터 브랜치)에서 나오는 두 개의 브랜치를 보여줍니다. 각 기능 분기마다 PR이 생성되었습니다. 한 브랜치는 e 커밋에 빌드가 있고 다른 브랜치는 e '커밋에 빌드가 있습니다. Azure devops는 먼저 병합 될 PR을 확인할 수 없습니다.
두 PR을 모두 병합하면 이전에 빌드되지 않은 마스터의 새 커밋으로 끝납니다. 여기에 설명되어 있습니다.
F
E \
/ | D
C | B
\ | /
A
마스터에서 빌드 할 필요가 없도록하려면 빌드 만료를 다음으로 설정할 수 있습니다. Immediately when branch name is updated