ワークフローの選択

はじめに

Lingo.dev CI/CDは柔軟性を持って設計されており、既存のあらゆるワークフローと統合できます。ただし、出発点として、このページでは検討すべき推奨ワークフローをいくつか紹介します。

注意：「最適な」ワークフローというものは存在しません。各ワークフローには異なるトレードオフがあり、ユーザーの好み、チーム規模、確立された作業方法に基づいて、異なるユーザーにアピールします。

推奨ワークフロー

オプション1：メインブランチへのコミット

コンテンツ変更がメインブランチにマージされると、翻訳が自動的に生成され、メインブランチに直接コミットされます。

最適な対象

開発者の関与を最小限に抑え、目に見えない、摩擦のない翻訳更新を求めるチーム。

利点

• 完全自動化 - 人間の介入不要
• 翻訳がメインブランチで即座に利用可能
• 最もシンプルなセットアップとメンテナンス
• 追加のブランチやプルリクエストの管理が不要

トレードオフ

• 翻訳のレビュープロセスがない
• 翻訳コミットが追加のCI実行をトリガーする可能性
• 何が翻訳されたかの可視性なしに変更がメインに直接表示される
• 翻訳がデプロイされるタイミングの制御が少ない

オプション2：メインブランチからのプルリクエスト

コンテンツがメインにマージされた後、翻訳が生成され、メインブランチから新しいプルリクエストとして提出されます。

最適な対象

プロセスをメインブランチに集中させながら、翻訳の可視性とレビュー機能を求めるチーム。

利点

• 翻訳変更がマージ前に可視化され、レビュー可能
• 翻訳されたコンテンツの明確な監査証跡
• 翻訳を受け入れる前に手動調整を行う機能
• 明示的な翻訳コミットでメインブランチの履歴をクリーンに維持

トレードオフ

• 手動でのプルリクエスト承認が必要（自動マージが設定されていない場合）
• コンテンツ変更と翻訳の利用可能性の間にわずかな遅延
• ワークフローで管理する追加のプルリクエスト

オプション3: フィーチャーブランチへのコミット

フィーチャーブランチでコンテンツの変更が行われると、翻訳が自動的に生成され、同じブランチに直接コミットされます。

最適な対象

長期的なフィーチャーブランチで作業し、翻訳を機能開発プロセスの一部にしたいチーム。

利点

• 機能が完成したときに翻訳も準備完了
• 機能レビュー中に別途翻訳作業が不要
• 完全な機能にはコンテンツと翻訳の両方が含まれる
• フィーチャーフラグデプロイメントとの相性が良い

トレードオフ

• 翻訳コミットがフィーチャーブランチの履歴に表示される
• 複数の開発者が同じブランチで作業する場合、マージコンフリクトの可能性
• 翻訳がコンテンツの準備状況ではなく機能の完成に紐付けられる
• リリースされない実験的な機能の翻訳が生成される可能性

オプション4: フィーチャーブランチからのプルリクエスト

フィーチャーブランチでコンテンツの変更が発生すると、翻訳が生成され、それらのブランチから個別のプルリクエストとして提出されます。

最適な対象

フィーチャーブランチワークフローを維持しながら、翻訳に対する最大限の制御と可視性を望むチーム。

利点

• 機能レベルでの翻訳変更の完全な可視性
• 機能完成前に翻訳をレビューおよび調整する機能
• 機能開発と翻訳統合の明確な分離
• 翻訳更新を受け入れるタイミングの柔軟性

トレードオフ

• 管理が最も複雑なワークフロー
• 機能ごとに複数のプルリクエスト（機能+翻訳）
• 機能が変更された場合、翻訳プルリクエストが古くなる可能性
• 機能と翻訳のプルリクエスト間の調整が必要