最近のアクセス:
異なる段階の検証や承認を管理するためのアプリケーションのバージョン管理
異なる段階の検証や承認を管理するためのアプリケーションのバージョン管理は、GeneXus Server を使用したバージョン管理と作業方法のシナリオの 1 つです。
通常、企業は、開発者がコミットした後に、クライアントへのリリース用または本番運用のためのバージョンを検証あるいはテストする段階へと進みます。
このような検証は単一の段階 (この場合は、アプリケーションリリースごとのバージョンの定義で説明しているシナリオに似ています) で行われるか、多くの場合は、複数の連続した段階 (各段階で開発の特定の側面をテストまたは検証する) で行われます。
たとえば、あるプロジェクトでは次のような段階が考えられます。
  • コードのレビュー
    • コードが正確に記述されているか
    • コードは命名法、ドキュメンテーション、モジュール化、セキュリティなどの内部標準に準拠しているか
  • 統合テスト
    • 最終製品の他のモジュールやコンポーネントとの統合後、コンパイル、設定、機能が正常に動作するか
  • 機能テスト
    • システムは定義された機能を正確に実行しているか
  • 準本番テスト
    • 本番運用で使われる環境 (ハードウェア、DBMS、Web サーバー、設定、データなど) を再現した環境で適切に機能するか
各段階を順番に完了させます。前のレベルが承認された場合のみ次のレベルに進むことができます。
たとえば、コードのレビューで特定の変更に問題があった場合、統合テストに進むことはできません。
そのため、このシナリオでは、バージョンを定義することで、検証や承認の複数の段階を管理する必要があります。

バージョン管理

最初に、単一の検証段階の簡単なシナリオを考えてみます。このシンプルなシナリオでは、メインバージョンをベースに、開発者が作業するための並列バージョンを作成します。テストを実施する担当者は、テストが成功した場合に、メインバージョンに変更を渡します。この開発バージョンは、GXserver コンソールを使用して、または GeneXus の [ チーム開発 ] ダイアログの [ バージョン ] タブから、GXserver のナレッジベースに作成されます。
イメージ:34527.png

検証段階が 1 つの場合の作業方法
GeneXus Server でこの方法を実装する場合は、同様の方法で追加の段階を実行できるため、最初に 1 つの開発バージョンと単一の検証段階で作業するシンプルなシナリオについて考えてみます。
開発およびテストの作業は、次のように編成されています。
  • 1 つの開発チーム: 各開発者は、開発バージョン (Development Branch) の、GeneXus Server に接続されているローカルのナレッジベースで協同作業します。
  • 1 つのテストチーム: 各テスト担当者は、General バージョンに追加されたローカルのナレッジベースで作業し、変更を適用して開発バージョンから変更を適用します。変更が承認された場合は、メインバージョンで GeneXus Server にコミットします。変更が承認されなかった場合は、開発チームに通知する必要があります。
開発者は、GeneXus Server のナレッジベースと変更をコンソリデートする必要がある場合は、そのつど GeneXus Server にコミットする必要があります。
同様に、他の開発者が行った変更を取得する必要がある場合は、GeneXus Server からナレッジベースを更新して、オブジェクトを更新する必要があります。
その結果、General バージョンでは検証された変更が維持されます。
General バージョンに接続されているナレッジベースを使用して GeneXus Server からナレッジベースを更新することにより、アプリケーションの設定プロセスを実行して、対応するプログラムや再編成ファイルをクライアントで利用できるようになります。
イメージ:34545.png

検証段階が 2 つの場合の作業方法

前述のとおり、検証段階は 1 つの場合と複数の場合があります。検証段階が複数ある場合、複数のバージョンで並行して作業し、変更が承認されるたびに 1 つのバージョンから他のバージョンへと変更を渡す必要があります。
この場合の作業方法は、アプリケーションリリースごとのバージョン定義と似ています。開発用の並列バージョンを定義する他に、追加の検証段階にもそれぞれ並列バージョンを定義します。
開発バージョン、統合テスト、本番運用など、検証段階が 2 つある場合は、General バージョンから派生する次のバージョンを定義する必要があります。
イメージ:34548.png
  • Development Branch: 開発者が作業を行い、GeneXus Server にコミットするバージョンです。
  • Integrated Test: 統合テストを実施する担当者は、このバージョンに接続されているナレッジベースを使用します。統合担当者は、他の統合担当者が承認した変更を、更新によって取得します。「変更を適用」によって開発バージョンから変更を適用し、GeneXus Server にコミットして変更を承認します。承認されなかった場合は変更を元に戻します。
  • General: 最終バージョンをリリース用にセットアップまたはロールアウトするには、メインバージョンに接続されているナレッジベースを使用します。ここから GeneXus Server からのナレッジベースの更新とビルドを実行します。
イメージ:34550.png

検証段階が 3 つ以上の場合

コードのレビュー、統合テスト、機能テスト、準本番運用テストなど、複数の段階がある場合は、メインバージョンや同じ基点から派生する次のバージョンを定義する必要があります。
  • 開発: 開発者が作業を行い、GeneXus Server にコミットするバージョンです。
  • レビュー: コードのレビュー担当者が作業を行うバージョンです。レビュー担当者は、他のレビュー担当者が承認した変更を更新によって取得します。「変更を適用」によって開発バージョンから変更を適用し、GeneXus Server にコミットして変更を承認します。承認されたなかった場合は変更を元に戻し、エラーが検出されたことを開発者に知らせます。
  • 統合: 統合テストを実施する担当者は、このバージョンに接続されているナレッジベースを使用します。担当者は、他の統合担当者が承認した変更を更新によって取得します。「変更の適用」によってレビューバージョンの変更を適用し、GeneXus Server にコミットして変更を承認します。承認されなかった場合は変更を元に戻します。
  • 機能: このバージョンは機能テストチームで使用します。他の段階と同様に、変更を適用して前の段階から変更を取得し、GeneXus Server にコミットして変更を承認します。
準本番運用と呼ばれる最後のテスト段階は、メインバージョンに接続されているナレッジベースで行います。本番運用で使用される環境と同じ環境を設定して、ハードウェアやインストールされているソフトウェア、設定、運用データなどもなるべく本番に近い状態にします。テストする変更は、機能バージョンから変更を適用して取得します。この準本番運用テストで変更が承認された場合のみ、メインバージョンで GeneXus Server へのコミットを実行できます。
最終バージョンをリリース用にセットアップまたはロールアウトするには、メインバージョンに接続されているナレッジベースを使用します。ここからのみ GeneXus Server からのナレッジベースの更新とビルドを実行できます。
このスキームを使用してバージョン管理を行うと、ここで説明したように、中間の手順が増えた場合でも検証段階を追加していくことができます (色分けされた人物の間に、人が増えている点に注目してください)。






サブページ
Created: 14/09/18 03:14 by Admin Last update: 19/03/27 01:29 by Admin
カテゴリ
Powered by GXwiki 3.0