Taiga가 결정을 기다릴 지점 선택하기

네 가지 결정을 분리하세요

가상의 장비 서비스에는 계획 수락, 빌드 실행, 변경 머지, 배포라는 서로 다른 결정 네 가지가 있습니다. 하나의 스위치를 네 가지 모두의 허가로 다루지 마세요.

자율성을 바꾸기 전에 머지 후 저장소 파이프라인이 하는 일을 살펴보세요. 작업 브랜치 머지가 배포를 시작한다면 자동 머지도 그 기존 작업 흐름을 시작할 수 있습니다.

계획이 기다려야 할지 결정하세요

제품 설정 Build on its own by default는 완성된 계획이 빌드로 진행할지 승인을 기다릴지 정합니다. 계획에 사람의 결정이 먼저 필요하면 끄세요.

이니셔티브의 Build on its own 설정은 해당 이니셔티브의 동작을 바꿀 수 있습니다. 작업을 대기열에 넣기 전에 기본값과 개별 선택을 모두 살펴보세요.

Approve는 승인자의 현재 권한 범위 안에서 승인자 ID로 빌드를 시작합니다. 실패한 계획은 빌드를 시작하지 않습니다. 빌드 자동화 자체가 결과 풀 리퀘스트의 머지를 허가하지는 않습니다.

머지 계층을 이해하세요

자율 머지는 별도로 통제하며 활성화하기 전에는 꺼져 있습니다. 문서화된 연동은 GitHub Enterprise를 포함한 GitHub를 지원합니다.

조직이나 팩터리의 꺼진 상한은 하위에서 재정의할 수 없습니다. 제품 기본값이 꺼진 것은 다릅니다. 상한이 허용하면 이니셔티브가 자체 머지를 켤 수 있습니다.

장비 서비스에서는 초기 범위를 명시하세요. 허용된 경계 안에서 결과의 영향이 작은 이니셔티브는 직원 접근 통제 변경과 다른 설정을 가질 수 있습니다.

필수 검토가 강제되도록 하세요

Taiga는 소스 관리 제공자에게 풀 리퀘스트를 머지할 수 있는지 묻습니다. 브랜치 보호가 필수 검사, 검토, 다른 조건을 정합니다. 자율 머지는 이 규칙을 우회하지 않습니다.

자동 검토가 머지를 막아야 한다면 저장소가 지원하는 구성으로 그 결과를 필수 상태 검사로 만드세요. 권고용 결과가 기대만으로 필수가 되지는 않습니다.

필수 사람 승인도 확인하세요. 통과한 검사는 정책이 요구하는 승인을 대체하지 않습니다. 실제 대상 브랜치의 규칙을 확인하세요.

중지된 머지를 해석하세요

이니셔티브에 표시된 이유를 읽으세요. 대기 중인 검사, 누락된 승인, 충돌, 미완료 계획은 서로 다른 대응이 필요합니다. 실패한 검사를 통과시키기 위해 수정이 검사 기준을 바꾼 경우에도 Taiga는 자율 머지를 중지합니다. 그 변경을 직접 검토하세요.

진행을 막는다는 이유만으로 필수 검사를 제거하지 마세요. 검사가 결과를 보고하지 않으면 구성을 수정하거나 허가된 정책 절차를 사용하세요. 수정 후에는 현재 커밋을 살펴보세요.

배포 허가를 별도로 유지하세요

Taiga GitHub App이 자율 머지를 수행하며 머지 주체로 기록됩니다. 저장소 파이프라인은 기존 배포 동작을 유지합니다.

이 시나리오에서는 머지하면 스테이징에 배포됩니다. 프로덕션에는 여전히 조직의 프로덕션 결정과 증거가 필요합니다. 파이프라인이 이 분리를 강제하는지 확인하세요. 소프트웨어 제공 검토에서 계속 학습하세요.