ベストプラクティス
長年、さまざまなチームやプロジェクトと作業する中で、私たちはTuistやXcodeプロジェクトで作業する際に従うことを推奨する一連のベストプラクティスを特定しました。これらのプラクティスは強制的なものではありませんが、維持と拡張を容易にする方法でプロジェクトを構造化するのに役立ちます。
Xcode
落胆パターン
リモート環境をモデル化するための設定
多くの組織では、異なるリモート環境をモデル化するためにビルド構成を使用している(例:Debug-Production やRelease-Canary )が、この方法にはいくつかの欠点がある:
- 不整合: グラフ全体にコンフィギュレーションの不整合があると、ビルドシステムはターゲットによっては間違ったコンフィギュレーションを使用してしまうかもしれない。
- 複雑さ: プロジェクトは、推論や保守が困難なローカル設定やリモート環境の長いリストを抱えることになりかねない。
ビルド構成は、さまざまなビルド設定を具現化するために設計されており、プロジェクトがDebug とRelease 以上のものを必要とすることはほとんどない。異なる環境をモデル化する必要性は、さまざまな方法で達成できる:
- デバッグビルドでは 開発時にアクセス可能なすべてのコンフィギュレーションをアプリに含めることができます(エンドポイントなど)。切り替えは、スキーム起動環境変数を使用するか、アプリ内のUIで行うことができます。
- リリースビルドの場合: リリースの場合、リリースビルドがバインドしているコンフィギュレーションのみを含めることができ、コンパイラディレクティブを使用してコンフィギュレーションを切り替えるためのランタイムロジックを含めることはできません。
::: 情報 非標準のコンフィギュレーション
Tuistは非標準のコンフィギュレーションをサポートし、バニラXcodeプロジェクトと比較してそれらを管理しやすくしていますが、コンフィギュレーションが依存関係グラフ全体で一貫していない場合は警告が表示されます。これは、ビルドの信頼性を確保し、構成に関連する問題を防ぐのに役立ちます。
:::
プロジェクト生成
構築可能なフォルダ
Tuist 4.62.0は、ビルド可能なフォルダ (Xcodeの同期グループ)のサポートを追加した。これはXcode 16で導入された機能で、マージの衝突を減らすことができる。
Tuistのワイルドカードパターン(例えば、Sources/**/*.swift )は、すでに生成されたプロジェクトにおけるマージ競合を排除しているが、ビルド可能なフォルダにはさらなる利点がある:
- 自動同期 :プロジェクト構造はファイルシステムと同期したまま-ファイルの追加や削除時に再生成は不要
- AIフレンドリーなワークフロー :コーディングアシスタントやエージェントは、プロジェクトの再生をトリガーすることなくコードベースを修正できる
- よりシンプルなコンフィギュレーション :明示的なファイルリストを管理する代わりにフォルダパスを定義する
より合理的な開発体験のために、従来のTarget.sources およびTarget.resources 属性の代わりに、ビルド可能なフォルダを採用することを推奨する。
swift
let target = Target(
name: "App",
buildableFolders: ["App/Sources", "App/Resources"]
)swift
let target = Target(
name: "App",
sources: ["App/Sources/**"],
resources: ["App/Resources/**"]
)依存関係
CIで解決済みバージョンを強制する
Swift Package Manager の依存関係を CI にインストールするとき、決定論的なビルドを保証するために--force-resolved-versions フラグを使うことを推奨します:
bash
tuist install --force-resolved-versionsこのフラグは、Package.resolved で固定されている正確なバージョンを使って依存関係が解決されることを保証し、依存関係の解決における非決定性によって引き起こされる問題を排除します。これは、再現可能なビルドが重要な CI において特に重要です。
