EN JP CN

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

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

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

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

projects_root ディレクトリおよび構成設定は、kwservice --migrateコマンドを使用することによって新しくインストールしたKlocwork に移行できます。一般的に、このプロセスには以下の手順が必要です。

  • サーバーの停止と既存のプロジェクト ルート フォルダーおよび構成設定のバックアップ
  • 既存プロジェクト ルート フォルダー、サーバー、ポート設定の指定による、新しい Klocwork サーバー パッケージのインストール
  • データベースの再検証
  • インストールのテスト

お使いになる前に

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

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

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

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

Tomcat サーバー構成: Klocwork Static Code AnalysisTomcat サーバー構成(<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 にインポートするを参照してください。

Klocwork のバージョンを使用している場合は、 このアップグレード パスに従います
11.011.0 最新 --> Klocwork 2017.2 最新
11.111.1 最新 --> Klocwork 2017.2 最新
11.211.2 最新 --> Klocwork 2017.2 最新
11.311.3 最新 --> Klocwork 2017.2 最新
20172017 最新 --> Klocwork 2017.2 最新
2017.12017.1 最新 --> Klocwork 2017.2 最新

リリース間の相互運用

Klocwork 2017.2 は、以前のバージョンの Klocwork 2017 サーバープラグインまたはデスクトップ解析プラグインと下位互換性があるので、どちらか一方をアップグレードすれば正しく動作します。 Klocwork バージョン 2017 は、製品のバージョン 11.x と下位互換性がありません。サーバーとデスクトップ解析両方のプラグインを、製品のバージョン 2017 にアップグレードする必要があります。

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

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

Klocworkサーバーパッケージのインストール

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

データベースの検証 (必須)

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

注: データベースを検証するには、古いインストールのデータベース サーバーを実行する必要があります。データベース サーバーは、Klocwork サーバーとは別のサービスとして一覧表示されるため、それが実行されていることを確認します。
次のコマンドを実行します。たとえば、
java -jar <11.0_server_install>/class/dbvalidate.jar --projects-root <projects_root>

フィールド

  • <11.0_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 2011 kw_central database (version: 95) validation started
<detected errors appear here>
Wed Jun 01 07:54:28 CDT 2011 Database validation finished.
  • エラーが表示される場合は、インポートまたは移行前にエラーを修正できるようにサポートチケットを開いてください。
  • エラーが表示されない場合は、データベースは正常に検証されました。

新しいライセンスの正しいディレクトリへの配置

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

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

Klocwork データの移行

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

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

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

注意

  • これまでのリリースで MISRA などのカスタム分類基準をインポートしている場合は、新しい分類基準ファイルをインポートして変更を反映させてください。分類基準の変更リストについては、新機能 を参照してください。MISRA チェッカーを利用している場合、taxonomies フォルダから misra.checkers.zip ファイルを <projects_root>/plugins フォルダにコピーする必要があります。

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

構成ファイルまたはメトリックファイルをカスタマイズした場合

  • <old_Klocwork_install>/config/kwmysql.ini にあるMySQL 構成ファイルを変更した場合
    新しいインストールの kwmysql.ini も同様に変更します。
    注: バージョン 9.2 以降で使用する MySQL のバージョンでは、次のフィールドはサポートされません。以前の kwmysql.ini ファイルにこれらのフィールドが含まれる場合、これらの行を新しいファイルにコピーしないでください。
    skip-bdb
    myisam_max_extra_sort_file_size
    重要: カスタマイズした構成ファイルを新しい Klocwork インストールにコピーしないでください。代わりに、新しくインストールした構成ファイルに対して同様のカスタマイズを行います。
  • <old_Klocwork_install>/config/kwfilter.conf にあるコンパイラマッピングファイルを変更した場合
    新しいインストールの kwfilter.conf も同様に変更します。
    重要: カスタマイズした構成ファイルを新しい Klocwork インストールにコピーしないでください。代わりに、新しくインストールした構成ファイルに対して同様のカスタマイズを行います。
  • カスタムメトリクスレポートを Klocwork Static Code Analysis に追加した場合、カスタムメトリクスレポート構成ファイル (metrics.xml) を編集する必要があります。metrics.xml ファイルは、次の場所にあります。
    <projects_root>/config

注意

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

アップグレードのテスト

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

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

すべてのデスクトップ解析プラグインをアップグレードする

Klocwork のすべてのプラグインが Klocwork2017.2 にアップグレードしたことを確認します。

Klocwork Desktop Analysis プラグインを一度立ち上げた後は、Klocwork ポータルから適切なプラグインをダウンロードすることによりユーザー自身がプラグインを再インストールできます。サーバーにプラグインをダウンロードおよび展開する方法の手順については、デスクトップ解析プラグインのダウンロードと展開を参照してください。
注: Klocwork extension for Visual Studio にアップグレードする際は、以前のバージョンのプラグインで生成された解析結果データはすべて削除されます。このため、まだサーバーと同期されていないローカルの欠陥更新情報はすべて失われます。新しいプラグインから解析結果を取得するために、使用ソリューションを再解析することができます。

他の projects_root ディレクトリでアップグレードのステップを繰り返す

別の 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 2017.2

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

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

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

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