リリース

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

概要

私たちは3つの主要コンポーネントを継続的にリリースしている：

• Tuist CLI - コマンドラインツール
• Tuist Server - バックエンド・サービス
• Tuist App - macOSおよびiOSアプリ（iOSアプリはTestFlightにのみ継続的にデプロイされる。

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

仕組み

1.規約の遵守

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

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

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

タイプ	説明	バージョン・インパクト	例
見事	新機能または能力	マイナーバージョンアップ (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を使っている：

• 前回のリリース以降のコミットを分析する
• スコープ（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リリースページ。
• ワークフロー実行用の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を使用していますが、ユーザーへの実際のリリースはそれほど頻繁ではなく、手作業によるスケジュールで行われます。