ワークフローの選択

はじめに

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

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

推奨ワークフロー

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

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

最適な対象

開発者の関与を最小限に抑え、目に見えないゼロフリクションの翻訳アップデートを望むチーム。

利点

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

トレードオフ

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

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

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

最適な対象

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

利点

• 翻訳の変更はマージ前に可視化およびレビュー可能
• どのコンテンツが翻訳されたかの明確な監査証跡
• 翻訳を受け入れる前に手動調整する能力
• 明示的な翻訳コミットによるメインブランチの履歴の整理

トレードオフ

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

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

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

最適な対象

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

利点

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

トレードオフ

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

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

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

最適な対象

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

利点

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

トレードオフ

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