Gerritコードレビュー：写真付きのクイックガイド

Gerrit Rietveldによる赤と青の椅子（1918）



BadooにはC / C ++プログラマー部門があります。 部門は非常に小規模であるため、その従業員は通常、異なるプロジェクトに従事しますが、例外的な場合にのみ交差します。



この状況のマイナスの結果の1つは、 バスファクターです。 この問題やその他の問題を解決するために、コードレビューシステム（Eng。Code review）を実験的に導入することが決定されました。



コード改訂システムの基本的な要件は次のとおりです。

• ローカルインストール。
• インストールと管理の最小限の労力;
• 最大の使いやすさ;
• プロジェクトへのアクセスの差別化。
• Gitサポート
• 無料（このプロジェクトの実験ステータスによる）。

いくつかのオプション（ Rietveld 、 ReviewBoard 、 Gerrit ）を検討した結果 、 Gerritをインストールして作業の準備をするのが最も簡単であるように思われました。 そのため、このシステムの使用に関する小さなガイドを作成することにしました。

歴史ツアー

オープンソースの世界ではよくあることですが、Gerritは別のプロジェクトのパッチセットとして登場しました。 元々の目標は、Pythonの著者であるGuido van Rossum（オランダ語： Guido van Rossum ）によってPythonで記述されたコードリビジョンシステムであるRietveldにACLサポートを追加することでした。 GuidoはRietveldコードを複雑にしたくないという事実のため、後者のフォークはGerritという名前で登場しました。



Gerritは後にPythonからJavaに書き直され、完全に独立したプロジェクトになりました。 現在、GerritはeBay、Sony、Couchbase、MediaWiki、Rockbox、Qtなどの企業とプロジェクトを使用していますが、最も有名なGerritユーザーはおそらくAndroid開発プロジェクトですGerritと書かれました。



ところで、ここでプロジェクト名の説明を見つけることができます： http : //en.wikipedia.org/wiki/Gerrit_Rietveld

動作原理

Gerritの開発は次のとおりです。

• リポジトリはGerritで作成されます。
• 開発者は、Gerritからリポジトリを複製します（またはgit remoteを既存のプロジェクトに追加します）。
• git pushを使用して、開発者は変更を送信して、リポジトリの特別なブランチのコードを修正します。
• Gerritは、変更レコードごとに個別の「チケット」を作成し、監査人はこれをコメント、適用、または拒否できます。

Gerritでアクセスシステムを設定することにより、開発者がコードリビジョンをバイパスして変更を送信することを防ぎ、これを監査人のみに任せることができます。これは私たちにとって非常に適しています。

インストールとセットアップ

GerritディストリビューションはWARアーカイブの形で配布されているため、インストールは非常に簡単です：データベースの作成（MySQL、PostgreSQL、組み込みH2がサポートされています）、ユーザーのシステムへの追加、サイトの初期化、Webサーバーの設定。 Badooは伝統的にnginxを使用するため、設定しました。 nginx.confでは、次のようになります。

server { listen 80; server_name gerrit; rewrite ^(.*) https://$server_name$1 permanent; } server { listen 443; server_name gerrit; add_header Strict-Transport-Security max-age=15768000; ssl on; ssl_certificate /local/nginx/conf/cert/gerrit.crt; ssl_certificate_key /local/nginx/conf/cert/gerrit.key; ssl_session_timeout 5m; ssl_session_cache shared:SSL:1m; ssl_protocols TLSv1; ssl_ciphers HIGH:!ADH; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host; auth_basic "Restricted"; auth_basic_user_file htpasswd; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インストールの詳細はドキュメントに記載されているため、詳細には触れず、代わりにGerritウェブインターフェースの説明に直接進みます。



これは、最初のインストール直後の最初のGerritページの外観です。







現在、Gerritはローカル認証をサポートしていません。 OpenID、HTTP Basic / Digest認証 、およびComputer Associates Siteminder （商用の「シングルサインオン」ソリューション）のサポートがあり、それだけです。 外部承認を使用するという決定は、オープン参加のプロジェクトでは非常に論理的ですが、この場合、その疑わしい利便性にもかかわらず、HTTP認証が唯一の可能なオプションです。

Gerritを始めよう

電子メールとSSHの公開キーを追加してシステムに登録すると、作業を開始できます。



まず、Gerritで新しいプロジェクトを作成する必要があります。 残念ながら、Webインターフェースを介してこれを行う方法はありません。 記事の執筆過程でGerrit 2.3がリリースされました。この省略は修正されました。最後に、Webインターフェースから直接新しいリポジトリを作成できます： Admin \ Projects \ Create new project：







プロジェクト作成フォームで、継承する権限をすぐに選択できます。これは、一般的な権限を持つプロジェクトを作成するときに役立ちます。 デフォルトでは、共通の権利（ All-Projects ）が継承されます。



追加のプロジェクト設定を指定することもできます。







コンソールに移動し、Gitを直接操作します。

 $ git clone ssh://gerrit:29418/test_project.git Cloning into test_project... warning: remote HEAD refers to nonexistent ref, unable to checkout.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告は無視できますが、かなり正当化されています（リポジトリにはリビジョンが含まれていません）が、私たちにとってはまったく役に立ちません。 奇妙なポート29418に驚かないでください-Gerritは独自のSSHサーバーとGit（JavaのJGit）を実装しています。



コードの最初のファイルと最初のリビジョンを作成します。

 $ cd test_project $ echo “test” > README $ git add README $ git commit README -m “first commit” [master (root-commit) b1f69cf] first commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 README
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのプロジェクトのデフォルトの権限は、コードリビジョンシステムをバイパスしてサーバーに変更を送信することを許可しないため、この段階でコマンド `git push origin master`は次のエラーで終了します。

 $ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 224 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To ssh://gerrit:29418/test_project.git ! [remote rejected] master -> master (can not create new references) error: failed to push some refs to 'ssh://gerrit:29418/test_project.git'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの目標は、監査人が常にコードをレビューして承認することを確認することですから。 したがって、次のようにサーバーに変更を送信する必要があります。

 $ git push origin HEAD:refs/for/master Counting objects: 3, done. Writing objects: 100% (3/3), 224 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: New Changes: remote: https://gerrit/337 remote: To ssh://gerrit:29418/test_project.git * [new branch] HEAD -> refs/for/master
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

控えめに言っても、コマンド構文は最も便利ではないことに注意してください。 ただし、これは次の設定で簡単に修正できます。

 $ git config branch.master.merge refs/for/master
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、変更はサーバーに正常に送信されましたが、すぐにはリポジトリに届きませんでした。 代わりに、サーバー上の識別子337を使用して変更が作成されました。これは、Gerrit Webインターフェイスを介して表示および承認できます（Gerrit出力のリンクに注意してください）。







このスクリーンショットでは、特定の変更のすべてのパラメーターとアクションを確認できます。 必要に応じて、追加の監査人（その場合は通知を受ける）を追加したり、確認（ レビュー ）したり、変更を拒否（ 変更を破棄 ）したりできます。 また、プロジェクトのチェックアウト 、 プル、チェリーピック、またはこの変更のパッチの受信など、簡単な「コピー/貼り付け」用の既製のコマンドテキストもあります。



当然、各変更にコメントを追加できます。これは[ レビュー]ページで行われます。先に進みましょう。







ここでは、変更評価フォームを直接見ることができます。 この写真では、5（-2 / -1 / 0 / + 1 / + 2）のうち3（-1 / 0 / + 1）の評価しかありません。 これは、テストユーザーのPhilip J. Fryがこのプロジェクトに対する投票権を持たないために発生しました。



評価-1 / + 1には推奨ステータスがあり、変更の受け入れまたは拒否には影響しません。したがって、デフォルトでは、すべての登録ユーザーにそれらを置く権利があります。 決定的なのは、 -2と+2の評価です（いいえ、-1 / + 1は要約されませんが、これは自動スクリプトを使用して実行できます）- +2の評価は変更を適用でき、 -2の評価は変更をブロックし、変更が適用されるまで適用できませんその削除（任意の数+2の存在にもかかわらず）。 投票システムの詳細な説明は、ドキュメントにあります 。



ユーザーに決定的な権利を与えると同時に、Gerritの権利システムを説明します。 まず、グループを作成する必要があります。グループを作成すると、プロジェクトの変更を評価できます。 これを行うには、[グループ]タブに移動します。一番下には、新しいグループを作成するためのフォームがあります。 テストユーザーはこのグループのメンバーに自動的に追加されますが、他のユーザーを追加する必要がある場合は、名前を入力するだけで、Gerritからヒントが表示されます。







この後、新しいテストレビューアグループには、このプロジェクトへの変更を承認または拒否する権利を与える必要があります。 [ プロジェクト ]タブで、 プロジェクト 、[ アクセス ]タブを選択し、[ 編集 ]ボタンをクリックします。







このページでは、権限とそのパラメーターを変更できます。 この場合、 テストレビューアーに -2から+2までの評価（ Label Code-Review ）を与える権利を与えます。この権利はプロジェクトのすべてのブランチに拡張されます。 同時に、同じグループに変更を適用する権利（ Submit ）を付与します。 新しい特権を追加した後、変更ページに戻ります。 さらに多くのオプションが表示されるようになりました。







ご覧のとおり、まず、決定的な+2および-2を含む、変更の評価をユーザーに提供する機会があります。 次に、 発行と送信ボタンが表示され、ユーザーが変更を適用できます。

特権システム

Gerritには複雑な特権システムがあります。 各特権はユーザーのグループに付与でき、同時にそのアクションの範囲をリポジトリの特定のブランチのフレームワークに制限できます。 同時に、管理者は新しい特権を作成できます（ ドキュメントには、著作権をチェックする例を示しています）。



デフォルトで使用可能な特権のリスト：

*ラベル確認済み -変更をチェック済みとしてマークする機能。

このカテゴリは、Androidプロジェクト専用に追加されたものであり、変更によってプロジェクトのアセンブリが中断されることはなく、テストに合格することを意味します。 このカテゴリは役に立たなかったため、削除方法についてはドキュメントに記載されています 。

*ラベルコードレビュー -利用可能な評価の範囲（-2から+2）を指定する機能を備えたコードの直接改訂。

*参照の作成 -リポジトリにリンク、ブランチ、タグを作成する機能。

* Forge作成者/ Forgeコミッター/ Forgeサーバー -他の人からの変更を「偽造」する機能。 Gerritは通常、作成者のメールアドレスが登録済みアドレスの1つと一致することを要求しますが、これはこの特権で回避できます。 通常、既存のリポジトリをGerritにインポートするときにのみ必要です。

*所有者 -このプロジェクトの権限を発行/変更する権限、プロジェクトの説明を変更する権限、リポジトリ内のブランチを削除および作成する権限を与えます（Webインターフェイスのみを使用）。

*プッシュ -変更（Eng。Commit）をリポジトリに書き込む権利。 refs / *でのコミットの特権は、コードリビジョンシステムをバイパスして、リポジトリに変更を直接追加する権利を与えます。

*プッシュマージコミット -ユーザーがブランチをマージできるプッシュへの追加。

*注釈付きタグのプッシュ -プッシュへの追加。今回は、リポジトリにタグを追加できます。

*読み取り -リポジトリ内のコード、システムの変更、およびそれらに対するコメントを読み取る権利。 デフォルトでは、システムに登録されているすべてのユーザーに許可されています。

*送信 -リポジトリに変更を適用する権利。



目標に基づいて、プロジェクトに次の最適な構成を選択しました。







したがって、「コミッター」は、コードリビジョンを目的としたリポジトリの部分にブランチマージを追加し（リポジトリに直接ではない）、タグと変更自体を作成してさらに検討することができます。 また、監査人は変更を確認して適用できます。

結論の代わりに

Gerritは、この記事の著者にかなり複雑な印象を残しました。



一方で、その機能のいくつかは、明白ではなく、不便であるか、まったく存在しません。これは一般に、記事のタイトルに描かれている奇妙な椅子に非常によく似ています。 たとえば、インターフェイスからグループを削除することはできません。プロジェクトコードを表示する方法はありません。最近まで、SSHを介してのみブラウザから新しいプロジェクトを作成することさえ不可能でした。 また、多くの管理機能はデータベースで直接実行する必要があり、これには問題が伴います。 Gerrit自体にユーザー管理がないことも良くありません。 一般に、 このリストを確認する多くの欠点があります 。



一方、Gerritは直接的な機能を正常に果たし、最初の知人とセットアップにしばらく時間を費やした後、開発者からの注意を必要としません。



結論として、私たちはGerritを実装した当初の目標が決して達成されなかったことを認めなければなりません-それを見るだけでプロジェクトの議論に参加せず、コードがなぜそうなのか理解していない開発者コードを「紹介」しようとするのは無意味です彼はそのままです。 しかし、コードリビジョンシステムは、開発者をプロジェクト全体に責任を持ち、他の人の変更を検討する「所有者」と、変更を直接適用することなくプロジェクトに変更を送信できる「参加者」に分割できる既存のプロジェクトの場合に非常に機能します。 したがって、すべての欠点にもかかわらず、私たちの部門はGerritを採用し、現在進行中のすべてのプロジェクトにGerritを使用しています。



アントン・ドヴガル、開発者

バドゥー会社