Part IV. Branching 실전 워크플로우
Part II와 Part III에서 branch가 pageserver 안에서 어떤 구조로 만들어지는지 확인했습니다. 이 Part에서는 시선을 storage 내부에서 개발 흐름으로 옮깁니다. Neon 클라우드 서비스의 CLI와 API로 branch를 만들고, PR마다 격리된 database를 연결합니다. schema migration을 미리 실행하고, 잘못된 변경을 되돌리는 절차도 차례로 다룹니다.
이 Part의 명령은 Neon 클라우드(console.neon.tech)를 대상으로 합니다. Part III의 자체 호스팅 환경에는 control plane이 없으므로 neon CLI가 동작하지 않습니다. 같은 개념을 pageserver API로 직접 수행하는 방법은 3.2 첫 Branch 만들기에서 다뤘습니다.
이 Part에서 다루는 것
- 4.1 Neon CLI와 API: 설치, 인증, branch 명령 전체, REST API 본문, 플랜별 한도
- 4.2 PR마다 Branch: GitHub Actions: PR 열림과 닫힘에 맞춘 branch 생명주기, Neon Local로 같은 패턴을 로컬에서 재현
- 4.3 Schema Migration 리허설: production 부모에서 branch를 만들어 migration을 미리 실행하고 측정하는 절차
- 4.4 Instant Restore, Reset, Snapshot: history window 안의 시점으로 되돌리기, 부모 상태로 초기화, snapshot 보관
- 4.5 Schema-only Branch와 민감 데이터: 데이터 없이 schema만 가진 root branch와 익명화 데이터 채우기
- 4.6 AI Agent 워크플로우: agent마다 branch를 할당하고 체크포인트와 복구를 적용하는 방식
읽기 전에 준비할 것
Neon 계정과 프로젝트 하나가 필요합니다. Free 플랜으로 이 Part의 예제 대부분을 실행할 수 있습니다. 다만 보호 branch는 Free에서 제공되지 않습니다. manual snapshot도 한 개까지만 만들 수 있습니다. 따라서 보호 branch를 쓰는 예제와 snapshot 두 개를 만드는 4.6 연습은 Launch 이상이 필요합니다. 플랜별로 branch 개수, root branch 개수, history window가 다릅니다. 각 장의 한도 표를 먼저 확인합니다.
npm i -g neon
neon auth
neon projects list
CLI 이름은 neon이며 neonctl은 같은 실행 파일의 별칭입니다. 이 노트에서는 neon으로 통일합니다.
이 Part를 읽고 답할 수 있어야 하는 질문
neon branches create와 REST API의parent_lsn,parent_timestamp,init_source는 각각 어떤 branch를 만드는가?- PR이 닫힌 뒤 branch를 삭제할 책임은 누구에게 있으며, 삭제하지 못했을 때 어떤 장치가 남는가?
- restore와 reset은 무엇이 다르며, 어느 쪽이 백업 branch를 남기는가?
- schema-only branch가 일반 branch와 달리 reset되지 않는 이유는 무엇인가?
- agent가 만든 수백 개 branch의 비용은 어디에서 발생하며 어떻게 정리하는가?