私は、人々が SVN にコミットするためのピア レビューを強制および追跡するためにどのようなメカニズムを使用しているのか疑問に思っていました。
コミットごとに、人々がピアレビューを受けているかどうかを追跡できるようにしたいと考えています (コミットできないルールを適用することが良い考えかどうかはわかりません。ピア レビューなしでコミットするおそらく正当な理由です) が、未レビューのコミットを追跡して、リリース前にこれらすべてのコミットを表示できるようにする必要があります。
[REV:XYZ] のような固定形式で、レビューする開発者のタグをコミットに追加することをすべての開発者に要求できます。これにより、履歴をフィルタリングできます。ここで述べたように、必要に応じて、ソース コード バージョン管理ツールの pre-commit フックを使用してこれを強制できます。
次に、ピア レビューなしにコードをコミットしてはならないという規則を、すべての開発者に伝える必要があります。また、コミットする前にコードをレビューすることの利点も示します。最初の数か月は、誰かがレビュアー タグのないコミットのコミット履歴を確認する必要があります。見つけた場合は、開発者にレビューを行った理由と誰と一緒に行ったかを尋ねます。レビューがなかった場合は、ルールを思い出させます。一部の開発者が故意にこの規則に数回違反した場合、影響が生じる可能性がありますが、通常、仲間からの圧力により、これは発生しません。
通常、このルールが適用されている場合、審査を行わない理由はありません。特に、「しかし、顧客に修正済みバージョンを提供するために、このバグを迅速に修正する必要がありました」は言い訳にはなりません。開発者は急いでエラーを起こす可能性が高いからです。
この質問は、git や bzr のような分散型 VCS の宣伝のように聞こえます: 開発者は変更を頻繁にコミットできる必要がありますが、独自のブランチにコミットし、中央リポジトリにプルされる前にレビューされます。
開発者は、変更ごとに (すべてのコミットではなく) ブランチを作成できます。このブランチでは、何度でもコミットできます。ただし、変更がトランクにマージされる前に、ピア レビューを実施できます。したがって、トランクにはピアレビューされたコードのみが含まれます。
パーミッションを介してこれを行うことができるため、選択した人だけがトランクにコミットでき、コミットする前にコードが問題ないことを確認できます。
私はしばらくの間バージョン管理を使用しており、(トランクで作業するのではなく) ブランチ モデルで作業する方が良いと思います。git のような DVCS システムはこれをさらに一歩進めており、多くの人にとってうまく機能しているようです。
個人的には、1 日に 50 回近く svn にコミットできることが多いので、好きではありません ;)
Atlassian の jira 用 greenhopper プラグインを pre-committ フックとして実行して、コミットで jira 参照を要求できることを知っています。開発タスクの計画にも greenhopper を使用する場合、すべてのコミットを jira 課題に接続するように強制できます。
また、greeenhopper を使用していない場合でも、問題追跡参照番号を含むコミットコメントを強制する pre-committ フックを作成できる可能性があります。
これにより、jira 課題に関連付けられた収集済みの変更セットを収集できるようになるはずです。
これを行う 1 つの方法は、チームでレビュー担当者コミット ルールを使用することです。つまり、開発者は自分のコードをコミットすることは許可されておらず、他の誰かに自分のコードをコミットするよう説得する必要があります。
私は以前にこのようなプロジェクトに取り組んだことがありますが、かなりうまく機能しています。欠点は、Subversion の場合、開発者ではなくレビュアーの名前がログに表示されることです。git を使用すると、開発者の名前を保持でき、レビュアーは Signed-off-by: 行を追加します。