브랜칭 및 릴리스 프로세스

이 문서의 목적은 Code Repositories 내의 프로젝트를 통해 관리되는 데이터 파이프라인의 브랜치 관리 및 릴리스 프로세스에 대한 권장되는 최선의 방법을 개요하고 있습니다.

하이레벨의 목표는 새로운 데이터 기능/데이터 품질 수정에 대한 빠른 반복과 안정적이고 프로세스 준수적인 변경 관리 프로세스 사이의 균형을 맞추는 프로세스를 설계하는 것입니다.

릴리스 범위

릴리스 관리 프로세스의 내부로 들어가기 전에 우리가 릴리스하는 "제품이 무엇인지"를 더 잘 정의할 필요가 있습니다. 우리의 목적을 위해 우리는 제품을 개념적 단위로 릴리스되는 자산 세트로 정의할 것입니다.

우리가 Foundry에서 파이프라인을 빌드하는 방법에 대한 권장 프로젝트 구조를 참조하면, 파이프라인은 다양한 유형의 여러 프로젝트 - 데이터소스, 변형, 온톨로지 및 워크플로에 의해 정의된다는 것을 알 수 있습니다. 그러나 대부분의 경우, 우리는 각 프로젝트를 제품으로 독립적으로 관리하지 않고, 대신 각 프로젝트는 자원의 하위 집합을 다음 제품 유형 중 하나로 정의할 것입니다:

• 온톨로지 제품: 이 제품은 데이터소스, 파이프라인, 온톨로지 프로젝트에서 생성된 결과물 데이터셋의 모음입니다.
• 유즈케이스 제품: 모든 유즈케이스 프로젝트는 자체적으로 존재하는 특정 유즈케이스를 나타냅니다. 각 유즈케이스는 제품으로 정의됩니다.

제품 브랜치 관리

다음 섹션은 우리가 각 제품의 릴리스를 관리하기 위해 배포하려는 브랜칭 전략을 참조합니다. 일반적인 브랜칭과 Code Repositories와 데이터셋 사이에서 브랜치가 어떻게 작동하는지에 대해 더 알아보기.

우리가 권장하는 일반적인 브랜치 전략은 GitFlow라는 흔한 실무에 기반하고 있으며 일부 수정이 있습니다. 주요 변경사항은 릴리스 브랜치를 생략하는 것입니다. Foundry에서 아티팩트가 배포되는 방식 때문에, 우리는 테스트 후에 dev에서 master로 직접 변경 사항을 병합할 수 있습니다.

공통 브랜치

master - 이것은 프로덕션 브랜치입니다. 따라서, 이것은 보호된 브랜치이며 릴리스 관리자 역할만이 이 브랜치로 PR을 병합하는 것을 승인할 수 있습니다. master 브랜치는 프로덕션 데이터를 가져오는 것으로 가정됩니다.

dev - dev(개발) 브랜치는 master 브랜치에서 파생된 스테이징 브랜치입니다. 테스트 데이터를 사용하여 완전한 기능을 테스트하려는 경우에 주로 관련이 있습니다. dev 브랜치는 master에서 가져올 수 있습니다(fallback branches를 통해 자동으로 발생) 또는 UAT 데이터 소스에서 가져올 수 있습니다.

feature-[X] - feature 브랜치는 주어진 기능이 개발되고 테스트되는 곳입니다. 이 브랜치는 dev 브랜치에서 파생됩니다. 이것은 수명이 짧은 브랜치로, 브랜치가 master에 병합되면 삭제될 수 있습니다. 브랜치가 dev에서 파생되었기 때문에 dev 브랜치가 가지고 있는 같은 데이터로 소스가 될 것입니다. 이것은 fallback 브랜치가 재설정되지 않는 한, 그리고 입력 데이터셋이 feature 브랜치에 존재하지 않는 한 계속 참입니다.

다른 특별한 브랜치

major-release-[X] - 소스 시스템의 스키마 변경으로 인해 필요한 모든 변경 사항을 통합하는 특별한 브랜치(특정 주기에 발생).

hot-fix-[X] - 프로덕션에서 발견된 문제를 수정하는 데 사용되는 특별한 브랜치로, 코드 베이스가 새 버전으로 이동했습니다. 우리는 dev와 master가 동기화되어 있다고 가정합니다(활성 테스트 중인 기능이 없는 한), 따라서 이러한 브랜치가 필요할 것으로 보이지 않습니다.

브랜치 관리 워크플로

위에서 설명한 것처럼, 일부 브랜치는 영구적인 반면 다른 브랜치는 수명이 짧습니다. 다음 섹션에서는 브랜치 간의 권장 워크플로를 설명합니다.

• t0에서, master 및 dev 브랜치가 생성됩니다.

• t1에서, feature x 브랜치가 dev에서 생성됩니다.

• t2에서, feature y 브랜치가 dev에서 생성됩니다.

• t3에서, feature x가 dev에 병합됩니다.

• t4에서, dev가 master에 병합되고, feature x 브랜치가 삭제됩니다.

• t5에서, dev가 feature y에 병합되어 dev의 최신 상태를 가져옵니다.

• t6에서, feature y가 dev에 병합되고 나중에 dev에서 master로 병합됩니다.

dev 및 master에 개발 및 릴리스 된 기능 외에도 major-release-[X]와 같은 주요 릴리스를 위한 장기간 브랜치가 개발되고 있습니다.

dev를 major-release-[X]에 계속 병합하는 것이 권장됩니다. 따라서 최신 기능이 동기화되어 있습니다. 우리는 온톨로지 스키마를 가능한 한 안정적으로 유지하고 데이터소스 및 변환 프로젝트의 변환을 통해 백엔드 스키마 변경을 숨기는 것을 권장합니다.

저장소 업그레이드

_저장소 업그레이드_는 Code Repositories의 설정 파일을 업데이트하라는 주기적인 프롬프트입니다. 이 업데이트는 언어 번들 종속성의 수정이나 버전을 올리는 업데이트를 적용하며, 이러한 권장 업그레이드를 적용하는 것이 최선의 방법입니다.

"Upgrade" 버튼을 클릭하는 것을 놓치면, 이 버튼은 상단 오른쪽의 "..." 옵션 메뉴에서 모든 브랜치에서도 사용할 수 있습니다:

업그레이드 프로세스는 기능 개발 주기와 같이 처리되어야 합니다. 이것은:

1. master는 dev를 통해 업그레이드되어야 합니다.

2. dev를 업그레이드하라는 프롬프트가 나오면 자동화된 feature 브랜치가 생성됩니다. CI 체크가 완료된 후 이 브랜치에서 빌드를 실행하여 설정 변경 사항을 테스트할 수 있습니다. 업그레이드 후에도 변환들이 여전히 실행되는지 확인한 후, dev에 설정 변경 사항을 병합합니다. dev가 업그레이드되면, 이러한 변경 사항을 master로 푸시하는 데 PR이 사용되어야 합니다.

3. 모든 열린 feature 브랜치를 업그레이드하려면, 이러한 구성 업그레이드를 포함하기 위해 dev를 각 브랜치로 다시 병합합니다.

유지 관리 창

생각에서 생산까지의 빠른 반복 루프는 개발 실무에서 일반적이며, 최종 사용자 피드백에 의존하는 프로젝트의 성공에 매우 중요합니다. 이러한 프로세스를 지원하기 위해, 우리는 사전에 정의된 유지 관리 창을 설정하는 것을 권장합니다.

예를 들어, 모든 기능 PR이 병합되면, dev 브랜치에서 모든 데이터셋이 빌드되어 결과를 수요일과 금요일에 확인할 수 있습니다. 이 날들 동안, 검증 중에 발견된 문제에 대한 수정만이 dev에 병합되고, dev는 최종적으로 목요일과 월요일, "릴리스 날"에 master로 병합됩니다.

이러한 주기에 모든 관련 당사자가 이 날들 동안 새로운 기능을 밀어내기 위해 충분한 시간을 투자하도록 합의하는 것이 권장됩니다.

기능 테스팅 및 최종 사용자 검증

기능 개발이 완료되면 기능 결과의 정확성과 모든 종속 리소스에 미치는 영향을 테스트하고 검증하는 것이 중요합니다. Code Repositories에서는 출력 데이터셋을 테스트해야 하는 기능 결과로 생각합니다.

위에서 정의한 브랜치 구조에 따라, 출력 데이터셋을 빌드할 때는 기능의 동일한 브랜치에서 입력 데이터셋의 데이터를 사용하거나, fallback 로직을 통해 소스 브랜치에서 읽게 됩니다. 이것은 간단한 버전에서는 master이고 다른 버전에서는 dev입니다.

개발자 수준의 테스트는 데이터셋 건강 체크, 종속 테스트 데이터셋, 또는 Contour과 같은 도구를 수동으로 사용하여 수행할 수 있습니다.

기능 개발이 완료되면, 새 기능 코드는 dev 브랜치에 병합되기 전에 검토되어야 하며, 기능 결과는 최종 사용자에 의해 정확성과 완전성을 검증해야 합니다.

우리는 첫 번째에 대해 Pull Request 리뷰와 두 번째에 대해 Foundry Issues를 사용하는 조합을 권장하며, 아래 다이어그램에서 설명합니다.

1. 개발자는 feature 브랜치에서 dev 브랜치로 pull request를 생성하고 구현 코멘트를 추가합니다.

2. dev-lead는 PR을 검토하고, 개발자와 필요한 변경 사항에 대해 협업하고, 마침내 PR을 dev에 병합합니다.

3. dev-lead는 dev 브랜치에서 빌드를 실행하여 기능 결과 데이터셋을 생성합니다.
4. 개발자는 결과 데이터셋에 Foundry Issue를 생성하고, 모든 테스트 및 검증 요청을 문서화하고, 이슈를 검증을 위한 관련 최종 사용자에게 할당합니다.
5. 최종 사용자는 이슈를 받고, 테스트해야 하는 관련 데이터셋과 브랜치의 전체 컨텍스트와 뷰를 보입니다. 그들은 필요한 변경 사항에 대해 개발자와 협업하고 이슈가 해결되고 병합 준비가 완료되면 이슈를 릴리스 관리자에게 할당합니다.
6. 릴리스 관리자는 이슈를 닫고 dev를 master에 병합합니다.
7. 릴리스 관리자는 feature 브랜치를 삭제합니다.

위의 워크플로는 당사자 간의 상대적으로 빠른 협업 주기를 가능하게 하면서 컨텍스트를 잃지 않습니다. 닫힌 이슈는 플랫폼에 보관되어 변경 관리 프로세스의 감사 추적을 수행할 수 있습니다.

Foundry Issues 기능 리뷰 워크플로

아래는 팀이 Foundry Issues를 사용하여 다른 이해당사자들로부터의 리뷰 요청을 추적하고, 새 기능에 대한 대화를 진행하며, 코드를 master에 병합하는 프로세스를 제어하고 문서화하는 방법의 예입니다. 모든 관심 있는 당사자들이 계속 알고 있고 최신 상태를 유지하도록 합니다. 이것을 지향적이라고 간주하고, 필요에 따라 기존의 운영 및 기술 프로세스에 맞게 조정하십시오.

워크플로 예시

개발자가 처음으로 기능 리뷰 요청 이슈를 생성할 때, 이슈는 Feature Review: Request Review 상태로 할당됩니다. 이슈는 기능이 특정하다면 데이터셋 또는 특정 열에 첨부할 수 있습니다.

최종 사용자와의 협업은 코멘트 섹션을 통해 이루어지며 Request Change 또는 Ready to Merge 사이에서 상태를 변경하고 이슈의 할당자를 변경하면서 이루어집니다.

Issues는 기능 리뷰 워크플로를 저장하는 좋은 장소입니다. 최종 사용자들은 검증 프로세스를 문서화하고(감사 목적으로) 다른 자산에 대한 링크를 첨부할 수 있습니다.

아래의 다이어그램은 빌드 결과 데이터셋에 이슈가 생성되는 방법을 보여줍니다.

1. Foundry Explorer에서 출력 데이터셋을 선택합니다.

2. Report Issue를 클릭하여 전체 데이터셋에 이슈를 보고합니다.

3. 기능이 특정 열과 관련이 있다면, 변경 사항에 대한 더 나은 컨텍스트를 제공하기 위해 열 수준 보고 이슈를 사용할 수 있습니다.

4. 양식에 의해 프롬프트되는 이슈 필드를 완료합니다.

5. 이슈가 생성되면 Feature Review: Request Review로 레이블을 변경하는 것을 잊지 마십시오. (이러한 레이블을 사용할 수 없는 경우 Palantir 대표에게 연락하십시오.)

리뷰 프로세스가 계속되면서, 모든 상태 변경과 검증 증거를 포함하는 협업 스레드는 이슈에 저장됩니다.