파이프라인 브랜치와 릴리스 절차

릴리스 절차는 새 기능과 품질 수정의 개발 속도를 유지하면서 운영 데이터의 변경을 검토하는 과정입니다. 릴리스 단위인 제품은 함께 반영하는 자산의 묶음으로, 여러 코드 저장소와 다른 Foundry 리소스를 포함할 수 있습니다.

릴리스 단위 정하기

프로젝트 하나를 반드시 제품 하나로 취급할 필요는 없습니다. 공통 온톨로지 제품은 원천, 변환과 온톨로지 프로젝트가 만드는 출력 데이터셋의 집합일 수 있습니다. 개별 업무 프로젝트는 독립적인 업무 활용 제품으로 관리할 수 있습니다.

같은 제품에 속한 저장소는 브랜치 이름을 일관되게 사용하는 것이 권장됩니다. 하위 변환이 의도한 상위 데이터 브랜치를 읽도록 하기 위한 기준입니다. 코드 브랜치와 데이터셋 브랜치의 연결은 브랜치 개념에서 설명합니다.

기본 브랜치

GitFlow를 바탕으로 별도 release 브랜치를 생략한 구성을 사용할 수 있습니다. 검증한 변경을 dev에서 master로 병합하는 방식입니다.

[X]는 기능 이름이나 릴리스 식별자를 나타내는 이름 패턴입니다. 기능 브랜치에 입력 데이터셋이 아직 없고 폴백 구성을 바꾸지 않았다면 dev와 같은 입력을 읽습니다. 단순히 브랜치 이름만 같다고 항상 같은 데이터가 선택되는 것은 아닙니다.

보통 dev와 master를 동기화하고 기능 검증 중에만 차이를 유지하면 별도 긴급 수정 브랜치가 필요한 경우를 줄일 수 있습니다.

기능을 병행 개발하는 흐름

가상 기능 X와 Y를 개발하는 순서는 다음과 같습니다.

장기 major-release-[X] 브랜치에도 dev를 계속 병합하여 일반 기능 변경과의 차이를 줄이는 것이 권장됩니다. 원천 스키마가 바뀌어도 원천 및 변환 프로젝트에서 차이를 흡수하여 온톨로지의 출력 스키마를 가능한 한 안정적으로 유지합니다.

저장소 업그레이드

Code Repositories의 업그레이드는 구성 파일 수정, 언어 번들 의존성 버전 변경과 관련 수정 사항을 적용합니다. 일반 기능과 같은 브랜치 및 검토 과정을 거쳐 반영합니다.

안내에서 Upgrade를 누르지 못했더라도 오른쪽 위 ... 메뉴에서 사용할 수 있습니다.

1. 운영 브랜치를 직접 바꾸기보다 dev를 먼저 업그레이드합니다.
2. dev에서 업그레이드를 시작하면 자동 기능 브랜치가 생성됩니다.
3. CI 검사가 끝난 뒤 그 브랜치에서 빌드하여 변환이 새 구성에서 실행되는지 확인합니다.
4. 변경을 dev에 병합하고 PR로 master에 반영합니다.
5. 열린 기능 브랜치에도 dev를 병합하여 같은 업그레이드를 적용합니다.

검증일과 배포일

참여자들이 결과를 확인할 시간을 확보하려면 정해진 검증 및 배포 주기를 둘 수 있습니다. 예를 들어 수요일과 금요일에는 dev의 전체 출력 데이터셋을 빌드하여 검증하고, 그 기간에는 발견한 문제의 수정만 dev에 반영합니다. 검증이 끝나면 목요일과 월요일에 dev를 master로 병합하는 식입니다.

이는 팀이 합의할 일정 예시입니다. 개발자, 업무 검증자와 릴리스 관리자가 필요한 시간을 확보할 수 있도록 주기를 함께 정합니다.

실제 출력 검증

기능 개발이 끝나면 결과의 정확성과 하위 리소스에 미치는 영향을 검증합니다. 기능 브랜치의 출력 빌드는 같은 브랜치의 입력이 있으면 이를 사용하고, 없으면 설정된 폴백을 따라 dev나 master의 입력을 사용합니다.

개발자는 데이터 상태 검사, 검증용 파생 데이터셋 또는 Contour 같은 도구로 실제 출력을 확인할 수 있습니다. 샘플 미리보기만으로 승인을 끝내면 조인 등에서 드문 경우를 놓칠 수 있습니다. SQL helper도 코드의 구문 및 계산을 확인하는 도구이지 실제 빌드 출력의 모든 조건을 검증하는 도구는 아닙니다.

코드 검토와 사용자 검증 연결

1. 개발자가 기능 브랜치에서 dev로 PR을 만들고 구현 내용을 설명합니다.
2. 개발 리드가 변경을 검토하고 필요한 수정을 논의한 뒤 dev에 병합합니다.
3. 개발 리드가 dev에서 빌드하여 기능 출력 데이터셋을 만듭니다.
4. 개발자가 출력 데이터셋에 Foundry Issue를 만들고 시험 내용과 확인 요청을 적어 관련 사용자에게 배정합니다.
5. 사용자는 해당 데이터셋과 브랜치에서 정확성과 완전성을 검증합니다. 필요한 수정이 끝나면 병합 가능한 상태로 표시하고 릴리스 관리자에게 배정합니다.
6. 릴리스 관리자가 Issue를 닫고 dev를 master에 병합합니다.
7. 릴리스 관리자가 기능 브랜치를 삭제합니다.

닫힌 Issue도 남으므로 논의와 검증 결과를 변경 관리의 감사 이력으로 활용할 수 있습니다.

스키마 변경 검토

출력 스키마는 데이터를 소비하는 팀에 대한 인터페이스입니다. 열 이름이나 자료형 변경은 하위 소비자의 동작을 깨뜨릴 수 있으므로 PR의 Affected Datasets 탭에서 스키마 차이를 확인합니다.

기존 열을 바로 삭제하거나 바꾸기보다 새 열을 추가하고, 기존 열의 폐기 계획과 소비자의 변경 방법을 알리는 전환 방식을 사용할 수 있습니다. 이전 주요 릴리스에서 폐기를 알린 열은 다음 주요 릴리스에서 제거하는 식으로 조율합니다. 관련 소비자는 계보와 영향 분석을 통해 확인합니다.

Foundry Issues를 이용한 기능 검토

기능 검토 상태와 담당자 변경을 Issue로 기록하면 업무 사용자도 코드 PR에만 의존하지 않고 검증에 참여할 수 있습니다. 다음은 팀에 맞게 적용할 수 있는 절차입니다.

1. Foundry Explorer에서 빌드 출력 데이터셋을 선택합니다.
2. 전체 데이터셋에 대한 검토는 Report Issue로 등록합니다.
3. 특정 열의 기능이라면 열 수준 Issue를 사용하여 검토 범위를 명확히 합니다.
4. 양식의 필드를 작성합니다.
5. 라벨을 Feature Review: Request Review로 바꾸고 검토 담당자를 지정합니다. 필요한 라벨이 없으면 Palantir 담당자에게 구성을 요청합니다.

논의는 댓글에서 진행하고 Request Change 또는 Ready to Merge 상태 및 담당자를 변경하여 다음 작업을 넘깁니다. 사용자는 검증 방법과 결과를 기록하고 관련 리소스 링크를 첨부할 수 있습니다. 상태 변경과 검증 근거는 같은 Issue에 남습니다.