レビューボード+ Mercurial-プロセスコードレビューの実装と自動化の経験

水銀レビューボード しばらく前、チームの拡大に関連して私が働いている会社で、コードレビュープロセスを導入することが決定されました。 選択は審査委員会で決定されました。この製品は十分な機能を備えており、2006年から積極的に開発されており、オープンソースです。 バージョン管理システムとしてMercurialを使用しています。



プロセスを編成するときに直面したタスクについては、レビューボード+ Mercurialバンドルのレビューコードが猫の下にあります。



そのため、サーバーの展開から始めました。 残念ながら、RBサイトのサーバー要件に関する情報は見つかりませんでした。 トピックの検索結果を確認した後、RBが「休む」主なパラメーターはRAMであることが明らかになりました。 ほとんどの場合、4GBの数値は「快適なボリューム」として言及されました。 2から始めましたが、RBはそれらを「離陸」しませんでした。差分を表示すると、「メモリを割り当てることができません」というエラーが点滅しました。 4GBに引き上げられ、すべてが時計仕掛けのようになりました。



次に、ドックのコードレビュープロセスをオフからセットアップし導入するプロセスが開始されました。 サイト。



レビューを公開するためのツールを選択するところまで、すべてが多少スムーズに進みました。 審査委員会の公式ツール-審査チームとMercurialプラグインから選択しました

公式ツールには明確なプラスがあります-レビュー委員会の開発者がサポートしていますが、主な欠点はGUIがないことです。 プラグインはMercurial用に特別に調整されているため、レビュー後よりもいくつかの利点がありますが、主な利点はTortoiseHg GUIへの統合です。 開発者のほとんどはTortoiseHgを使用しているため、プラグインを使用することになりました。

プラグインドックに慣れました。すべてが順調に進んでいるようです。 メインバージョンをダウンロードしました(このページでも別のバージョンが提供されています)。その時点では、まだGoogle Codeでホストされていました 。 使用しようとしましたが、実際には存在しませんでした。非常に悪い状態であることが判明しました。バグはバッチで増加し、Mercurialの最新バージョンとの互換性は完全ではありませんでした。 彼らは代替を置きまし -物事は良くなりましたが、彼女はMercurial> = 2.3との完全な互換性もありませんでした。 しかし、私たちはフォークを掘って希望を失いませんでした、 労働者が発見されました! しかし、これには問題がありました。一部のユーザーは、何らかの理由で、Unix仮想マシンとWindowsの「実際の」ハードウェアの両方からレビューを投稿しようとすると、常に404エラーをスローしました。 まだ小さな不具合がいくつかありましたが、今は覚えていません。 当時、これに対処する時間はなかったので、私たちは何を使用しました。



これは半年間続いた。 この間、私たちは、形成された投稿プロセスがかなりの時間を改訂し、一部のユーザーがレビューを投稿するのを忘れた(そして忘れた)ことに気付きました。 したがって、プロセスを可能な限り自動化することが決定されました。



これに関する情報を推測して、次の計画が採用されました。





実装を検討する過程で、別のユーザーに代わってレビューを投稿する機能が必要であることに気付きました。 水星へのプラグインは方法を知りませんでした。 奇跡を期待して、MercuryのWebサイトのプラグインページにアクセスします...信じられません-プラグインが生き返り、開発が始まりました! 公式リポジトリはbitbucket移動しました。プラグインは現在、Mercurialの最新バージョンで動作し、他のユーザーに代わってレビューを投稿することもサポートしています。 奨励され、実装を開始しました。



したがって、これはどのように実装されますか(すべてのアクションはCentOS 6.3を実行しているサーバーで行われます)。



  1. リポジトリにフォルダーを置きます〜/ home / victor / autoreview / gdam_frontend /
  2. RBのプラグインをフォルダーに配置します〜/ home / victor / autoreview / hgreviewboard /
  3. レビュー委員会で 、直感的なログインreview_bot を使用してユーザーを作成し、別のユーザーに代わってレビューを投稿する権限を付与します(「ユーザーとして送信できます」権限)
  4. リポジトリ/home/viktor/gdam_frontend/.hg/hgrcの設定ファイルに移動して、そこに次の行を追加します。

    [拡張子]

    reviewboard = / home / victor / autoreview / hgreviewboard



    [レビューボード]

    #Board Repository ID、詳細を確認-www.reviewboard.org/docs/manual/1.7/admin/configuration/repositories

    レポイド= 1



    #Review Board Review Group、詳細-www.reviewboard.org/docs/manual/1.7/admin/configuration/review-groups

    target_groups = A5_Reviewers



    #レビューボードサイト、詳細-www.reviewboard.org/docs/manual/1.7/admin/installation/creating-sites

    サーバー= レビュー/ revievboard

    ユーザー= review_bot

    パスワード= bot_password



    [フック]

    #Mercurial着信フック、詳細-hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:incoming

    incoming.autoreview = /home/viktor/autoreview/a5.sh $ HG_NODE


  5. 次に、着信フックでハングするスクリプト/home/viktor/autoreview/a5.shを作成します。

    function log { echo '>> '$1 echo `date`' >> ' $1 >> $script_dir/autoreview.log } script_path=`readlink -f "$0"` script_dir=`dirname "$script_path"` revision=$1 log "Processing revision $revision" messages_file='/home/viktor/autoreview/messages.txt' cd /home/viktor/autoreview/gdam_frontend user=`hg log -r $revision | grep 'user:' | sed -r 's/^user:\s{0,}//g'` log "Revision $revision is made by $user " user_found=`grep "^'$user'" $script_dir/users.txt` if [ "$user_found" != "" ] then commit_message=`hg log -r $revision | grep 'summary:' | sed -r 's/summary:\s{1,}//g'` message_found=`grep "$commit_message" "$messages_file"` if [ "$message_found" == "" ] then merge_commit=`echo $commit_message | grep '^\s\{0,\}[M|m]erge'` if [ "$merge_commit" == "" ] then echo $commit_message >> "$messages_file" rb_user=`echo $user_found | sed -r "s/^'$user'\s//g"` log "Found revision board user - $rb_user" review_id=`echo $commit_message | grep -o '[Rr][Bb]-[[:digit:]]\{1,\}' | sed -r 's/^[R|r][B|b]-//g'` if [ "$review_id" != "" ] then log "Updating review $review_id" hg postreview -e $review_id --submit_as $rb_user -p $revision else log "Posting new review for $revision" hg postreview --submit_as $rb_user -p $revision fi else log "Skipping merge revision $revision ($commit_message)" fi else log "Skipping already processed revision $revision ($commit_message)" fi else log "User $user is not listed in users.txt mapping file" fi
          
          





    スクリプトの重要なポイントを見ていきましょう。



    1. スクリプトが置かれているディレクトリを定義する

       script_path=`readlink -f "$0"` script_dir=`dirname "$script_path"`
            
            



    2. 処理されたコミットのハッシュを決定します。これは、着信フックを持つパラメーター$ HG_NODEとして提供されます

       revision=$1
            
            



    3. コミットメッセージを含むファイルを定義します。同じメッセージのコミットをスキップするために使用されます(graft-eのコミット時に表示されることがよくあります)。

       messages_file='/home/viktor/autoreview/messages.txt'
            
            



    4. コミットを行ったユーザーを定義します(コミット情報を出力(hg log -r $ revision)+ grep + sedしてユーザーを「プルアウト」)

       user=`hg log -r $revision | grep 'user:' | sed -r 's/^user:\s{0,}//g'`
            
            



    5. 処理されたコミットのハッシュを決定します。これは、着信フックを持つパラメーター$ HG_NODEとして提供されます

       revision=$1
            
            



    6. レビュー委員会のユーザーとコミットしているユーザーのコンプライアンスのラインを決定します。 これは、次のような特別なファイルusers.txtを検索することで決定されます。

        「Vasya Pupkin <Vasya.Pupkin@example.com>」vasya-p
       「Ivan Petrov <Ivan.Petrov@example.com>」ivan-p 
      最初の行の場合:Vasya Pupkin <Vasya.Pupkin@example.com>-コミットにリストされているユーザー、vasya-p-レビュー委員会の対応するユーザーのログイン

       user_found=`grep "^'$user'" $script_dir/users.txt`
            
            



    7. コミットメッセージを切り取ります

       commit_message=`hg log -r $revision | grep 'summary:' | sed -r 's/summary:\s{1,}//g'`
            
            



    8. messages_fileにそのようなメッセージがあるかどうかを確認します

       message_found=`grep "$commit_message" "$messages_file"`)
            
            



    9. マージがコミットするかどうかを確認する

       merge_commit=`echo $commit_message | grep '^\s\{0,\}[M|m]erge'`)
            
            



    10. コミットをmessage_fileに書き込みます

       echo $commit_message >> "$messages_file"
            
            



    11. 一致文字列からユーザーRBログインを引き裂く

       rb_user=`echo $user_found | sed -r "s/^'$user'\s//g"`
            
            



    12. これが既存のレビューの更新であるかどうかを確認します-コミットメッセージのRB-{{id}}を示す更新の同意。ここで{{id}}-RBでレビューを行います

       review_id=`echo $commit_message | grep -o '[Rr][Bb]-[[:digit:]]\{1,\}' | sed -r 's/^[R|r][B|b]-//g'`
            
            



    13. レビューを投稿する

       hg postreview --submit_as $rb_user -p $revision
            
            



      または既存のものを更新する

       hg postreview -e $review_id --submit_as $rb_user -p $revision
            
            





  6. スケジュール/home/viktor/autoreview/pull_a5.shに従ってリポジトリをプルするスクリプトを作成します

     message_file='/home/viktor/autoreview/messages.txt' echo '' > "$message_file" cd '/home/viktor/autoreview/gdam_frontend' hg pull rm $message_file
          
          





    このファイルでは、空のmessages.txtを作成します。これはa5.shで使用され、現在のプルで繰り返し発生するコミットを識別するために使用されます。 プールを実行した後、このファイルを削除します。

  7. 作成したスクリプトをcronスケジュールに追加します。 5分ごとに実行する例:

      0,5,10,15,20,25,30,35,40,45,50,55 * * * * /home/viktor/autoreview/pull_a5.sh 
    コメントでは、より最適な記録オプションが提案されました。
      * / 5 * * * * /home/viktor/autoreview/pull_a5.sh 


出力には、次の自動レビューディレクトリ構造があります。

/ホーム/勝者/オートレビュー

-/ gdam_frontend-コードレビューを整理するリポジトリのクローン

-/ hgreviewboard-Mercurialのレビューボードプラグイン

-* a5.sh-クエストのレビューの投稿を実行するスクリプト

--autoreview.log-a5.shスクリプトアクションログ

-* pull_a5.sh-プルリポジトリを実行するスクリプトは、cronを使用してスケジュールに従って実行されます

--users.txt-レビュー委員会ユーザー向けのMercurialユーザーマッピングファイル



*は、ファイルに「実行可能」フラグがあることを意味します。



さらに、再依頼のレビューを投稿するプロセスは自動化されており、コミッターにとって「気付かれずに」行われます。 コミッターが行う必要があるのは、チケットレビューの変更をコミットするときだけです。コミットメッセージはRB-{{ID}}で始まる必要があります。{{ID}}はチケットレビューIDです。



何を改善できますか?



  1. ブランチクロージャーコミットのフィルター処理(マージと同様)
  2. バックアウトコミットのフィルター(マージと同様)
  3. messages.txtファイルを使用せずにコミットメッセージが発生するように、コミットメッセージの一意性の検証を改善します(これを行う方法はありません)


私はすべてのコメントとコメントを喜んで検討します。

最後まで読んでくれてありがとう!



All Articles