|
| 1 | +# 릴리스 전략 |
| 2 | + |
| 3 | +> [English](./RELEASE_STRATEGY.md) | 한국어 |
| 4 | +
|
| 5 | +## 개요 |
| 6 | + |
| 7 | +이 문서는 Changesets를 사용하여 버전 관리를 하고 독립적인 패키지 릴리스를 지원하는 vue3-pivottable 모노레포의 릴리스 전략을 설명합니다. |
| 8 | + |
| 9 | +## 릴리스 플로우 |
| 10 | + |
| 11 | +```mermaid |
| 12 | +sequenceDiagram |
| 13 | + participant F as feature 브랜치 |
| 14 | + participant D as develop |
| 15 | + participant M as main |
| 16 | + participant R as release/vX.X.X |
| 17 | + participant NPM as npm 레지스트리 |
| 18 | + |
| 19 | + Note over F,D: 1. 기능 개발 |
| 20 | + F->>D: changesets와 함께 PR |
| 21 | + D-->>D: 코드 리뷰 & 머지 |
| 22 | + |
| 23 | + Note over D,NPM: 2. 베타 릴리스 (자동) |
| 24 | + D-->>D: Changesets 소비 |
| 25 | + D-->>D: 버전 bump + beta 접미사 |
| 26 | + D-->>D: 품질 체크 (lint, typecheck) |
| 27 | + D-->>D: 모든 패키지 빌드 |
| 28 | + D->>NPM: @beta 퍼블리시 |
| 29 | + D-->>D: 변경사항 커밋 |
| 30 | + |
| 31 | + Note over D,M: 3. 프로덕션 준비 |
| 32 | + D->>M: PR (베타 버전, changesets 없음) |
| 33 | + M-->>M: 리뷰 & 머지 |
| 34 | + |
| 35 | + Note over M,NPM: 4. 안정 릴리스 (자동) |
| 36 | + M->>R: 릴리스 브랜치 생성 |
| 37 | + R-->>R: beta 접미사만 제거 |
| 38 | + R-->>R: 품질 체크 & 빌드 |
| 39 | + R->>NPM: @latest 퍼블리시 |
| 40 | + |
| 41 | + Note over R,M: 5. 동기화 |
| 42 | + R->>M: main 업데이트를 위한 PR |
| 43 | + M-->>M: 머지 (main에 안정 버전 반영) |
| 44 | +``` |
| 45 | + |
| 46 | +## 브랜치 책임 |
| 47 | + |
| 48 | +### develop 브랜치 |
| 49 | +- **목적**: 모든 기능의 통합 브랜치 |
| 50 | +- **자동 작업**: |
| 51 | + - changesets 소비 (파일 삭제됨) |
| 52 | + - changesets 기반 버전 bump |
| 53 | + - 타임스탬프와 함께 beta 접미사 추가 |
| 54 | + - 품질 체크 실행 (ESLint, TypeScript) |
| 55 | + - 모든 패키지 빌드 |
| 56 | + - @beta 태그로 npm에 퍼블리시 |
| 57 | + - 버전 변경사항을 develop에 커밋 |
| 58 | + |
| 59 | +### main 브랜치 |
| 60 | +- **목적**: 프로덕션 준비 코드만 |
| 61 | +- **보호**: 직접 푸시 불가 |
| 62 | +- **자동 작업**: |
| 63 | + - release/vX.X.X 브랜치 생성 |
| 64 | + - changeset 처리 없음 (develop에서 이미 완료) |
| 65 | + - 안정 릴리스 프로세스 트리거 |
| 66 | + |
| 67 | +### release/vX.X.X 브랜치 |
| 68 | +- **목적**: 안정 릴리스를 위한 임시 브랜치 |
| 69 | +- **자동 작업**: |
| 70 | + - 버전에서 beta 접미사 제거 |
| 71 | + - 품질 체크 실행 |
| 72 | + - 모든 패키지 빌드 |
| 73 | + - @latest 태그로 npm에 퍼블리시 |
| 74 | + - main으로 다시 PR 생성 |
| 75 | + |
| 76 | +## 패키지 독립성 |
| 77 | + |
| 78 | +모노레포는 독립적으로 버전이 관리되는 세 개의 패키지를 포함합니다: |
| 79 | + |
| 80 | +```mermaid |
| 81 | +graph TD |
| 82 | + A[Changeset 파일들] --> B{어떤 패키지?} |
| 83 | + B -->|vue-pivottable| C[메인 패키지] |
| 84 | + B -->|plotly-renderer| D[Plotly 렌더러] |
| 85 | + B -->|lazy-table-renderer| E[Lazy Table 렌더러] |
| 86 | + |
| 87 | + C --> F[독립 버전] |
| 88 | + D --> G[독립 버전] |
| 89 | + E --> H[독립 버전] |
| 90 | + |
| 91 | + F --> I[빌드 후 변경시만 퍼블리시] |
| 92 | + G --> J[빌드 후 변경시만 퍼블리시] |
| 93 | + H --> K[빌드 후 변경시만 퍼블리시] |
| 94 | +``` |
| 95 | + |
| 96 | +### 설정 |
| 97 | +```json |
| 98 | +{ |
| 99 | + "linked": [], // 연결된 패키지 없음 |
| 100 | + "fixed": [], // 고정 버전 없음 |
| 101 | + "access": "public" |
| 102 | +} |
| 103 | +``` |
| 104 | + |
| 105 | +이를 통해 각 패키지는: |
| 106 | +- 자체 버전 번호를 가짐 |
| 107 | +- 독립적으로 릴리스 가능 |
| 108 | +- 변경사항이 있을 때만 퍼블리시 |
| 109 | + |
| 110 | +## 버전 예시 |
| 111 | + |
| 112 | +### 시나리오 1: 단일 패키지 업데이트 |
| 113 | +```yaml |
| 114 | +# 메인 패키지의 버그 수정을 위한 Changeset |
| 115 | +"vue-pivottable": patch |
| 116 | + |
| 117 | +# develop에서의 결과: |
| 118 | +vue-pivottable: 1.1.1 → 1.1.2-beta.1234567890 |
| 119 | +@vue-pivottable/plotly-renderer: 2.0.0 (변경 없음) |
| 120 | +@vue-pivottable/lazy-table-renderer: 1.0.13 (변경 없음) |
| 121 | + |
| 122 | +# main/release에서의 결과: |
| 123 | +vue-pivottable: 1.1.2-beta.1234567890 → 1.1.2 |
| 124 | +# 다른 패키지는 퍼블리시되지 않음 |
| 125 | +``` |
| 126 | + |
| 127 | +### 시나리오 2: 다중 패키지 업데이트 |
| 128 | +```yaml |
| 129 | +# 새 기능을 위한 Changesets |
| 130 | +"vue-pivottable": minor |
| 131 | +"@vue-pivottable/plotly-renderer": minor |
| 132 | + |
| 133 | +# develop에서의 결과: |
| 134 | +vue-pivottable: 1.1.1 → 1.2.0-beta.1234567890 |
| 135 | +@vue-pivottable/plotly-renderer: 2.0.0 → 2.1.0-beta.1234567890 |
| 136 | +@vue-pivottable/lazy-table-renderer: 1.0.13 (변경 없음) |
| 137 | + |
| 138 | +# main/release에서의 결과: |
| 139 | +vue-pivottable: 1.2.0-beta.1234567890 → 1.2.0 |
| 140 | +@vue-pivottable/plotly-renderer: 2.1.0-beta.1234567890 → 2.1.0 |
| 141 | +# lazy-table-renderer는 퍼블리시되지 않음 |
| 142 | +``` |
| 143 | + |
| 144 | +## 품질 게이트 |
| 145 | + |
| 146 | +### PR 체크 (pr-check.yml) |
| 147 | +1. ESLint - 모든 패키지 |
| 148 | +2. TypeScript 타입 체킹 - 모든 패키지 |
| 149 | +3. 빌드 검증 - 모든 패키지 |
| 150 | +4. Changeset 존재 확인 |
| 151 | + |
| 152 | +### 릴리스 체크 |
| 153 | +1. 빌드 전 타입 체킹 |
| 154 | +2. 빌드 전 린팅 |
| 155 | +3. 퍼블리시를 위해 빌드 성공 필수 |
| 156 | +4. 오류 허용 퍼블리싱 (한 패키지가 실패해도 다른 패키지 계속 진행) |
| 157 | + |
| 158 | +## 워크플로우 파일 |
| 159 | + |
| 160 | +### 1. `.github/workflows/pr-check.yml` |
| 161 | +- **트리거**: main 또는 develop으로의 PR |
| 162 | +- **체크**: Lint, TypeCheck, Build, Changesets |
| 163 | +- **목적**: 머지 전 코드 품질 보장 |
| 164 | + |
| 165 | +### 2. `.github/workflows/release-develop.yml` |
| 166 | +- **트리거**: develop으로 푸시 |
| 167 | +- **작업**: 버전 관리, 빌드, @beta 퍼블리시 |
| 168 | +- **핵심 기능**: changesets 소비 |
| 169 | + |
| 170 | +### 3. `.github/workflows/release.yml` |
| 171 | +- **트리거**: main으로 푸시 |
| 172 | +- **작업**: beta 접미사 제거, 빌드, @latest 퍼블리시 |
| 173 | +- **핵심 기능**: changeset 불필요 |
| 174 | + |
| 175 | +## 보안 |
| 176 | + |
| 177 | +### npm 토큰 |
| 178 | +- `NPM_TOKEN`: 메인 패키지 퍼블리싱 |
| 179 | +- `NPM_TOKEN_SUMIN`: 스코프 패키지 퍼블리싱 |
| 180 | +- GitHub Secrets로 저장 |
| 181 | + |
| 182 | +### 브랜치 보호 |
| 183 | +- main: PR 필수, 직접 푸시 불가 |
| 184 | +- develop: CI 커밋을 위해 열려있음 |
| 185 | +- release/*: 임시, 자동 생성 |
| 186 | + |
| 187 | +## 명령어 참조 |
| 188 | + |
| 189 | +| 명령어 | 설명 | |
| 190 | +|---------|-------------| |
| 191 | +| `pnpm changeset add` | 변경사항에 대한 changeset 추가 | |
| 192 | +| `pnpm changeset status` | 대기 중인 changesets 확인 | |
| 193 | +| `pnpm build:all` | 모든 패키지 빌드 | |
| 194 | +| `pnpm typecheck` | TypeScript 체크 실행 | |
| 195 | +| `pnpm lint` | ESLint 실행 | |
| 196 | +| `pnpm -r <command>` | 모든 워크스페이스에서 명령 실행 | |
| 197 | + |
| 198 | +## 모범 사례 |
| 199 | + |
| 200 | +1. **항상 changesets 추가** - 릴리스를 트리거해야 하는 변경사항에 대해 |
| 201 | +2. **베타에서 먼저 테스트** - main으로 승인하기 전에 npm @beta 확인 |
| 202 | +3. **독립 버전** - 변경되지 않은 패키지는 bump하지 않음 |
| 203 | +4. **품질 우선** - 퍼블리시 전 모든 체크 통과 필수 |
| 204 | + |
| 205 | +## 릴리스 프로세스 중 업데이트 처리 |
| 206 | + |
| 207 | +### 시나리오: main으로의 PR 이후 develop 변경사항 |
| 208 | + |
| 209 | +develop에서 main으로의 PR이 이미 열려있고 develop에 새로운 변경사항이 푸시되는 경우: |
| 210 | + |
| 211 | +1. **자동 PR 업데이트** |
| 212 | + - release-develop 워크플로우가 기존 PR을 자동으로 감지 |
| 213 | + - PR 제목을 새 베타 버전으로 업데이트 |
| 214 | + - PR 설명에 타임스탬프와 새 버전 정보 업데이트 |
| 215 | + - `auto-updated`와 `needs-review` 라벨 추가 |
| 216 | + - PR을 "ready for review" 상태로 설정 |
| 217 | + |
| 218 | +2. **리뷰 프로세스** |
| 219 | + - 리뷰어는 라벨을 통해 업데이트 알림을 받음 |
| 220 | + - 이전 승인은 유지되지만 재검토 권장 |
| 221 | + - PR 설명에 명확한 "Updated" 상태와 타임스탬프 표시 |
| 222 | + |
| 223 | +3. **장점** |
| 224 | + - PR 히스토리와 토론 내용 보존 |
| 225 | + - 수동 개입 불필요 |
| 226 | + - 모든 베타 버전의 명확한 감사 추적 |
| 227 | + |
| 228 | +### 예시 플로우 |
| 229 | +``` |
| 230 | +1. v1.2.0-beta.1234567890 → PR #123 생성 |
| 231 | +2. develop에 새로운 수정사항 푸시 |
| 232 | +3. v1.2.1-beta.2345678901 → PR #123 자동 업데이트 |
| 233 | +4. 리뷰어가 "auto-updated" 라벨 확인 후 재검토 |
| 234 | +5. 승인 후 main으로 머지하면 안정 릴리스 트리거 |
| 235 | +``` |
| 236 | + |
| 237 | +## 문제 해결 |
| 238 | + |
| 239 | +### 베타 버전이 퍼블리시되지 않나요? |
| 240 | +- changesets가 존재하는지 확인 |
| 241 | +- 빌드가 성공하는지 검증 |
| 242 | +- npm 토큰 권한 확인 |
| 243 | + |
| 244 | +### 패키지가 업데이트되지 않나요? |
| 245 | +- changeset에 패키지 이름이 포함되어 있는지 확인 |
| 246 | +- 패키지에 빌드 스크립트가 있는지 확인 |
| 247 | +- package.json의 이름이 일치하는지 검증 |
| 248 | + |
| 249 | +### CI에서는 타입 오류가 있는데 로컬에서는 없나요? |
| 250 | +- 로컬에서 `pnpm typecheck` 실행 |
| 251 | +- 모든 워크스페이스 패키지 확인: `pnpm -r typecheck` |
| 252 | +- 의존성이 최신인지 확인 |
| 253 | + |
| 254 | +### PR이 자동으로 업데이트되지 않나요? |
| 255 | +- GitHub Actions 권한 확인 |
| 256 | +- GITHUB_TOKEN이 PR 쓰기 권한을 가지고 있는지 검증 |
| 257 | +- PR이 열린 상태인지 확인 |
0 commit comments