異なる段階の検証や承認を管理するためのアプリケーションのバージョン管理は、
GeneXus Server を使用したバージョン管理と作業方法のシナリオの 1 つです。
通常、企業は、開発者がコミットした後に、クライアントへのリリース用または本番運用のためのバージョンを検証あるいはテストする段階へと進みます。
このような検証は、単一の段階で行われることがあります (この場合の作業方法は、
アプリケーションリリースごとのバージョン定義で説明しているシナリオと似ています)。多くの場合は、複数の連続した段階で行われ、各段階で開発の特定の側面をテストまたは検証します。
たとえば、あるプロジェクトでは次のような段階が考えられます:
- コードのレビュー
- コードが正確に記述されているか
- コードは命名法、ドキュメンテーション、モジュール化、セキュリティなどの内部標準に準拠しているか
- 統合テスト
- 最終製品の他のモジュールやコンポーネントとの統合後、コンパイル、設定、機能が正常に動作するか
- 機能テスト
- 準本番環境テスト
- 本番運用で使われる環境 (ハードウェア、DBMS、Web サーバー、設定、データなど) を再現した環境で適切に機能するか
各段階を順番に完了させます。前のレベルが承認された場合のみ次のレベルに進むことができます。
たとえば、コードのレビューで特定の変更に問題があった場合、統合テストに進むことはできません。
そのため、このシナリオでは、バージョンを定義することで、検証や承認の複数の段階を管理する必要があります。
最初に、単一の検証段階のシンプルなシナリオを考えてみます。このシンプルなシナリオでは、メインバージョンをベースに、開発者が作業するための並列バージョンを作成する必要があります。テストを実施する担当者は、テストが成功した場合に、メインバージョンに変更を渡します。開発バージョンは、GXserver コンソールまたは GeneXus のチーム開発ダイアログの [ バージョン ] タブを使用して、GXserver のナレッジベースに作成します。
検証段階が 1 つの場合の作業方法
GeneXus Server でのこの方法の実装に備えて、まずは、1 つの開発バージョンと単一の検証段階で作業するシンプルなシナリオを取り上げます (追加の段階については、同様の方法で実行できます)。
開発およびテストの作業は、次のように編成されています:
- 1 つの開発チーム: 各開発者は、開発バージョン (Development Branch) で、GeneXus Server に接続されているローカルのナレッジベースを使用して協同作業します。
- 1 つのテストチーム: 各テスト担当者は、General バージョンに接続されたローカルのナレッジベースで作業し、変更を適用して開発バージョンから変更を適用します。変更が承認された場合は、メインバージョンで GeneXus Server にコミットします。変更が承認されなかった場合は、開発チームに通知する必要があります。
開発者は、
GeneXus Server のナレッジベースと変更をコンソリデートする必要がある場合は、そのつど
GeneXus Server にコミットする必要があります。
同様に、他の開発者が行った変更を取得する必要がある場合は、
GeneXus Server からのナレッジベースの更新を実行してオブジェクトを更新する必要があります。
その結果、General バージョンに検証済みの変更が保持されます。
General バージョンに接続されているナレッジベースを使用することで、
GeneXus Server からナレッジベースを更新したり、アプリケーションの設定プロセスを実行して、対応するプログラムや再編成ファイルをクライアントで利用できるようになります。
前述のとおり、検証段階は 1 つの場合と複数の場合があります。検証段階が複数ある場合、複数のバージョンで並行して作業し、変更が承認されるたびに 1 つのバージョンから他のバージョンへと変更を渡す必要があります。
この場合の作業方法は、
アプリケーションリリースごとのバージョン定義のシナリオと似ています。開発用の並列バージョンを定義するとともに、追加の検証段階にもそれぞれ並列バージョンを定義することができます。
開発バージョン、統合テスト、本番運用など、検証段階が 2 つある場合は、いずれも General バージョンから派生させる形で次のバージョンを定義する必要があります。
コードのレビュー、統合テスト、機能テスト、準本番環境テストなど、複数の段階がある場合は、いずれもメインバージョンや同じ基点から派生させる形で次のバージョンを定義する必要があります:
- 開発: 開発者が作業を行い、GeneXus Server にコミットするバージョンです。
- レビュー: コードのレビュー担当者が作業を行うバージョンです。レビュー担当者は、他のレビュー担当者が承認した変更を更新によって取得します。変更を適用して開発バージョンから変更を適用し、GeneXus Server にコミットして変更を承認します。承認されたなかった場合は変更を元に戻し、エラーが見つかった場合は開発者に通知します。
- 統合: 統合テストを実施する担当者は、このバージョンに接続されているナレッジベースを使用します。更新を実行して他の統合担当者が承認した変更を取得し、変更を適用してレビュー済みバージョンから変更を適用し、GeneXus Server にコミットして変更を承認します。承認されなかった場合は変更を元に戻します。
- 機能: このバージョンは機能テストチームで使用します。他の段階と同様に、変更を適用して前の段階から変更を取得し、GeneXus Server にコミットして変更を承認します。
準本番環境と呼ばれる最後のテスト段階は、メインバージョンに接続されているナレッジベースで行います。本番運用で使用される環境と同じ環境を設定して、ハードウェアやインストールされているソフトウェア、構成、運用データなどもなるべく本番に近い状態にします。テストする変更は、変更を適用して機能バージョンから取得します。この準本番環境テストで変更が承認された場合のみ、メインバージョンで
GeneXus Server へのコミットを実行できます。
最終バージョンをリリース用にセットアップまたはロールアウトするには、メインバージョンに接続されているナレッジベースを使用します。ここからのみ
GeneXus Server からのナレッジベースの更新とビルドを実行できます。
このスキームを使用してバージョン管理を行うと、ここで説明したように、中間の手順が増えた場合でも検証段階を追加していくことができます (異なる色のプロファイルと、中央のプロファイルが増えている点に注目してください)。