次の方法で共有

分岐の概要

  • [アーティクル]

X++のリポジトリ (Repos) の分岐構成は、開発チームの嗜好と金融と業務アプリのライフサイクルによって異なります。 導入においてすでに優先的な分岐構造があり、それがこの記事の後半で説明する 最低限の分岐基準 を満たすのであれば、それを使って新規開発を管理することができます。 また、本記事で解説している他の分岐構造のオプションを評価することも可能です。

注意事項

X++ の開発サイクルには、一般的なアプリケーション開発とは異なる要素がいくつかあることが分かります。 以下の項目を意識して、分岐の構成を考えてみてください:

  • エンタープライズ リソース プランニング (ERP) システムは、ビジネス クリティカルな環境です。 コード管理のインフラを設計する際には、生産上の重大な問題のリスクとディザスター リカバリのタイムラインの両方の最小化に役立つ設計要素を優先させる必要があります。
  • 標準的なシステムコードは複雑で、相互依存性が高いため、一般的には、コードの更新のたびに、すべての重要なビジネス プロセスについて自動テストと手動テストの両方を行うことを推奨します。 このテストは長時間におよぶ場合があるため、検証中のコードを長期間格納する分岐を計画する必要があります。
  • 開発チームは、製品の特定のモジュールや領域の強化に集中することが多いため、X++ ではマージによるコンフリクトが比較的頻繁に発生します。 したがって、コリジョンの頻度を減らし、コリジョンが発生したときに修正しやすくなるような分岐戦略を計画する必要があります。

最小分岐条件

X++ リポジトリの分岐戦略では、最低限、以下の基準をサポートする必要があります:

  • テストされていない開発コードや開発中のコードの隔離 – 開発者は、チームメイトが誤ってアクティブな開発ブランチを壊してしまうことがないようにコードを保護する必要があります。 チームで 1 つの開発分岐を共有する場合、各開発者はチームメイトのコードを壊すようなコードをコミットしないようにしなければなりません。 この目的のために、バージョン管理機能の追加構成を行う必要があります。 これ以外の情報では、テストされていないコードを開発中のコードから隔離することが、この保護を提供する理想的な方法です。
  • 開発中のコードとテスト対象コードの隔離 – コードの変更はユニット テストや開発者の手動テストでは合格するかもしれませんが、関連するタスクはまだ機能テストの準備が整っていない可能性が考えられます。 X++ の分岐構造では、変更点の集合が機能テストに対応できるようになるタイミングを明確に表記する必要があります。
  • テスト中のコードと本番コードの分離 – すべてのバージョン管理の基本的な目的は、コードの変更が完全に検証されるまで、本番環境へのコードのリリース防止を支援することです。
  • 機能テストサイクルが比較的長い –財務と業務アプリのカスタマイズの検証に時間がかかる理由については、本記事の 検討が必要な事項 セクションをご参照ください。

分岐ポリシーのガイダンス

選択する分岐戦略にかかわらず、以下の分岐ポリシーのベストプラクティスを推奨します:

  • ライブ/本番環境のコード分岐は、直接編集できないようにロックする必要があります。 変更は、他の分岐からのマージによってのみ行われるべきです。
  • 機能テストが始まる前に、開発者は自分のコードを対応する分岐に移動させる必要があります。 不完全な作業から分岐を保護するために、ポリシーを定義することをお勧めします。 Git では、プル リクエストを完了させる前に、最小限のレビュアーの数 を要求することができます。 Team Foundation Version Control (TFVC) には、チェックインがゲート されるようにするための仕組みがあります。

分岐戦略

TFVC での分岐

TFVC を使用するチームに共通する分岐戦略は、トランク ベースのアプローチと開発者の分離、リリースの分離を組み合わせたものです。 この戦略は、コードがアクティブな開発から機能テスト、本番環境へと時系列的に進行するように、開発サイクルの段階を反映させる試みです。 TFVC の分岐戦略の詳細。

開発者は、自分の作業項目が機能テストの準備が整ったと判断すると、その作業に関連するすべての変更を、専用の開発分岐から専用のテスト分岐にマージまたは「昇格」します。 テスト分岐には、機能検証を待っているすべてのコードが含まれています。 作業項目に関連する変更が機能検証に合格すると、生産準備の整ったコードを保持する専用の分岐に昇格します。 実稼働ブランチには、実稼働環境で動作している (または、まもなく実稼働環境に展開される) コードが含まれています。

Git での分岐

Gitは、トランク ベースのアプローチ と GitFlow のアプローチ の両方で非常にうまく機能します。 Git ブランチを使用する場合、マージの競合のリスクを減らすために、分岐を短命に保ち、頻繁に同期することを強くお勧めします。 Git の分岐戦略の詳細。

開発者が新しい作業を始めると、その変更を保持するために新しい分岐を作成することができます。 開発者は、オリジンの分岐と同期させることを心がけ、プル リクエストを頻繁に作成し、ビルドとテストの検証を通じて変更点を確認する必要があります。 開発完了時に、スクワッシュとマージの操作 で簡単に変更点をマージ バックすることができます