전역 브랜치 작업 흐름과 수명
전역 브랜치는 여러 앱의 자원 변경을 같은 문맥에서 개발하고 검토하여 main에 병합하는 단위입니다. 지원 자원의 변경을 묶는 기능이며 자원마다 추가, 리베이스와 병합 방식이 다를 수 있습니다.
브랜치 열기
지원 앱의 브랜치 선택기 또는 Global Branching 앱에서 새 브랜치를 만듭니다. 이름, 온톨로지와 공간 및 조직의 조건은 브랜치 보안을 따릅니다.
기존 브랜치는 앱의 선택기나 Global Branching > Branches에서 찾습니다.
지원 앱에서는 아래의 branch taskbar가 현재 문맥을 표시합니다.
변경 범위
브랜치에 있는 지원 자원을 수정하면 main과 분리하여 작업합니다. 다만 일반 Foundry 자원을 생성하거나 삭제하는 동작은 main에 영향을 줍니다. 온톨로지 엔터티는 예외로 브랜치에서 생성, 수정 또는 삭제할 수 있습니다.
일부 앱은 변경 전에 자원을 브랜치에 추가해야 하고, 다른 앱은 첫 변경을 저장할 때 자동 추가합니다. 필요하면 브랜치 선택 시 추가 안내가 나타납니다.
브랜치에서 시험한 액션의 데이터 편집은 main 데이터로 병합되지 않습니다. 액션 정의 변경과 시험 데이터 및 외부 효과는 액션 브랜치 조건을 따릅니다.
main 갱신과 리베이스
작업 중 main의 같은 자원이 바뀌면 rebase로 최신 main 변경을 가져오고 그 위에 브랜치의 저장한 변경을 다시 적용합니다.
브랜치에서 자원 제거
Global Branching 앱 또는 taskbar에서 자원을 브랜치에서 제거하면 그 자원의 상태를 main 버전으로 되돌립니다.
이는 Foundry 자원 자체의 삭제와 다릅니다. 다른 브랜치 자원이 이 변경에 의존하면 브랜치 전체의 동작이 깨질 수 있으므로 계보를 먼저 확인합니다.
변경 제안 만들기
Owner 또는 해당 공간 Administrator가 Global Branching 앱이나 taskbar의 Create proposal을 선택합니다. 설명은 Markdown을 지원하므로 검토에 필요한 변경 목적과 범위를 기록할 수 있습니다.
제안 페이지에서 수정한 자원, 검사와 검토자를 확인합니다.
검사와 충돌
제안을 만들면 각 자원의 검사를 실행합니다. 모든 자원이 최신 main과 병합 가능해야 하며, 승인과 충돌 등의 모든 검사가 통과해야 제안을 병합합니다.
main보다 오래되었거나 충돌이 있으면 rebase 검사가 실패하고 해당 자원의 앱으로 이동하여 리베이스합니다. 충돌하지 않는 변경은 자동 해석하지만 같은 자원의 같은 속성을 양쪽에서 바꾼 실제 충돌은 사용자가 어느 버전을 사용할지 선택해야 합니다.
검토자
모든 승인 정책을 충족해야 합니다. 비보호 자원도 편집 권한 사용자의 승인이 필요할 수 있으며 기여자 권한으로 자동 충족하는 기본 정책과 구분합니다. 보호 자원은 해당 정책의 검토자를 요구합니다.
Awaiting approval 자원의 Manage에서 정책을 보고 필요한 검토자를 지정합니다. 지정한 검토자에게 알림을 보냅니다. Code Repositories와 Pipeline Builder의 정책은 해당 자원에서 정합니다.
검토자는 taskbar나 Global Branching의 Review로 자원별 검토 화면을 엽니다.
검토 과정에서 한 사용자라도 변경을 거부하면 그 자원의 상태가 Rejected가 되고 전체 제안 병합을 막습니다. 거부한 사용자가 다시 검토하고 Approve해야 병합할 수 있습니다.
병합과 빌드
승인과 검사를 모두 통과하고 Do not merge가 해제되어 있으면 Merge proposal을 사용할 수 있습니다. 제안을 볼 수 있는 사용자의 병합 권한을 적용합니다.
| 선택 | 병합 후 빌드 범위 |
|---|---|
| Build all affected resources | 변경의 영향을 받는 모든 자원. 직접 바꾸지 않은 downstream도 포함 |
| Build modified resources only | 이 브랜치에서 직접 바꾼 자원만 빌드. 의존 자원은 수동 빌드가 필요할 수 있음 |
| Do not build resources | 자동 빌드 없음. 병합 후 필요한 자원을 직접 빌드 |
일부 자원만 병합되고 다른 자원이 실패할 수 있습니다. 제안 페이지는 성공한 자원과 실패하여 브랜치에 남은 자원을 구분합니다. 부분 실패한 병합은 현재 되돌릴 수 없으므로 표시된 오류를 해결하고 병합을 다시 시도해야 합니다.
브랜치 상태와 보존
| 상태 | 동작 |
|---|---|
| Active | 개발 또는 병합 진행 중. 활성 상태인 동안 빌드/인덱싱한 데이터 유지 |
| Inactive | 무활동 기간 뒤 자동 전환. 온톨로지 인덱싱을 해제하고 이후 정책 기간에 데이터 삭제. 새 빌드는 즉시 실패 |
| Archived | 사용자가 수동 보관. 비활성과 같은 인덱싱 해제, 빌드 실패와 데이터 삭제 적용. 메타데이터는 유지하고 복원 가능 |
| Merged | 제안을 병합한 종료 상태. 복원할 수 없고 브랜치 선택기에서 숨김 |
기본으로 35일 동안 활동이 없으면 Inactive가 되고, 비활성화 후 7일이 지나면 데이터 삭제를 시작합니다. 공간의 Control Panel > Spaces > Actions > Global branch retention policy에서 기간을 설정합니다.
Inactive 또는 Archived로 바뀌면 Owner에게 이메일과 플랫폼 알림을 보냅니다. Inactive 표지를 제거하거나 자원을 열 때 Activate branch를 선택하여 다시 활성화할 수 있습니다.
Archived는 선택기에 나오지 않으며 Global Branching에서 열어 복원합니다. 자원을 열 때 Restore branch 안내가 나타날 수도 있습니다.
안내를 닫고 자원과 상호작용할 수는 있지만 권장하지 않습니다. Merged 브랜치는 선택기에서 접근할 수 없고 Global Branching 앱에서만 볼 수 있으며 복원할 수 없습니다.
활성화/복원 뒤 데이터와 로직 복구
상태를 되돌려도 이미 삭제한 데이터나 JobSpecs가 자동으로 되살아나는 것은 아닙니다.
| 자원 | 필요한 복구 경로 |
|---|---|
| 온톨로지 엔터티 | Ontology Manager banner의 재인덱싱 또는 설명의 작은 수정처럼 스키마 의미를 바꾸지 않는 변경으로 인덱싱 재시작 |
| Code Repository | 관련 transform의 주석 수정 등 변경을 커밋하고 Code Repositories 안에서 빌드하여 JobSpecs와 데이터를 다시 기록 |
| Pipeline Builder | Pipeline Builder에서 deploy 및 build하여 JobSpecs와 데이터 다시 생성 |
| 빌드 스케줄 | 반복 실패로 일시 중지되었으면 Build Schedules 또는 Data Lineage에서 수동 재개 |
Code Repository의 삭제한 JobSpecs를 복원하는 첫 빌드를 Data Lineage 같은 다른 앱에서 시작하면 JobSpecs를 다시 기록하지 못합니다.
로컬 Git 개발은 Inactive/Archived 브랜치 작업을 자동으로 막지 않으며 그 변경의 구체화 데이터나 JobSpecs가 삭제될 수 있습니다. AI FDE는 이 두 상태의 변경을 허용하지 않고 활성화 또는 복원을 요구합니다.
제안 상태
제안은 Open, Merged 또는 Closed입니다. Open은 진행 중이거나 승인한 상태, Merged는 main에 병합한 상태, Closed는 병합하지 않고 닫은 상태입니다. 열린 제안이 있는 브랜치를 보관하면 그 제안도 닫습니다.