プロジェクトルートディレクトリの移行

projects_root ディレクトリのコピーを作成し、コピーを移行することをお勧めします。すると、指摘ステータスの変更など、変更はしないように指示されますが、ユーザーは Validate を引き続き使用できます。

移行にかかる時間を削減するために、手順に示したように、移行前に不要なプロジェクトおよび失敗したビルドを削除することを強くお勧めします。

ソフトウェアの新規メジャーリリースに移行する場合、メジャーリリースに新しい Validate ライセンスが必要な場合など、適格なライセンスのあることを確認してください。詳細については、ライセンスを参照してください。

デフォルトのサーバー設定を使用しない場合は、アップグレードを開始する前にカスタム設定を指定する必要があります。指定しない場合は、インストール中にこれらの設定がデフォルト設定に戻ります。忘れてしまった場合は、アップグレードの完了後にいつでも、環境ごとに設定にアクセスして変更できます。

Tomcat サーバー構成: Validate の Tomcat サーバー構成 (<projects_root>/tomcat/conf/server.template) は、移行中にバックアップされ、置き換えられます。バックアップファイルには、server.template.bak　または　server.template.bak_X (X　は数字) という名前が付けられます。お使いの server.template が Validate のデフォルトから変更された場合は、バックアップからそれらの変更内容をコピーできるので、maxPostSize が -1 に設定されていることを確認し、Validate サーバーを再起動してください。

サポートされるアップグレード パス

下の表で最新のバージョンおよび適切なアップグレード パスを確認してください。以下の表にリストされていない製品の以前のバージョンをアップグレードする必要がある場合は、インポートメソッドを実行します。詳細については、既存のプロジェクトを新しい projects_root にインポートするを参照してください。

Perforce はここでも役に立ちます。以前のリリースからの移行が必要な場合には、Static Code Analysis プロフェッショナルサービスまでお問い合わせいただき、サービスエンゲージメントを介して相談してください。

リリース間の相互運用

Validate の最新の改善点を活用するには、Server、Build、および Desktop Analysis プラグインを常に最新バージョンの製品にアップグレードすることを推奨します。Validate サーバーツールとビルドツールは、各メジャーリリース内でデスクトップ解析プラグインとの互換性があります。

また Validate には、以前のメジャーバージョンの Validate から現在のバージョンの Validate にビルドをロードする機能もあります。たとえば、これはデータのインポートまたは移行を行わずに、Validate 2022 の任意のバージョンから Klocwork 2024.4 に Validate ビルドをロードできるということです。

2 つのバージョンの Validate サーバーの実行

たとえば、既存のサーバーへのアクセスを継続しながら Validate 2024.4 サーバーをテストするなど、2 セットの Validate サーバーを実行する場合は、別々の projects_root ディレクトリでそれらを実行する (そして、ポートを適切に設定する) 必要があります。

アップグレードの準備をするには:

1. 移行する projects_root については、次のコマンドを実行します。

   validate service --projects-root <projects_root> check 
   

2. 実行中のサーバーおよび使用中のポートについて書き留めます。新しいバージョンの Validate に移行した後、サーバーはこれらのポートで実行されるようになります。
3. サーバーを停止します。
4. 復元ポイントを作成するために、移行する projects_root ディレクトリの完全なバックアップを作成します。Validate のアップグレード後は、アップグレードを元に戻せません。
5. 構成ファイル (kwmysql.ini または kwfilter.conf など) をカスタマイズした場合は、<server_install>/config ディレクトリのバックアップを作成します。
6. サーバーを起動します。
   データの移行に要する時間を削減するために、次のことを強くお勧めします。

   • 移行しない以前のバージョンから、プロジェクトを削除します。
   • 以前のバージョンから、失敗したプロジェクトビルドを削除します。フィールド説明するようにプロジェクトを移行した後、以前のリリースで失敗したビルドを再開することはできません。ただし、テーブルからビルドをロードすることはできます。
7. サーバーを停止します。
8. (オプション) 2 番目の復元ポイントを作成するために、移行のために準備した projects_root ディレクトリのバックアップを作成します。
9. 既存の Validate ライセンスを安全な場所に保存します。
10. 混乱を回避するために、古い Validate のログを <projects_root>/logs から削除します。

Validate 2024.4 サーバーパッケージをインストールします。手順については、Validate のインストールを参照してください。

リモートライセンスサーバーを使用している場合は、移行する前に、それを Reprise に変換してください。

カスタマーサポートから新しいライセンスファイルを受け取った場合、新しい <projects_root>/licenses フォルダーにそれをコピーします。

<path to old installation>/kwservice --projects-root <old_projects_root> stop
<path to installation>/kwservice --projects-root <old_projects_root> set-service-property license host <reprise server host>
<path to installation>/kwservice --projects-root <old_projects_root> set-service-property license port <reprise server port>

projects_root を移行するには、<Validate_2024.4_Server_install>/bin から次のコマンドを実行します。

validate service --projects-root <old_projects_root> start --migrate

projects_root が正常に移行された場合、移行された projects_root から取得したポート番号で、Validate サーバーが起動します。

Notes

• これまでのリリースでカスタム分類基準をインポートしていた場合は、新しい分類基準ファイルを再インポートして変更を反映させる必要があります。
• Validate サーバーを Windows サービスとして実行している場合、--migrate オプションでサーバーを起動した後に、validate service --projects-root <migrated_projects_root> stop でサーバーを停止します。その後、Windows Services 管理を使用してValidate 2024.4 サービスを起動します。
• Unix で SSH を使用して、または Windows で Windows Services 管理を使用して、Validate サーバーをリモートで管理できます。それ以外の場合は、start、restart、および stop コマンドをローカルに発行する必要があります。
• 上記のコマンドは、projects_root のすべての外部構成ファイルを UTF-8 に変換します。すべての外部構成ファイルは、日本語などのマルチバイト文字が含まれている場合は、UTF-8 エンコードされている必要があります。

特定プロジェクトの移行を優先する

通常の移行を実行するとき、または失敗後に移行を再開するときに、優先順位リストを含めることができます。

優先リストを使用して移行を実行する:

1. プロジェクト名のリストが改行で区切られて書かれたテキストファイル (priority.txt など) を用意します。移行はファイルで指定されたプロジェクトの順番に実行され、リストにない残りのプロジェクトはその後アルファベット順で移行されます。例:

   Project_c
   Project_a
   Project_b

2. --priority-projects-file フラグと、優先するファイルのパスを指定して、移行コマンドを実行します。

   priority-projects-file がない場合、プロジェクトはプロジェクト ID の順番で移行されます。プロジェクト ID は元のプロジェクト名に基づいており、変更できません。

   kwservice start -r <project_root_dir> --migrate --priority-projects-file C:/Users/priority.txt

   または

   validate service start -r <project_root_dir> --migrate --priority-projects-file C:/Users/priority.txt

• <old_Validate_install>/config/kwmysql.ini にある MariaDB 構成ファイルを変更した場合、新しいインストールで kwmysql.ini に同じ変更を加えます。
  重要: カスタマイズした構成ファイルを新しい Validate インストールにコピーしないでください。代わりに、新しくインストールした構成ファイルに同様のカスタマイズを行います。

• <old_Validate_install>/config/kwfilter.conf にあるコンパイラマッピングファイルを変更した場合

  新しいインストールの kwfilter.conf も同様に変更します。

  重要: カスタマイズした構成ファイルを新しい Validate インストールにコピーしないでください。代わりに、新しくインストールした構成ファイルに同様のカスタマイズを行います。

• カスタムメトリクスレポートを Validate に追加した場合、カスタムメトリクスレポート構成ファイル (metrics.xml) を編集する必要があります。metrics.xml ファイルは、次の場所にあります。<projects_root>/config
• <old_Validate_install>/config/java_wrappers_memory.conf にあるメモリ割り当てファイルを変更した場合は、それらの変更が引き続き必要であることを確認し、新しいインストールで java_wrappers_memory.conf に同じ変更を加えます。

Notes

• metrics.xml ファイルは、Validate インストール全体ではなく、projects_root ディレクトリに適用されます。このため、複数の projects_root ディレクトリがある場合、カスタマイズした metrics.xml ファイルを各 projects_root にコピーする必要があります。
• metrics.xml ファイルのカスタマイズ後に Validate サーバーを再起動する必要があります。

プロジェクトおよびビルドが Validate に表示されることを確認します。

新しいライセンスファイルをインストールした場合、ライセンス数が正しいことのチェックにより、ライセンスファイルが正しくインストールされたことを確認します。

別の projects_root を移行するには、この章で説明した (Validate のインストールを除く) ステップを再度実行します。

2 番目以降の projects_root ディレクトリのためのアップグレードのステップのサマリーは、次のとおりです。

1. アップグレードの準備をします。
2. 次を実行します。

   validate service --projects-root <projects_root> start --migrate
   

3. カスタマイズしたコンパイラ設定ファイルがあれば、それを再作成します。
4. カスタム　メトリクス　レポートを Validateに追加した場合、カスタム　メトリクス　レポート構成ファイル (metrics.xml) を編集します。
5. アップグレードをテストします。

通常、新しいリリースの Validate には、現在のイベントに対応して顧客の要求に応えるようにチェッカー設定が変更されています。これらの変更は、以前のリリースからのチェッカー設定と新しいリリースの設定が異なっていることを意味している可能性があります。

古い設定に対応する正しいチェッカーが有効になっていることを確認してください。 設定が完了したら、build specification (ビルドスペック) を再生成して最新の変更をキャプチャし、修正されていないソースコードで統合ビルド解析を実行します。

既に最初の Validate 2024.4 解析を実行しており、指摘またはステータス変更の一部が欠落している場合は、そのビルドを削除し、チェッカーを再設定して新しい解析を実行します。

最後のプレアップグレード統合ビルド解析と最初の Validate 2024.4 解析を同じソースコードで実行してから、2 つのビルドを比較することをお勧めします。こうすると、解析エンジンの変化を正しく評価できます。