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