機能分離戦略を調べる

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Azure DevOps で Team Foundation バージョン管理 (TFVC) 機能分離戦略を実装する予定ですか? 次のような疑問を抱くことでしょう。

• 大規模な開発チームでは実用的ですか?
• アジャイル プロセスに適合していますか?
• 分離された機能ブランチの適切な有効期間はどのくらいですか?

この記事は、これらの疑問にお答えし、TFVC での機能分離に関する明確な視点を提供することを目的としています。 TFVC ブランチ戦略全体のガイダンスについては、TFVC でのブランチ戦略に関する記事を参照してください。

注意

この記事では TFVC について説明します。 Git については、「Git ブランチ戦略を採用する」を参照してください。

機能分離とは

機能分離戦略を使用すると、機能に対して作業したり、"機能" ブランチ ("トピック ブランチ" とも呼ばれます) のバグを親ブランチに基づいて修正したりできます。 この戦略は、次を実行するための変更を、チームの他の部分から分離します。

• 機能を試す。
• 変更を簡単にロールバックする。
• 変更を親ブランチにマージする。

注意

この "機能" の使用は、機能作業項目の種類とは無関係です。 この戦略は、エピック、機能、プロダクト バックログ項目、ユーザー ストーリー、その他プロセスで定義したいずれの作業項目の種類でも使用できます。

機能またはバグごとに 1 つの機能ブランチを作成するのが一般的ですが、この戦略では、リスクの低いいくつかの機能を分離するために、雑多な機能ブランチを作成する可能性があります。

リポジトリ スコープである Git ブランチとは異なり、TFVC ブランチはパス スコープであるため、それほど軽量ではありません。 これを回避するには、TFVC 機能ブランチの数と有効期間を制限します。 明示的、暗黙的、クローク、および非再帰的なフォルダー マッピングを使用してワークスペースを最適化して、パフォーマンスを向上させ、マシン上の必要なディスク領域を減らします。

ヒント

ワークスペースには、必要なファイルのみが含まれるようにする必要があります。 複数の機能ブランチ間で分離および切り替えを行うために、複数のワークスペースを作成することを検討してください。 混乱を避けるには、ワークスペースと機能ブランチの両方に一貫した名前付け規則を使用してください。

名前付け規則が重要

機能ブランチには、一貫した名前付け規則を使用してください。 ブランチは自己記述的で、ユーザーが簡単に識別できる必要があります。 次に推奨事項をいくつか示します。

• 個人が実行する作業の機能/ユーザー名/説明。 例: "features/pat/sdk-java"。
• 特定の作業項目に関連付けられている機能作業の機能/作業項目。 例: "features/115673"。
• 特定のスプリント内の個人によって行われる作業のスプリント/ユーザー名/説明。 例: "S53/pat/dictionary-refactor"。
• あるエンジニアリング バグに特化して行われる作業のバグ修正/ユーザー名/バグ ID。 例: "bugfix/pat/707"。

機能ブランチの作成

通常、スプリントまたはイテレーションのコンテキスト内で機能を操作する必要があるときに、機能ブランチを作成します。

親ブランチを保護し、マージの競合を最小限に抑えるには、親ブランチから機能ブランチに定期的に変更内容を順方向に統合 (FI) します。 FI を使用すると、親ブランチではなく、機能ブランチでマージの競合を解決できるようになります。

この戦略で、機能が親ブランチと非同期になるのを防ぐこともできます。 変更内容を親ブランチに逆方向に統合 (RI) する前に、必ず FI を行ってください。

ヒント

機能ブランチの有効期間は短くしてください。

メインや他の中央ブランチとは異なり、機能ブランチの有効期間は限られています。 これらのスコープは、通常、スプリントまたはイテレーション内で開発される機能、バグ、修正プログラムです。 機能がチームの完成の定義 (DoD) を満たし、変更内容が親ブランチにマージされたら、機能ブランチを削除することを検討してください。

機能ブランチの数が増えるにつれて、ストレージ要件とブランチ階層の視覚化ノイズが増大します。 機能ブランチが 5 つだけでも、図は既にノイズが多く、監視品質が急速に失われます。 チームが何百もの機能ブランチを作成した場合の影響を想像できますか?

同様に、Visual Studio の [ソース管理エクスプローラー] ビューは、ブランチの数が増えるにつれてノイズが多くなり、実用的ではなくなります。 一貫した名前付け規則がない限り、数百の機能ブランチ内で特定の機能ブランチを見つけることは困難です。

ヒント

完了したら、機能ブランチを削除してください。

機能ブランチを削除した場合の影響

機能ブランチを削除すると、ノイズを最小限に抑え、アクティブな機能開発に集中できます。

これは論理的な削除であり、履歴は失われません。 削除されたブランチは非表示にできます。

1. [ツール]>[オプション]>[Visual Studio Team Foundation Server] の順に選択します。
2. [ソース管理エクスプローラーで削除された項目を表示する] を選択します。

または、[ソース管理エクスプローラー] のメニュー バーの [削除済み項目の表示/非表示] アイコンを切り替えます。

必要に応じて、削除されたブランチと関連項目を復元することもできます。

チーム内の誰も destroy コマンドを使用してブランチを破棄していない場合は、履歴の再生に依存する監査および移行ツールに必要な全履歴が得られます。

注意

destroy コマンドは慎重に使用してください。 これは完全な削除です。

ブランチの有効期間を短くし、一貫した名前付け規則を採用すると、小規模および大規模なチームに対して機能分離戦略の効果を維持できます。

これで、機能分離を使用するようになったので、継続的インテグレーション、フィーチャー トグル、およびその他の補完的な戦略を探求してください。

関連リソース

• TFVC でのブランチ戦略
• 継続的インテグレーション
• フィーチャー トグル
• Team Foundation バージョン管理 (TFVC)
• DevOps Rangers ガイダンス (英語)