Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure DevOps で Team Foundation バージョン管理 (TFVC) を使用した DevOps を採用する予定ですか? 次のような疑問を抱くことでしょう。
- 適切な分岐戦略をどのように判断するか?
- DevOps に効果的な戦略があるのか?
- 単一または複数のバージョンのアプリケーションをどのようにサポートするか?
TFVC は、コードを維持し、チームをより効果的にするための一元的なバージョン コントロール システムです。 コラボレーションと一貫性のあるコード共有、発行、レビュー機能を備えています。
シンプルな状態を保つ!
効果的な分岐戦略を採用することで、以下が可能になります。
- "DevOpsｄ カルチャ" を育てる
- コラボレーション フローを促進し、生産性を向上させる
- チームがコードの開発に費やす時間を増やし、管理にかかる時間を短縮できるようにする
DevOps を採用する際は、ブランチ戦略をシンプルに保ち、高品質を目指すことが重要です。 以下に推奨事項をいくつか示します。
- シンプルな戦略から始め、必要に応じて発展させる
- ブランチに一貫性のある命名規則を使用する
- 個人が実行する作業に対しては features/ユーザー名/説明 (例: features/sandra/sdk-java)
- エンジニアリング バグに固有の作業に対しては bugfix/ユーザー名/バグ ID (例: bugfix/takashi/707)
- 計画したリリースに対しては releases/バージョン (例: releases/V1.00)
- 多くの場合、逆方向の統合 (RI) を使用して メイン ブランチにマージする
- 一貫したコード レビュー (ガベージ イン、ガベージ アウト) を実施する
- 以下を使用して、CI/CD パイプラインを実装します。
- ゲート チェックイン
- 自動テスト
シンプルな分岐戦略から始める
"出荷可能な" リリース ユニットを識別するソース管理構造を作成します。 "リリース可能なユニット" の概念は、この戦略の基本的な部分であり、Steve St Jean は次のように説明します。
- バージョン管理と出荷の物理単位。
- 分岐モデルとリリース モデルをサポートするプライマリ ユニット。
- スイート レベル、アプリケーション レベル、または コンポーネント レベルを指定可能。
- スイートの場合、すべてのアプリケーションで一緒にバージョンとパッチを適用する必要がある。 たとえば、Microsoft Word と Excel は Microsoft Office Suite の一部です。 Visio は、Microsoft Office Suite のその他の部分とは無関係にリリースまたはパッチを適用する場合があるため、これには含まれません。
- TFVC では、チーム プロジェクト ノードの下のルート ノードとなる。
- Git のリポジトリと同等に扱うことが可能
通常は、1 つの運用バージョンのみをサポートすることから始め、不具合の修正や新機能の開発を並行して行うことになります。 一般的な例としては、Web サイト、企業の基幹業務アプリケーション、中間ツールなどがあります。
シンプルなメインのみの分岐戦略から始めます。
ビルドを自動化して、メイン ブランチへのすべてのチェックインでトリガーし、自動テストを実行し、成功した場合は、開発 (dev) 環境にリリースをデプロイします。
| [Branch]\(ブランチ) | Build | 環境 | Notes |
|---|---|---|---|
| メイン | CI_Bld | Dev | メインへのすべてのチェックインでトリガーされます |
リリース サイクルを完了したら、リリース ブランチを作成します。 リリース ブランチを使用してリリースを安定させ、メインで次のバージョンの開発を続行します。 検証済みのバグ修正を逆向きに統合 (RI) し、メイン ブランチと頻繁にマージして、技術的負債全体を最小限に抑えます。
ビルドとリリースを自動化して、以下を実行します。
- リリース ブランチへのすべてのチェックインを使用してトリガーする
- 自動テストを実行する
- 開発環境やその他の環境にデプロイする
| [Branch]\(ブランチ) | Build | Pipelines | Notes |
|---|---|---|---|
| メイン | CI_Bld | Dev | メインへのすべてのチェックインでトリガーされます |
| V1.00 | RC_Bld | Dev -> QA -> UAT -> Staging -> Prod | リリースへのすべてのチェックインでトリガーされます |
バージョン 2 がリリース候補になると、V2.00 ブランチを指す既存の RC ビルド パイプラインを更新できます。 V1.00 が現在のバージョンのときと同じようにビルドおよびリリースされるようになりました。
| [Branch]\(ブランチ) | Build | Pipelines | Notes |
|---|---|---|---|
| メイン | CI_Bld | Dev | メインへのすべてのチェックインでトリガーされます |
| V2.00 | RC_Bld | Dev -> QA -> UAT -> Staging -> Prod | リリースへのすべてのチェックインでトリガーされます |
| V1.00 | Hotfix_Bld | Hotfix -> Staging -> Prod | 修正プログラムへのすべてのチェックインでトリガーされます |
必要に応じて分岐戦略を拡張する
Word などの商用ソリューションなど、複数の運用バージョンをサポートする必要が生じた場合は、分岐戦略を拡張できます。
サポートする必要がある完了したリリース サイクルごとに、機能分離を使用して、新しいリリース ブランチを作成し、メインにある次のバージョン開発を続行します。 逆方向の統合 (RI) により v1.0 と v2.0 からメインにマージされることにご注意ください。 これらは、運用環境にリリースされるバグの修正プログラムを表しています。
シンプルな分岐戦略を使用し、一貫した名前付け規則を採用することで、次のことがサポートされます。
- 1 つ以上のリリースがサポートされているアプリケーション
- 新機能の継続的な開発
- ユーザーへの価値の継続的デリバリー
チェックリストとフィールドからのレッスン
チェック リスト
- シンプルな状態を保ち、必要に応じて分岐の複雑さを拡張する
- コードを出荷可能な単位に整理する
- ブランチに一貫した名前付け戦略を使用する
- すべてのチェックインを使用してビルドする
- ゲート チェックインと自動テストを使用して CI/CD パイプラインを作成する
フィールドからのレッスン - 避けるべきこと
- ブランチが多くなりすぎないようにする!
- 変更をマージすると、複雑さが増し、コストがかかる
- 環境ごとの個別のブランチは不要
- チェリーピックを使用してコードを運用環境に移行しないようにする
- 人を解決したり、ツールで問題を処理したりしない