このセクションでは、コミット後コード レビュー スキャンを構成して実行する方法について説明します。コミット後コード レビュー スキャンは、ソース管理システムをスキャンし、チェックインされたコードの中から新規作成または変更されたコードを特定し、そのコードを担当レビューアーと照合します。 

このセクションの内容:

関連するトピック

概要

コミット後コード レビューを構成するには、次の操作が必要です。

  • サーバー上の Parasoft Test において:
    • コード レビュー用のテスト コンフィギュレーションを構成します (以下のセクションで説明)。
    • このテスト コンフィギュレーションのコマンドライン実行を構成します (以下のセクションで説明)。
    • 自動スキャンのスケジュールを設定します (以下のセクションで説明)。
    • レビュー対象のコードがあるプロジェクトが、Parasoft Test で確実に利用できるようにします。プロジェクトはソース管理システムからチェックアウトするべきです。
  • デスクトップとサーバー両方のすべての Parasoft Test において:

コミット後コード レビューのためのテスト コンフィギュレーション設定

コミット後プロセスのために、コード レビュー用テスト コンフィギュレーションを毎晩サーバー上で実行し、ソース管理システムをスキャンします。このテスト コンフィギュレーションは、チェックインされたコードの中から新規作成または変更されたコードを特定し、そのコードを担当レビューアーと照合します。 

重要

コード レビューを実行する前に、デフォルトのコード レビュー用テスト コンフィギュレーションを確認してカスタマイズする必要があります。

コードの変更を検出してレビューの準備をするテスト コンフィギュレーションを作成するには、次の操作を行います。  

  1. [Parasoft] メニューの [テスト コンフィギュレーション]をクリックするか、または ツールバーの [テストの実行] ドロップダウン リストから [テスト コンフィギュレーション] を選択します。
  2. 既存テスト コンフィギュレーション (たとえば [ビルトイン] > [Code Review] > [Post-Commit] など) を複製するか、新規にテスト コンフィギュレーションを作成します。
  3. [スコープ] タブで [指定した期間に追加または変更されたファイルだけをテスト] オプションを有効にします。この設定は、どのファイルがコード レビューのために準備されているかを決定します。たとえば、毎日コード レビュー スキャナーを実行する予定の場合、[日前] フィールドに 1 を入力します。毎週実行する予定であれば、 7 を入力します。
    • 別の方法として、ある期間中に変更されたすべてのファイルを準備するように設定することもできます。[締め切り後に追加または変更されたファイルだけをテスト] および [かつ次の日付までに追加または修正されたファイル] を有効にして、期間を設定します。
  4. [スコープ] タブで [ファイル フィルター] > [パス オプション] の設定を確認し、必要があれば変更します。これらのテスト コンフィギュレーション設定の詳細については、「チーム間での SOAtest の構成」を参照してください。
  5. [共通] タブで [ソース管理システムからプロジェクトを更新] チェックボックスをオンにします。
    • コード レビュー スキャンが実行される前にプロジェクトはソース管理リポジトリから完全に更新されている必要があります。コード レビュー スキャンの前にリソースを更新する外部システムがある場合、このオプションをオンにする必要はありません。更新を行う他のシステムがない場合は、このオプションをオンにすることを強く推奨します。
  6. レポート設定で、ユニークな ID を使用してコードレビュー スキャンを実行するよう設定していない場合、[共通] タブに移動して [セッション タグのオーバーライド] オプションを有効にし、設定済みの ID のいずれかを選択するか、独自の ID を指定します。ID は、このテスト コンフィギュレーションから発生するすべてのコード レビューに割り当てられるタグになります。
    • コード レビューが正しくレポートされるには、コード レビュー スキャンのセッション タグを設定し、DTP セッション タグを使用して特定の DTP プロジェクトと関連付けるコード レビューを指定します。
  7. [コード レビュー] タブをクリックします。
    1. [コード レビュー スキャナーを有効化] チェックボックスをオンにします。
    2. すべての利用可能なチーム スキャナーからのコード レビューの結果をレポートに含めるには、[詳細なレポートを生成] オプションを有効にします。このオプションを無効にすると、レポートには、現行のテスト コンフィギュレーションで指定したスキャナー識別子の結果だけが含まれます。
    3. このテスト コンフィギュレーションを実行した後にコード レビュー タスクを自動的に公開 (アップロード) したい場合、[レビューを自動公開] オプションを有効にします。夜間の実行で -publish オプションを使用する場合、この設定に関係なくタスクはパブリッシュされます。
    4. [優先順位] ドロップダウン リストから優先順位を選択します。この優先順位は、このテスト コンフィギュレーションを使って作成するすべてのコード レビュー タスクに割り当てられます。
  8. [作成者]、[レビューアー]、[監督者]、および [フィルター] タブで、コード レビューをどのように割り当てるかを定義します。レビューアーと監督者は、特定の作成者またはプロジェクト領域に割り当てることができます。
    • [作成者] タブで、レビュー対象のコードを作成している開発者のリストを定義します。作成者ごとに名前を指定します。名前とソース管理システムでのログイン名が異なる場合はログイン名も指定します。
      • 作成者リストには、開発者全員を指定することも、一部の開発者だけを指定することもできます。
      • コードの変更をコミットした開発者が [作成者] タブで定義されていない場合、その変更は「未定義の作成者」による変更としてマークされます。
      • ここで作成者をレビューや監督者にマップする必要はありません。これらのフィールドは、以前のバージョンの Parasoft Test との下位互換性を保つためのものです。[作成者] タブで個々に開発者を定義したくない場合、次の設定を行うことができます。1) [フィルター] タブで [レビュー対象パスの (未定を含む) すべての作成者を受け入れ] オプションを有効にします。 2) [レビューアー] タブで、コードのどの部分をどのレビューアーが担当するかを定義します。
    • [レビューアー] タブおよび [監督者] タブで、それぞれのレビューアー/監督者が担当する作成者あるいはプロジェクト領域を指定します。
      • レビューアーは、コードの変更の検証、コメントの追加、および承認を行います。監督者は、リビジョンが確実にレビューされて適時に修正されるよう、プロセス全体を監督します。監督者はレビューを実行する必要はありませんが、リビジョンとレビューにコメントを追加できます。この役割は任意です。
      • パスは、論理的 (ワークスペースの) パス規約で定義されます。ワイルドカードを使用できます。詳細と例については下記の「フィルターのヒントと例」を参照してください。
      • レビューアーと監督者は、特定の作成者やパスにマップすることなく定義できます。そのようなレビューアー/監督者には自動的にコード レビュー パッケージが割り当てられませんが、彼らの名前はレポートに含まれます。作成者は、スキャナー補助のダイアログからレビューアー/監督者を選択することができます。
      • これらのタブは AND 論理ではなく OR 論理を使用します。言い換えると、レビューアー (または監督者) の名前を定義してから、その人物にレビュー (または監督) させたい作成者とレビュー パスを定義します。指定された作成者またはレビュー パスから新しいコードが来た場合、そのコードはこのレビューワーまたは監督者に割り当てられます。
  9. (オプション) [コード レビュー] > [フィルター] タブで必要に応じて以下のオプションを変更します。
    • 抑制されたブロックの変更を無視する: コード レビュー スキャンで "codereview-begin-suppress" マーカーと "codereview-end-suppress" マーカーの間にあるすべての差分を無視する場合、このオプションをオンにします。これらのマーカーは、比較エディターで特定のコード ブロックの差分を非表示にするために使用するマーカーと同じです (詳細については「差分を表示しないコード部分の指定」を参照してください)。
    • 差分: コード レビュー スキャンで、特定のパターンに一致する、現行のソースと以前のソースのすべての差分を無視する場合、適切な正規表現を指定します。たとえば、コード レビューが必要な差分として自動生成コメントがレポートされるのを防止できます。 
    • コミット前とコミット後のマッチング: コミット前およびコミット後コード レビューの複合プロセスに関するオプションです。コードをチェックインする前にレビュー用にコミットする必要があると同時にコミット後にもスキャンを行ってレビュープロセスが正しく行われるよう確認する場合に使用します。
      • コミット前とコミット後のマッチング: コミット後スキャンで、コミット前スキャンとコミット後スキャンの特定のパターンに一致するすべての差分を無視する場合、適切な正規表現を指定します。たとえば、このオプションを使用して、チェックイン時に追加された CVS の自動生成ヘッダーがコミット後レビューが必要な差分としてレポートされるのを防ぐことができます。詳細については、「コミット前とコミット後の両方のコード スキャン」 を参照してください。

      • コミット前検索範囲 (日): コミット前タスクとコミット後タスクの対応を決定する際に使用するタイムフレームをカスタマイズする場合、この設定を変更します。詳細については「 コミット前とコミット後の両方のコード スキャン」を参照してください。
    • レビュー対象パスの (未定義を含む) すべての作成者を受け入れ: 個々に開発者を定義したくない場合、次の設定を行います。1) [レビュー対象パスの (未定義を含む) すべての作成者を受け入れ] オプションを有効にします。 2) [レビューアー] タブで、コードのどの部分をどのレビューアーが担当するかを定義します。
  10. [適用] ボタンをクリックして新しいテスト コンフィギュレーションを保存します。
  11. プロジェクトに対してこのテスト コンフィギュレーションをテストしてから、テスト コンフィギュレーションを実行します。

レビューのためにコードを準備する - スキャナーの自動実行

コミット後コード レビューの場合、通常コード レビュー用テスト コンフィギュレーションはコマンドライン モードで定期的に (たとえば 24 時間ごとに) 自動実行されるように設定されます。テストはチームのコード レビュー用テスト コンフィギュレーションを実行します。テストを実行するたびに、コード レビュー スキャナーはソース管理リポジトリをスキャンして新規/変更のコードを探し、発見したコードをレビュー用に準備します。

コマンドラインの設定

  1. プロジェクトをまだ設定していない場合、Parasoft Test GUI でプロジェクトを設定します。
  2. (任意) 必要に応じてローカル設定ファイル (オプション ファイル) を使って、GUI で指定された設定を上書きします。詳細については、「ローカル設定の指定」 を参照してください。

コマンドラインの実行

コマンドラインからコード レビュー スキャナーを実行するには、次のようなコマンドを使用します。

parasofttestcli -publish -publishteamserver -config "team://xtest-codereview.properties" -resource 
"my_resource"

soatestcli -publish -publishteamserver -config "team://xtest-codereview.properties" -resource
"my_resource" -localsettings C:\tmp\localsettings.properties

上記の例では次のオプションを使用しています。

  • -publish: Parasoft DTP へのテスト結果のパブリッシュ
  • -publishteamserver: テスト結果を Team Server に送ります。 
  • -config: テスト コンフィギュレーションを指定します。例:
    • -config "builtin://Demo Configuration"
    • -config "Demo Configuration"
    • -config "user://My First Configuration"
    • -config "team://Team Configuration"
    • -config "team://teamconfig.properties"
  • -resource: テストするプロジェクト/ファイルを指定します。例:
    • -resource "Acme Project"
    • -resource "/MyProject/src/com/acme/MyClassTest.java"
    • -resource "/MyProject/src/com/acme"
    • -resource testedprojects.properties

ローカル設定ファイルを使って UI での指定を上書きする場合、 -localsettings オプションを使用します。例:

  • parasofttestcli -publish -config "team://xtest-codereview.properties" -resource 
    "my_resource"  -localsettings C:\tmp\localsettings.properties

複数の Parasoft 製品がある場合における parasofttestcli での -config の使用

複数の Parasoft 製品をインストールしていて、SOAtest 固有のコマンドではなく、parasofttestcli を使ってテストを実行したい場合、必ず -config の後に製品名を追加し、どの製品のテスト コンフィギュレーションを使用するのかを指定してください。 

たとえば、parasofttestcli を使って SOAtest の [Code Review] チーム テスト コンフィギュレーションを実行するには、次のように指定します。 

parasofttestcli -config "soatest.team://Code Review" -resource "my_resource"

レビューアーへの通知

コード レビュー スキャナーの実行のたびに、コードのレビューの準備ができたことが担当レビューアーに通知されます。レビューアーは 「レビューアー:コードの変更のレビュー」にあるようにレビューすることができます。

レビューが完了した後、作成者は「作成者:レビュー コメントの検証と対応」にあるように対応することができます。

コミット前とコミット後の両方のコード スキャン 

プロセス

開発チームによっては、コミット前のプロセスによってレビューのためにコードをサブミットするだけでなく、次の理由から定期的にサーバー モードで (製品のコマンドライン インターフェイスから) コミット後のスキャンを実行したい場合があります。

  • 以下の両方が実行される 2 層の通知システムを構築する。
    • 各チーム メンバーにタスクをレビューするよう IDE の通知によって知らせる。これを実現するには、[新規または更新されたレビューを次の間隔で通知] オプションを使用します。
    • サーバーからサマリー レポートを E-mail で送信し、保留中のレビュー タスクについてレビューアーおよび監督者に通知する。E-mail は適切なレポート オプションが設定されている場合に生成されます。[詳細なレポートを生成] オプションがオンの場合、レポートにはすべてのコード レビュー スキャン (コミット前およびコミット後) のタスクが含まれます。オプションがオフの場合は、現在のコミット後スキャンのタスクだけが含まれます。コマンドライン実行からのレポート生成設定の詳細については「レポートの生成」を参照してください。
  • ソース管理にコミットされたがコミット前の処理でレビューのためにサブミットされなかったコードの変更を特定する。

コミット前プロセスに加えてコミット後のスキャンを実行する場合、次の処理を行うことができます。 

  • 空のワークスペースに対してコミット後スキャンを実行する:  この処理は、さらにスキャンを実行したり、さらにタスクをレポートしたりすることはありません。単純に、(適切なレポート オプションが設定されている場合)、サブミットされた "コミット前" レビューに関連する電子メールを生成します。
  • ワークスペースをセットアップしてから、-include を使ってコミット後スキャンを実行し、プロジェクト中のスキャンしたい部分だけを再スキャンする:  この処理は、コミット前レビュー プロセスでレビューのためにサブミットされなかった、プロジェクト中の重要なコード部分の変更を発見し、それらの変更点について新規にタスクを生成します。
  • 完全なワークスペースをセットアップし、すべてのコードに対してコミット後スキャンを実行するこの処理は、コミット前レビュー プロセスでレビューのためにサブミットされなかったコードの変更点を発見し、それらの変更点について新規にタスクを生成します。

チェックインされたすべてのコードを確実にレビューしたい場合

多くのチームが以下を要求するポリシーを推進したいと考えています:

  • すべてのコードの変更をレビューする
  • コードをレビューしてからでなければチェックインしてはならない

これを達成する方法の 1 つは、ハイブリッド コード レビュー プロセスを構築することです。ハイブリッド コード レビュー プロセスでは、コミット前コード レビューでレビュー用にコードをサブミットしてから、コミット後モードを使用してこのプロセスが守られているかを検証します。 

コミット後スキャンは、対応するコミット前タスクが「完了」としてマークされていない場合、コード レビュー タスクをレポートします。[フィルター] タブの [コミット前検索範囲 (日)] オプションを変更すると、対応するコミット前タスクを決定する期間をカスタマイズできます。デフォルトでは、コミット後スキャンから遡って 7 日前まで検索します。 

マネージャーを監督者として設定できます。リリースまたはビルドの前にすべてのコードがレビューされたかどうかを確認するには、1) コミット後タスクがレポートされていないこと、2) 監督者 E-mail にコミット後プロセスからの保留中のレビュー アイテムが表示されていないことを確認します。 

コミット前とコミット後が混在するコード レビュー プロセスにおいて、コード レビュー スキャナーが「コミット前コード レビューでレポートされた変更点」と「ソース管理システムにコミットされた変更点」とを比較することにも注意してください 

  • 変更の内容が一致した場合、これは、ソース管理システムにコミットする前に、コミット前コード レビューによってファイルがレビューされたことを意味します。  この場合、コミット前プロセスは実施されています。
  • 変更の内容が一致しない場合、これは、ファイルが変更されたにも関わらずコード レビューに出されなかったことを意味します。この場合、コミット前プロセスは実施されていません。

ただし、レビューを必要としない細かな変更がソース管理システムにコミットされることもあります。たとえば次のような CVS ヘッダーなどです。

/*
* $RCSfile: MyFile.txt,v $
* $Revision: 1.13 $
*
* Comments:
*
* (C) Copyright Parasoft Corporation 1996.  All rights reserved.
* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF Parasoft
* The copyright notice above does not evidence any
* actual or intended publication of such source code.
*
* Revision 1.2  2006/02/03 10:07:28  dan
* class repackaged
*
* Revision 1.1  2005/09/18 09:26:24  mark
* new file
*/

そのような場合は、夜間のコミット後スキャンのためのテスト コンフィギュレーションで、自動生成コードを表す正規表現を指定するべきです。この設定は、[コード レビュー] タブの [フィルター] タブの [コミット前とコミット後のマッチング] オプションで指定できます。

たとえば、上記の例の CVS ヘッダーの変更を無視するには、次のように入力します: (^ \* .*)|(^ \*$)

また、レビューする必要がないその他の変更点を照合して無視するようテスト コンフィギュレーションを設定することもできます。たとえば、開発チームはドキュメントの変更をレビューすることなく直接ソース管理システムにコミットすることができます。 

  • No labels