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

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

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

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

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

最初の Klocwork 2023.4 解析実行で前回のリリースからの指摘、ステータス変更、またはコメントの喪失を回避するために、最初の Klocwork 統合ビルド解析の前にを必ずお読みください。

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

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

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

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

リリース間の相互運用

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

また Klocwork には、以前のメジャーバージョンの Klocwork から現在のバージョンの Klocwork にビルドをロードする機能もあります。これは、たとえば Klocwork 2022 の任意のバージョンから Klocwork 2023.4に、データをインポートまたは移行することなく、Klocwork ビルドをロードできるということです。詳細については、ビルドのクロスバージョンサポートを参照してください。

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

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

サーバーの起動および停止方法の詳細については、Klocwork サーバーの起動および Klocwork サーバーの停止を参照してください。

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

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

   kwservice --projects-root <projects_root> check 
   

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

Important: Klocwork データの移行にかかる時間を削減するために、次のことを強くお勧めします。

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

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

dbvalidate は、データベースのデータの一貫性をチェックするツールです。移行またはインポート前にデータベースのエラーを修正できるようにするには、このツールの実行が必須です。インストールされているソフトウェアのバージョンと一致する dbvalidate ツールのバージョンを使用します (つまり projects_root ディレクトリと一致するバージョン)。

データベースを検証するには、古いインストールのデータベース サーバーを実行する必要があります。データベース サーバーは、Klocwork サーバーとは別のサービスとして一覧表示されるため、それが実行されていることを確認します。

次のコマンドを実行します。たとえば、

java -jar <server_install>/class/dbvalidate.jar --projects-root <projects_root>

フィールド

• <server_install> はお客様のインストールディレクトリです。
• <projects_root> は検証する古いプロジェクトルートの場所を指定します。

例

java -jar /local/tools/klocwork/server/class/dbvalidate.jar --projects-root /local/tools/klocwork/server/projects_root 

dbvalidate ツールは、"validation started" から "validation finished" までの行のエラーを報告します。

Wed Jun 01 07:53:58 CDT 2022 kw_central database (version: 95) validation started
<detected errors appear here>
Wed Jun 01 07:54:28 CDT 2020 Database validation finished.

• エラーが表示される場合は、インポートまたは移行前にエラーを修正できるようにサポートチケットを開いてください。
• エラーが表示されない場合は、データベースは正常に検証されました。

--rebuildIndex=true オプションを使用して dbvalidate を実行することもできます。これにより、指定したプロジェクト用に lucene インデックスを再作成でき、多くの場合インデックスのサイズを減らすことができます。

Important: --rebuildIndex=true オプションを使用して dbvalidate を実行する前に、lucene インデックスフォルダーを必ずバックアップしてください。

たとえば、次を実行できます。

java -cp dbvalidate.jar com.klocwork.dbvalidate.Cleanup231 --projects-root <projects_root_folder> --project <project_name> --rebuildIndex=true

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

ライセンス オプションの詳細については、「ライセンスのカスタマイズ」を参照してください。

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

kwservice --projects-root <old_projects_root> start --migrate

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

Notes

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

• <old_Klocwork_install>/config/kwmysql.ini にある MariaDB 構成ファイルを変更した場合、新規インストールで kwmysql.ini に同じ変更を加えます。

• <old_Klocwork_install>/config/kwfilter.conf にあるコンパイラマッピングを変更した場合、新規インストールで kwfilter.ini に同じ変更が行われます。

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

Notes

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

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

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

Klocwork の最新の改善点を活用するには、Desktop Analysis プラグインを常に最新バージョンの製品にアップグレードすることを推奨します。

Klocwork extension for Visual Studio にアップグレードする際は、以前のバージョンのプラグインで生成された解析結果データはすべて削除されます。このため、まだサーバーと同期されていないローカルの欠陥更新情報はすべて失われます。新しいプラグインから解析結果を取得するために、使用ソリューションを再解析することができます。

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

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

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

   kwservice --projects-root <projects_root> start --migrate
   

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

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

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

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

最後のプレアップグレード統合ビルド解析と最初の Klocwork 2023.4 解析を同じソースコードに実行してから、2 つのビルドを比較することをお勧めします。こうすると、解析エンジンの変化を正しく評価できます。このバージョンのチェッカーの改良、追加、削除の詳細については、新機能を参照してください。