# リリース

Tuistでは、意味のある変更がメインブランチにマージされると自動的に新しいバージョンを公開する継続的リリースシステムを採用しています。このアプローチにより、メンテナが手動で介入することなく、改良が迅速にユーザーに届くことが保証される。

## 概要

私たちは3つの主要コンポーネントを継続的にリリースしている：
- **Tuist CLI** - コマンドラインツール
- **Tuist Server** - バックエンド・サービス
- **Tuist App** - macOSおよびiOSアプリ（iOSアプリはTestFlightにのみ継続的にデプロイされる。

各コンポーネントには独自のリリースパイプラインがあり、メインブランチにプッシュするたびに自動的に実行される。

## 仕組み

### 1.規約の遵守

コミットメッセージの構造化には[Conventional
Commits](https://www.conventionalcommits.org/)を使用しています。これにより、私たちのツールは変更の性質を理解し、バージョンバンプを決定し、適切な変更ログを生成することができます。

フォーマット:`タイプ(スコープ): 説明`

#### コミットの種類とその影響

| タイプ     | 説明           | バージョン・インパクト          | 例                               |
| ------- | ------------ | -------------------- | ------------------------------- |
| `見事`    | 新機能または能力     | マイナーバージョンアップ (x.Y.z) | `feat(cli)：Swift6のサポートを追加。`     |
| `フィックス` | バグ修正         | パッチのバージョンバンプ (x.y.Z) | `fix(app)：プロジェクトを開く際のクラッシュを解決`  |
| `諸注意`   | ドキュメントの変更    | リリースなし               | `ドキュメント：アップデート・インストール・ガイド`      |
| `スタイル`  | コードスタイルの変更   | リリースなし               | `スタイル：swiftformatでコードをフォーマットする` |
| `手戻り`   | コードのリファクタリング | リリースなし               | `refactor(server)：認証ロジックの簡素化`   |
| `完璧`    | パフォーマンス向上    | パッチのバージョンアップ         | `perf(cli): 依存関係の解決を最適化する`      |
| `テスト`   | テストの追加／変更    | リリースなし               | `test: キャッシュのユニットテストを追加`        |
| `雑用`    | メンテナンス・タスク   | リリースなし               | `chore: 依存関係の更新`                |
| `ci`    | CI/CDの変更     | リリースなし               | `ci: リリースのワークフローを追加`            |

#### 変化への対応

破格の変更はメジャーバージョンアップ(X.0.0)の引き金となるため、コミット本文に明記する必要があります：

```
feat(cli): change default cache location

BREAKING CHANGE: The cache is now stored in ~/.tuist/cache instead of .tuist-cache.
Users will need to clear their old cache directory.
```

### 2.変更検出

各コンポーネントは[git cliff](https://git-cliff.org/)を使っている：
- 前回のリリース以降のコミットを分析する
- スコープ（cli、app、server）によるコミットのフィルタリング
- リリース可能な変更があるかどうかを判断する
- 変更履歴の自動生成

### 3.パイプラインの解放

リリース可能な変更が検出された場合：

1. **バージョン計算** ：パイプラインが次のバージョン番号を決定する
2. **変更履歴の生成**: git cliff がコミットメッセージから変更履歴を生成する
3. **ビルド・プロセス** ：コンポーネントがビルドされ、テストされる
4. **リリース作成** ：GitHubリリースが成果物とともに作成される
5. **ディストリビューション** ：アップデートはパッケージマネージャにプッシュされる (例: Homebrew for CLI)

### 4.スコープフィルタリング

各コンポーネントは、関連する変更があった場合にのみリリースする：

- **CLI**:`(cli)` スコープ付きコミット、またはスコープなしコミット
- **アプリ** ：`(app)` スコープでのコミット
- **サーバー** ：`(サーバー)` スコープのコミット

## 良いコミットメッセージを書く

コミットメッセージはリリースノートに直接影響を与えるので、明確で説明的なメッセージを書くことが重要です：

### やるんだ：
- 現在形を使う："add feature "ではなく、"add feature"
- 簡潔でありながら、説明的であること
- 変更がコンポーネント固有のものである場合は、スコープを含める。
- 該当する場合、問題を参照:`fix(cli): ビルドキャッシュの問題を解決 (#1234)`

### やめてくれ：
- "バグを修正 "や "コードを更新 "といった曖昧なメッセージを使う。
- 1つのコミットで複数の無関係な変更を混在させる
- 変更情報の入れ忘れ

### 変化への対応

変更を加える場合は、コミット本文に`BREAKING CHANGE:` を含めてください：

```
feat(cli): change cache directory structure

BREAKING CHANGE: Cache files are now stored in a new directory structure.
Users need to clear their cache after updating.
```

## リリース・ワークフロー

リリースのワークフローは
- `.github/workflows/cli-release.yml` - CLI リリース
- `.github/workflows/app-release.yml` - アプリのリリース
- `.github/workflows/server-release.yml` - サーバーリリース

それぞれのワークフロー
- メインへのプッシュで走る
- 手動でトリガー可能
- 変更の検出にはgit cliffを使用
- リリースプロセス全体を処理

## モニタリング・リリース

リリースの監視は
- [GitHubリリースページ](https://github.com/tuist/tuist/releases)。
- ワークフロー実行用のGitHub Actionsタブ
- 各コンポーネントのディレクトリにある変更履歴ファイル

## メリット

この継続的なリリースのアプローチは、以下を提供する：

- **迅速な納品** ：マージ後すぐに変更がユーザーに届く
- **ボトルネックの削減** ：マニュアルリリースを待つ必要がない
- **明確なコミュニケーション** ：コミットメッセージからの変更履歴の自動化
- **一貫したプロセス** ：すべてのコンポーネントで同じリリースフロー
- **品質保証** ：テストされた変更のみがリリースされる

## トラブルシューティング

リリースに失敗した場合

1. 失敗したワークフローの GitHub Actions ログを確認する
2. コミットメッセージは従来の書式に従うようにしてください。
3. すべてのテストが合格することを確認する
4. コンポーネントが正常にビルドされたことを確認する

即時リリースが必要な緊急の修正
1. コミットの範囲を明確にする
2. マージ後、リリースのワークフローを監視する。
3. 必要であれば、マニュアルリリースを作動させる

## App Storeリリース

CLIとサーバーは上記の継続的リリース・プロセスに従いますが、**iOSアプリ** はAppleのApp Store審査プロセスのため例外となります：

- **手動リリース**: iOSアプリのリリースには、App Storeへの手動申請が必要です。
- **レビューの遅れ** ：各リリースはAppleの審査プロセスを通過する必要があり、1-7日かかることがあります。
- **一括変更** ：通常、iOS の各リリースでは複数の変更がまとめて行われます。
- **TestFlight** ：ベータ版は、App Storeリリース前にTestFlight経由で配布される場合があります。
- **リリースノート** ：App Storeガイドライン用に特別に作成する必要があります。

iOSアプリは相変わらず同じコミット規約に従い、変更ログ生成にはgit
cliffを使用していますが、ユーザーへの実際のリリースはそれほど頻繁ではなく、手作業によるスケジュールで行われます。