빌드 트리거 및 이유 지정

필요할 때마다 수동으로 빌드를 큐에 대기시킬 수 있지만 대부분의 경우 자동 트리거를 사용하여 빌드 프로세스를 정의하면 팀의 요구 사항을 가장 효과적으로 충족할 수 있습니다.빌드가 트리거되면 특정 이유가 Reason 속성에 기록됩니다.이 항목에서는 빌드 프로세스를 개발할 때 사용 가능한 모든 빌드 트리거와 빌드 이유를 사용하는 방법에 대해 설명합니다.

• 빌드 트리거를 사용하여 팀 목표 달성

  • 빌드 중단으로부터 팀 보호

  • 연속 통합을 사용하여 품질 유지 관리

  • 야간 BVT를 실행하여 제품 품질 확인

• 자동 빌드 트리거 사용

  • 연속 통합 트리거를 사용하여 변경 내용이 체크 인될 때 큐에 빌드 대기시키기

  • 빌드 롤링 트리거를 사용하여 변경 내용이 체크 인될 때 큐에 빌드를 대기시키지만 빌드가 실행되는 빈도에 제한이 있음

  • 제어된 체크 인 트리거를 사용하여 팀 멤버가 변경 내용을 체크 인하려고 시도할 때 큐에 빌드를 대기시키고 빌드가 실패하는 경우 변경 내용 차단

  • 일정 트리거를 사용하여 정기적으로 큐에 빌드 대기시키기

• 수동으로 큐에 빌드 대기시키기

  • 큐에 빌드 대기시키기

  • 큐에 개인 빌드 대기시키기

• 사용자 지정 코드를 사용하여 큐에 빌드 대기시키기

• 빌드 트리거 및 이유로 작업

빌드 트리거를 사용하여 팀 목표 달성

빌드 중단으로부터 팀 보호

빌드에 손상을 주는 변경 사항을 개발자가 체크 인하면 소규모 팀의 경우 상당한 혼란을 겪을 수 있으며,규모가 큰 팀의 경우에는 생산성 저하 및 일정 지연을 초래하는 높은 비용을 감수해야 할 수도 있습니다.제어된 체크 인 트리거를 사용하여 이러한 문제로부터 코드베이스의 일부 또는 전부를 보호할 수 있습니다.

연속 통합을 사용하여 품질 유지 관리

연속 통합은 코드를 가능한 한 자주 공유 리포지토리에 통합하는 프로세스입니다.코드 통합 중에는 빌드 중단이나 테스트 실패를 통해 코드에 오류가 있음을 적시에 확인할 수 있습니다.연속 통합 트리거를 사용하여 연속 통합을 구현할 수 있습니다.빌드 롤링 트리거는 연속 통합 트리거와 유사하며 체크 인이 발생할 때마다 빌드를 실행할 충분히 강력한 빌드 시스템이 없는 경우 유용할 수 있습니다.

제어된 체크 인 트리거는 연속 통합보다 훨씬 더 강력한 방법으로 사용할 수 있습니다.연속 통합 트리거는 빌드 중단 또는 실패한 핵심 단위 테스트와 같은 문제에 대해 팀에 경고하지만, 제어된 체크 인 트리거는 이러한 종류의 문제가 코드베이스에 도입되는 것을 차단합니다.

빌드 시스템을 사용하여 연속 통합을 지원하는 방법에 대한 자세한 내용은 연속 통합을 지원하는 빌드 프로세스 정의 및 연속적으로 빌드 및 배포를 참조하십시오.

야간 BVT를 실행하여 제품 품질 확인

빌드 품질을 평가하기 위해 정기 테스트 실행을 예약할 수 있습니다.이러한 테스트를 BVT(빌드 확인 테스트) 또는 스모크 테스트라고도 합니다.이러한 테스트는 대개 응용 프로그램의 특정 빌드에서 주요 영역을 확인하는 데 사용되는 다양한 테스트 도구 모음으로 이루어집니다.일정 트리거를 사용하여 야간 BVT 실행을 구현할 수 있습니다.

일정 트리거에 대한 자세한 내용은 일정 트리거를 사용하여 정기적으로 큐에 빌드 대기시키기를 참조하십시오.BVT 프로세스를 설정하는 방법에 대한 자세한 내용은 방법: 응용 프로그램을 빌드한 후 예약된 테스트 구성 및 실행을 참조하십시오.

자동 빌드 트리거 사용

빌드 정의에 대한 빌드 트리거를 지정해야 합니다.대부분의 경우 빌드 프로세스가 자동으로 실행되기를 원합니다.이 단원에서 설명하는 자동 트리거 중 하나를 선택할 수 있습니다.

연속 통합 트리거를 사용하여 변경 내용이 체크 인될 때 큐에 빌드 대기시키기

연속 통합 트리거를 사용하여 빌드를 정의하는 경우 팀 멤버가 변경 내용을 체크 인할 때마다 빌드가 큐에 대기됩니다.빌드 정의 작업 영역은 빌드 정의를 트리거하는 파일을 결정합니다.빌드 작업 영역에 대한 자세한 내용은 빌드 작업 영역 사용을 참조하십시오.

연속 통합이 트리거하는 빌드에는 IndividualCI라는 Reason이 할당됩니다.

빌드 롤링 트리거를 사용하여 여러 개의 체크 인과 함께 정기적으로 빌드

빌드 롤링 트리거로 빌드를 정의하는 경우 빌드가 실행되지 않으면 빌드 시스템은 각 체크 인의 빌드를 큐에 대기시킵니다.빌드를 실행하는 경우 시스템은 빌드를 완료할 때까지 대기한 다음 아직 빌드하지 않은 모든 체크 인의 다른 빌드를 큐에 대기시킵니다.최소 빌드 간격n분 확인란을 선택하고 0에서 2147483647 사이의 정수 값을 입력하는 경우 빌드의 빈도를 더 제한할 수 있습니다.

예를 들어, 한 빌드 에이전트만 가질 수 있으며 20분마다 빌드를 끝낼 수 있습니다.연속 통합 트리거를 사용하고 팀에서 오전 10시와 오전 11시 사이에 코드를 9회 체크 인하는 경우 마지막 체크 인은 오후 1시까지 빌드할 수 없습니다. 그러나 빌드 롤링 트리거를 사용하고 간격으로 60분을 지정하는 경우 동일한 체크 인 집합을 오전 11:20분까지 빌드할 수 있습니다.

빌드 정의 작업 영역은 빌드 정의를 트리거하는 파일을 결정합니다.빌드 작업 영역에 대한 자세한 내용은 빌드 작업 영역 사용을 참조하십시오.

빌드 롤링이 트리거하는 빌드에는 BatchedCI라는 Reason이 할당됩니다.

제어된 체크 인 트리거를 사용하여 팀 멤버가 변경 내용을 체크 인하려고 시도할 때 큐에 빌드를 대기시키고 빌드가 실패하는 경우 변경 내용을 차단할 수 있습니다.

제어된 체크 인 트리거를 사용하여 빌드를 정의하는 경우 팀 멤버가 버전 제어 시스템에 제출하는 변경 내용은 보류 집합에 저장되고 빌드될 때까지 큐에 대기됩니다.체크 인 프로세스는 이 빌드가 성공적이어야 완료될 수 있습니다.빌드 정의 작업 영역은 빌드 정의로 제어되는 파일을 결정합니다.빌드 작업 영역에 대한 자세한 내용은 빌드 작업 영역 사용을 참조하십시오.

제어된 체크 인이 트리거하는 빌드에는 CheckInShelveset라는 Reason이 할당됩니다.

제어된 체크 인 트리거를 구현하는 방법에 대한 자세한 내용은 변경 내용의 유효성을 검사하는 제어된 체크 인 빌드 프로세스 정의를 참조하십시오.이러한 종류의 빌드 정의가 팀에 미치는 영향에 대한 자세한 내용은 제어된 체크 인 빌드에 의해 제어되는 보류 중인 변경 내용 체크 인을 참조하십시오.

일정 트리거를 사용하여 정기적으로 큐에 빌드 대기시키기

일정 트리거

일정 트리거를 사용하여 빌드를 정의하고 이전 빌드 이후에 변경된 내용이 없어도 새로 빌드 확인란의 선택을 취소하는 경우 이 빌드 정의를 가장 최근에 실행한 이후 변경 내용이 체크 인되면 지정한 일과 시간에 빌드가 큐에 대기됩니다.변경 내용이 마지막으로 성공한 빌드와 연결되었는지 여부와 관계없이 빌드가 큐에 대기됩니다.

이 방식으로 트리거된 빌드에는 Schedule이라는 Reason이 할당됩니다.

팁
사용자 지정 빌드 프로세스 템플릿을 개발하는 경우 템플릿의 InvokeForReason 섹션에 대한 Reason 속성의 값으로 Schedule을 선택하면 대부분 ScheduleForced도 선택해야 할 수 있습니다.

일정 트리거(Reason: ScheduleForced)

일정 트리거를 사용하여 빌드를 정의하고 이전 빌드 이후에 변경된 내용이 없어도 새로 빌드 확인란을 선택하는 경우 지정한 일과 시간에 빌드가 큐에 대기됩니다.변경 내용이 체크 인되었는지 여부와 관계없이 빌드가 큐에 대기됩니다.

이 방식으로 트리거된 빌드에는 ScheduleForced라는 Reason이 할당됩니다.

팁
사용자 지정 빌드 프로세스 템플릿을 개발하는 경우 템플릿의 InvokeForReason 섹션에 대한 Reason 속성의 값으로 ScheduleForced를 선택하면 대부분 Schedule도 선택해야 할 수 있습니다.

수동으로 큐에 빌드 대기시키기

특정한 상황에서는 빌드 프로세스를 자동으로 실행하지 않으려고 할 수 있습니다.

• 빌드 정의가 아직 개발 중이기 때문에 자동으로 실행할 준비가 되지 않았을 수 있습니다.

• 특수 빌드 프로세스는 수동으로만 실행하려고 할 수도 있습니다.

이러한 경우에는 수동 트리거를 선택할 수 있습니다.팀 멤버가 빌드 정의를 수동으로 큐에 대기시키는 경우에만 빌드 정의가 실행됩니다.

큐에 빌드 대기시키기

수동이 아닌 빌드 트리거를 사용하여 정의된 빌드 정의를 비롯한 모든 빌드 정의를 수동으로 큐에 대기시킬 수 있습니다.수동으로 빌드를 큐에 대기시키는 경우 Reason이 Manual로 설정됩니다.수동으로 빌드를 큐에 대기시키는 방법에 대한 자세한 내용은 큐에 빌드 대기시키기를 참조하십시오.

큐에 개인 빌드 대기시키기

보류 집합에 저장한 변경 내용을 빌드하려는 경우 체크 인하기 전에 개인 빌드("버디 빌드"라고도 함)를 사용하여 코드 변경 내용의 유효성을 검사할 수 있습니다.수동으로 개인 빌드를 큐에 대기시키는 경우 Reason이 ValidateShelveset로 설정됩니다.개인 빌드를 큐에 대기시키는 방법에 대한 자세한 내용은 큐에 빌드 대기시키기를 참조하십시오.

사용자 지정 코드를 사용하여 완료된 빌드 만들기

Microsoft.TeamFoundation.Build 네임스페이스의 클래스를 활용하여 완료된 빌드를 만드는 사용자 지정 코드를 개발할 수 있습니다.이 방식으로 빌드가 큐에 대기되는 경우 Reason이 UserCreated로 설정됩니다.자세한 내용은 Extending Team Foundation: Build를 참조하십시오.

빌드 트리거 및 이유로 작업

다음과 같은 방식으로 빌드 프로세스에서 트리거와 이유를 활용할 수 있습니다.

• 빌드 프로세스의 트리거 설정: 빌드 정의에서 트리거 탭을 클릭한 다음 팀의 요구 사항을 가장 효과적으로 충족하는 트리거를 선택합니다.빌드 정의를 만드는 방법에 대한 자세한 내용은 빌드 정의 만들기를 참조하십시오.

• 사용자 지정 빌드 프로세스에서 받아들이는 빌드 이유 정의: InvokeForReason 활동을 사용하여 특정 이유로 실행된 빌드에서만 실행할 빌드 프로세스의 세그먼트를 묶을 수 있습니다.자세한 내용은 Team Foundation Build Activities: InvokeForReason을 참조하십시오.