Codeisok、またはBadooでのコードレビューの履歴

読者の皆さん、こんにちは！ 私の名前はイリヤ・アヤエフです。私はBadooでほぼ7年間働いています。 私の現在の職務はエンジニアリングディレクター品質保証と呼ばれ、実際、会社では多くのことを行っています。品質管理、リリースエンジニアリング、開発プロセスと方法論、さらには情報セキュリティです。 私の責任範囲内にある1つの領域は、コードレビューです。 今日、私たちのプロセスの歴史と結果（ オープンソースのcodeisokになった ） についてお話します。

この記事には歴史的な説明が含まれていますが、コードレビューのためのさまざまなツールの技術的な比較はありません。 それにもかかわらず、私はそのようなツールの例を提供します、そしてあなたが質問に興味があるなら、あなたは自分でツールをインストールして比較することを試みるかもしれません。

かつてBadooでコードレビューはありませんでした。 実際に。 変更されたコードに関する情報を交換する最初の試みは、単に変更をメールに送信することでした。 ちなみに、Gitも使用されませんでした。



2011年の夏、私が最初に入社したとき、コードのバージョンを保存するためにSVNが使用されました。 以前は、誰もがCVSで働いていて、Mercurialに切り替える試みが1回あったと言いましたが、失敗しました。 なぜ-誰も覚えていない。 実際のところ、Mercurialを試してみることにしたとき、別のVCSに切り替える必要は特になかったのではないかと思います。 すべてがすべての人に適しています。 そして、ファッションのためにファッショナブルなツールを必要とする人はいません。









いずれにせよ、私はそれらの時間を見つけませんでした、そして、プロジェクトの私の知り合いはSVNと密接に関連しています。 開発は1つのブランチ（トランク）で行われました。 時々、サードパーティの実験的な事柄が別のSVNブランチで行われ、その後、共通のブランチで発生したことを減らすための苦痛な試みが行われました。 驚くことではありません。SVNはブランチでの作業に最も理想的なものではありません。



作業の流れは次のようになりました。トランクヘッドを取得し、コードを変更し、コミットします（SVNはサーバーへのコミットをすぐに共通コードに受け入れます）。 SVNから受け取ったリビジョン番号を覚えて、チケットに書き込みます。これにより、レイアウトでどのタスクに入ったのかが明確になります。 明らかに、チケットのリビジョン番号が本番リビジョンに記載されている番号よりも小さい場合、このタスクのコードはコミットの履歴にあります。



コミット後、変更のある差分がメール、一般的なメーリングリストに送信されました。 これにより、コードの変更に精通したい人はこれを行うことができます。 当然、合理化されたコードレビュープロセスはありませんでした。

Git

プロジェクトにちょうど来て、プロセスの正しい構築に夢中になっていたQA部門の責任者として、そのように生きることは不可能であることがすぐに私に明らかになりました。 1つのブランチで開発されたコードは、問題やエラーを分析するのが難しく、レイアウトするのが難しく、ロールバックできないので、適切なテストでは完全に失敗します。









したがって、最初に行うべきことは、ハエをカツレツから分離することです。 その結果、Gitへの切り替えと機能ブランチのイデオロギーがもたらされ、このアプローチのすべての付随的な利点が得られました。 2012年のRIT ++でこの移行について詳しく説明したのは、 Yuri Nasretdinovとのペアレポート です 。



この場合、何らかの方法でタスクのコードに加えられた変更を追跡する必要があり、さらにリリースブランチで追跡する必要がありました。 何が行われたか、それをテストする方法、レイアウトする方法、エラーの原因を見つける方法などを理解するために、2つのことを行いました。

1. 彼らは、メールへの手紙の形で変更を通知する「古い」メカニズムを残しました。 ちなみに、このアプローチは今でも使用されており、多くのエンジニアが便利です。コードの特定のセクションや特定のタスクで特定の人が行った変更をメールでいつでも見つけることができます。 今日Badooでは、このメカニズムは通常のコードレビュープロセスと並行して機能します。
   
   
2. コードビューアーを中央のGitリポジトリにインストールしました。リポジトリ内のブランチ、コミット、ファイルなどを確認できました。タスクコードが一般的なリポジトリに入ると、このWebインターフェイスへの変更へのリンクがGitフックに登録されたため、誰もが興味を持ちましたリンクをたどって変更を確認できます。
   
   

その瞬間、cgitのほぼ完全なクローンであるGitPHPは 、この目的に最も適したツールのように思えました。 ミニマルなインターフェイスにより必要なすべてのことができるようになり、PHPのオープンソースコードにより、必要に応じて何かを変更/追加できるため、このツールが気に入りました。



残念ながら、ツールドメインhttp://gitphp.org/は 、今日は死んでいます。 GitHubのリポジトリも削除されました-どうやら、作者はツールの開発と保守をもはや望んでいないようです。 しかし、 https：//github.com/xiphux/gitphpを覚えており、著者であるChris Hanには非常に感謝しています 。



私たちはオープンソースを愛し、尊重しています。GitPHPでは、他の多くのツールと同様に、いくつかの改善を行いました。 たとえば、2013年11月のこの記事では、ツールの速度を最適化する方法と、Chris Hanがそれらをメインコードにどのように受け入れたかについて話しました。

コードレビュー

Gitに切り替えて、プロセスをセットアップしました。 次は？ 開発における多くの事柄に戦略的に影響を与えるもう1つのポイントは、コードレビューです。 多くのプラス（マイナスもありますが、どういうわけか別の記事で説明します）があるプロセスは、当社では構築されていません。









コードレビューを整理するためのさまざまなツールのテストを開始し、トライアルインストールを行い、問題を調査しました。 まず、BadooのメインリポジトリのすべてをPHPコードで整理し、すべてがうまくいった場合にのみ、会社全体に配布したいと考えました。



当時のプロセスとツールに対して行った最も重要な要件は次のとおりです。

1. 社内でツールをホストする機能。 知的ノウハウであるいくつかの開発がありますが、常識の観点から、ソースコードがネットワークに漏れることは本当に望ましくありません。
   
   
2. コードをすぐに表示/修正/チェックできるようにします。 すぐにフィードバックしてください。 たとえば、GitHubのプルリクエストで行われるように、開発者がすべての準備が整ったことを正式に示すまで待たないでください。 さらに、 コードを一般的なリポジトリにプッシュするときに 、多くの基本的なチェックを自動的に行います。
   
   
3. 実装プロセスは透過的でスムーズでなければならず、すでに組立ラインにある現在のタスクを妨げてはなりません。したがって、誰も特別な変更に気付かないようにしますが、必要に応じて人々は新しい機会を得ます。
   
   
4. Jiraとの統合。当時Jiraはすでに社内で広く使用されていました。
   
   

この段階で、プルリクエストのイデオロギーとは異なる2つの新しい用語を使用する必要があります。 これはbrunchdiffとbrunchlogです。 実際、これは単純にベースブランチ（この場合はほとんどの場合マスター）とタスクブランチのコードの違いです。 Branchdiffは、2つのブランチヘッド間の完全な差分です。 Branchlog-2つのブランチのヘッド間の違いを示すコミットの完全なログ。 ブランチのトランクコミットが大きくなると、branchdiffおよびbranchlogのタスクが大きくなります。

ゲリット

同じ頃、私がメインのコードリポジトリとPHPを整理しているとき、私たちのsishniksはリポジトリ（多くのコードがあります）でコードレビューを実施し、 Gerritを試してみることにしました。 この記事の Anton Dovgalは、それがどのようであったか、どのツールがまだ検討されているか、どのような問題を望み、解決できたかについて詳しく述べました。



今後、BerooではGerritは現在使用されていません。 しかし、その時点では、変更のコミットについてのみレビューを行うことができたため、他の部門には適していませんでした。 コードは、ブランチ全体（branchdiff）のコードをレビューできませんでした。 正直に言って、今できるかどうかはわかりません。 したがって、私たちは会社全体のコードレビューのツールとしてGerritから拒否しました。

Gitlab / GitHub

当時、バックオフィスの責任者であるBoris Chernetsovは、コードレビューのためのツールの学習を支援しました。 Boryaはさまざまなツールを配置し、それらがどのように機能するかを示し、これらのツールがサポートするレビュープロセスを提案しました。



しかし、当時考慮されたツールはどれも私たちに適していませんでした（標準的なフレーズは、あなた自身の自転車を発明する正当な理由です）。 私が覚えている限り、主な問題は次のとおりでした。

1. 多くのツールは、自己ホスト型ソリューションを提供しませんでした。 そして、私たちにとってこれは基本的な要件の1つでした。
   
   
2. 事前受信フックがないため、検証が遅れ、開発サイクルが長くなりました。 すべての自動チェックは、プルリクエストの作成後、事後のみ実行できます。 これは、たとえばGitHubの仕組みです。これは有料サービスでもあります。
   
   
3. GitLabは非常に生々しく、多くのバグが含まれていましたが、最初は本当に気に入っていました。 宣言された機能の多くは機能しませんでした。 今日、私が知る限り、彼らはずっと先を行き、プロジェクトをうまく開発しました。
   
   

Gitoriousなどのツールをさらに調べましたが、GitLabに比べても機能がはるかに劣っていて、必要な機能の多くを提供していませんでした。

コードレビュー用のGitPHP

見つけたツールに不満を感じていた私たちは、まったく異なる方法を採用することにしました。 私たちに100％適したツールはなく、GitPHPコードの編集はそれほど難しい作業ではないので、GitPHPでコードをコメントするための最も簡単なメカニズムを作ってみませんか？ 特に、サーバーにコードを保存する必要がある他のすべてのもの、アクセス制御Gitosis 、チケットへのバインド、ブランチへの変更の表示などはすでに存在します。



彼らはそれを決めました。



最初のバージョンを作成するのに時間がかかりませんでした。 Nikolay Krapivnyは、 Atlassian Crowdを介して承認を行うのを助け、数日でコード行をコメントアウトする最も簡単な形式を提供しました。 そして、それがどれほど便利で便利なのかを理解しました：チケットのリンク（誰もが慣れている以前にあったリ​​ンク）をクリックすると、コードにコメントを書くことができます。



コメントは電子メールで開発者に送信され、公開メーリングに配置できます。 また、Jiraのチケットに追加されました。 とても快適です。 別個の「レビュー用チケット」の作成に煩わされるため（たとえばCrucibleのように）、GitPHP内でレビュアーを割り当てる（レビュアーはJiraでの開発後にチケットが転送されたものです）、別個のレビューステータスなどは必要ありません。 コメントがあり、チケットが再開されました-つまり、コードを修正する必要があります。 すべて順調であれば、チケットをさらに転送します。



このシンプルなスキームはプロジェクトに有機的に適合しており、開発者はそれを非常に気に入っており、迅速かつ簡単に取り上げられて使用され始めました。

るつぼとFishEye

しかし、バックエンドの開発者がすぐにアイデアを採用し、ツールを広く使用するようになり、一部の開発者も開発に貢献したにもかかわらず、すべてが完璧というわけではありませんでした。



モバイル開発者は最初は強く抵抗し、ツールの使用を拒否しました。 言い訳は異なっていました：インターフェースが快適ではないという事実から始めて、彼が緊急に必要とするものがないという事実で終わる。



市場に出回っているコードレビューツールを数回レビューし、状況を改善することを期待して適切なものを見つけようとしました。 ツールは実際に開発され、多くの便利な機能を追加しますが、それほど多くの機能は追加されません。 しかし、これらすべての問題は新しいものです。



そのため、次のレビューツールが調査に参加しました：Upsource、Crucible、GitLab、Phabricator、Review Board、Kallitheaなど。 残念ながら、それらの間で理想的なツールは見つかりませんでした。



それにもかかわらず、CrucibleをGitPHPと並行して使用し、これら2つのツールの作業を1年間比較しました。 Crucibleは以前のプロジェクトで多くのモバイル開発者によって使用され、肯定的なフィードバックを提供しました。 彼はJiraとの最高の統合の1つを持っていましたが、これは驚くことではありません-彼もAtlassianによって作られています。



判明した主なCrucibleの問題はパフォーマンスです。 いくつかの機能を無効にして、機能を大幅に削減する必要さえありました。



開発者が推奨する異なるハードウェア、異なる最適化を試しましたが、何も達成しませんでした。 このツールから絞り出した最速の処理は、プッシュ後にツールにコードが表示される10分前でした。 また、いくつかのタスクの場合、依存関係は明確ではなく、数時間待つ必要がありました。 リポジトリとコミットの数を増やした後、速度は非線形に低下しました。 機能の開発と配信のダイナミクスにとって、これは適切ではありませんでした。



Crucibleが内部で構築および保存し、差分、ログ、および非難ブロックを表示するための基礎となるインデックスは、非常にゆっくりと構築されます。 さまざまなデータベースエンジンも試しました。 時々、何らかの未知の理由で、クルーシブルはジラを「中断」し始めました。 両方のシステムを再起動することで処理されました。



結局、GitPHPも何倍も高速に動作することがわかりました。モバイル開発者の要求に応じて、多くのウィッシュリストを追加することができました。Crucibleには多くの問題があります。 したがって、Crucibleで1年間遊んだ後、モバイル開発者にもGitPHPを実装するという強い意思決定を行いました。



現在、このツールはすべての部門の標準として当社で使用されています。 そして、Gerritで遊んだユーザーはこのツールを使用し、モバイル開発者、PHP開発者、およびレイアウトデザイナーを持つJS開発者、一般的にはすべてすべてを使用します。

コデイソク

もちろん、GitPHPの使用を開始して以来、大量の水が流れており、元のツールをほとんど認識できませんでした。 彼は、新しい機能、新しいデザイン、多くの追加機能、最適化、改善を受けました。









JiraとCrowdだけでなく、たとえばRedmineなど、いくつかの認証方法を追加しました。 構文の強調表示を変更し、サイドバイサイドモードを完全に書き直しました。 Gitosisを取り除き、リポジトリ、ユーザー、およびWebインターフェイスを介したそれらのアクセスの管理を実装しました-簡単で便利です（ SashaとZhenya 、ありがとう）。 ファイル（ Sasha 、ありがとう）、拡張子、diffの変更、レビュー用のフィルターを追加しました。 すべてをドッカーで包むことで楽器のインストールを簡単にしました。 デザインを完全に変更しました。 まあ、コードレビューを行うことの可能性を忘れないでください。コードレビューも進化し、はるかに便利になりました。



一般的に、このツールは完全に異なるものになったため、新しい名前をCodeisokと名付けました 。 「ok from code」と表示され、コードがすべて正常であることを意味します。



この表現は社内のミームであり、ダイアログで使用されます。



「タスクを確認してください。」

-見た、codeisok'nul！



そして本日、 Codeisokがオープンソースコミュニティで利用可能になったことをお知らせいたします。 このツールはすでにBadoo以外のいくつかのプロジェクトで機能しており、肯定的なレビューがあります（ wetrend.comやturbocontract.ruなど ）。 あなたもそれを気に入って、役に立つことを願っています。 私たちは、改善とプルリクエストを喜んで受け入れます-私たちは常にオープンソースツールの開発を手伝ってくれる人たちに喜んでいます。



また、この機会を利用して、プロジェクトの開発と改善にご協力いただいたすべての方々に深く感謝いたします。 みんなありがとう！ あなたは信じられないほどクールです！



ニキル・ヴァーマ

スタス・イグナテンコフ

アレクサンダー・イズマイロフ

アントン・ドヴガル

ユーリ・ナスレッディノフ

ニコライ・クラピブニー

コンスタンチン・ジュイン

ミロス・ポポビッチ

アレクサンダー・トレガー

エフゲニー・マクロフ

デニス・コレネフスキー

パベル・マトリギン

アレクサンダー・グリシン

ローマン・ラザレフ

アレクサンダー・オビヤンキン



信頼できるコードで！

イリヤ・アジェエフ、バドゥ