注
コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。
X++のリポジトリ (Repos) の分岐構成は、開発チームの嗜好と金融と業務アプリのライフサイクルによって異なります。 実装に既に優先分岐構造があり、この記事で後述する 最小分岐条件を 満たしている場合は、それを使用して新しい開発を管理します。 または、この記事で説明されている他の分岐構造オプションを評価します。
注意事項
X++ 開発サイクルのいくつかの要素は、一般的なアプリケーション開発とは異なります。 以下の項目を意識して、分岐の構成を考えてみてください:
- エンタープライズ リソース プランニング (ERP) システムは、ビジネス クリティカルな環境です。 コード管理インフラストラクチャを設計するときは、運用環境の主要な問題のリスクとディザスター リカバリータイムラインの両方を最小限に抑えるのに役立つ設計要素に優先順位を付けます。
- 標準的なシステムコードは複雑で、相互依存性が高いため、一般的には、コードの更新のたびに、すべての重要なビジネス プロセスについて自動テストと手動テストの両方を行うことを推奨します。 このテストは時間がかかる可能性があるため、検証中にテスト内コードを長時間含めるブランチを用意することを計画してください。
- 開発チームは、製品の特定のモジュールや領域の強化に集中することが多いため、X++ ではマージによるコンフリクトが比較的頻繁に発生します。 したがって、衝突の頻度を減らし、衝突が発生したときに衝突を修正しやすくする分岐戦略を計画します。
最小分岐条件
X++ リポジトリの分岐戦略では、最低限、以下の基準をサポートする必要があります:
- 開発中のテストされていない開発コードまたはコードの分離 – チームメイトがアクティブな開発ブランチを誤って中断しないように開発者を保護します。 チームで 1 つの開発分岐を共有する場合、各開発者はチームメイトのコードを壊すようなコードをコミットしないようにしなければなりません。 この目的のために、バージョン管理機能の追加の構成を使用します。 これ以外の情報では、テストされていないコードを開発中のコードから隔離することが、この保護を提供する理想的な方法です。
- 開発中のコードとテスト対象コードの隔離 – コードの変更はユニット テストや開発者の手動テストでは合格するかもしれませんが、関連するタスクはまだ機能テストの準備が整っていない可能性が考えられます。 X++ の分岐構造では、変更点の集合が機能テストに対応できるようになるタイミングを明確に表記する必要があります。
- 実稼働コードからのテスト内コードの分離 – すべてのバージョン管理の基本的な目的は、コードの変更が完全に検証されるまで、コードが運用環境にリリースされないようにすることです。
- 機能テスト サイクルが比較的長い – 財務と業務アプリのカスタマイズの検証に時間がかかる理由については、本記事の 考慮事項 セクションをご参照ください。
ブランチポリシーのガイダンス
選択した分岐戦略に関係なく、次のブランチ ポリシーのベスト プラクティスを使用します。
- 直接編集されないように、ライブ/運用コード ブランチをロックします。 変更は、他のブランチからのマージによってのみ行います。
- 機能テストを開始する前に、コードを対応するブランチに移動します。 不完全な作業からブランチを保護するのに役立つポリシーを定義します。 Git では、プル リクエストを完了させる前に、最小限のレビュアーの数 を要求することができます。 Team Foundation Version Control (TFVC) には、チェックインがゲート されるようにするための仕組みがあります。
分岐戦略
TFVC での分岐
TFVC を使用するチームに共通する分岐戦略は、トランク ベースのアプローチと開発者の分離、リリースの分離を組み合わせたものです。 この戦略は、アクティブな開発から機能テスト、ライブ運用環境まで、コードが時系列的に進行するにつれて、開発サイクルのフェーズを反映します。 TFVC の分岐戦略の詳細。
開発者は、自分の作業項目が機能テストの準備が整ったと判断すると、その作業に関連するすべての変更を、専用の開発分岐から専用のテスト分岐にマージまたは「昇格」します。 テスト分岐には、機能検証を待っているすべてのコードが含まれています。 作業項目に関連する変更が機能検証に合格すると、生産準備の整ったコードを保持する専用の分岐に昇格します。 実稼働ブランチには、実稼働環境で動作している (または、まもなく実稼働環境に展開される) コードが含まれています。
Git での分岐
Gitは、トランク ベースのアプローチ と GitFlow のアプローチ の両方で非常にうまく機能します。 Git ブランチを使用する場合は、ブランチの有効期間を短くし、頻繁に同期して、マージ競合のリスクを軽減します。 Git の分岐戦略の詳細。
開発者は、新しい作業を開始するときに、変更を保持する新しいブランチを作成します。 開発者はブランチを配信元ブランチと同期し続け、ビルドとテストの検証を通じて変更を検証するプル要求を作成することがよくあります。 開発完了時に、スクワッシュとマージの操作 で簡単に変更点をマージ バックすることができます