継続的インテグレーションを行うときにコードレビューを行うタイミング

継続的インテグレーション環境に切り替えようとしていますが、コードレビューをいつ行うべきかはわかりません。継続的インテグレーションについて読んだことから、1日に何度もコードをチェックインしようとしているはずです。これは、まだ完全ではない機能を意味していると思います。

質問は、コードレビューをいつ行うかです。

コードをチェックインする前にそれを行うことはできません。1日あたり複数のチェックインは言うまでもなく、毎日のチェックインを実行できないプロセスが遅くなるためです。

また、チェックインしているコードがコンパイルされるだけで機能が完全ではない場合、ほとんどのコードレビューは機能の完成時に最もよく行われるため、コードレビューを行うことは無意味です。これは、機能が完了したときにコードレビューを行う必要があることを意味しますが、その未レビューのコードはリポジトリに入りますか？

IMO、メインラインが最高品質のコードのみを持つように、メインラインに公開される前にコードを確認する必要があります。

OTOH、「CIテストの自動化が実行されていない場合、なぜわざわざ検討するのですか？」という良い点を挙げることができるので、おそらくCIサーバーが構築し、テストするプライベートブランチを各開発者に提供するのが最善でしょう。この方法では、最初にコミットしてそこにプッシュし、合格するとレビューを取得し、メインラインにマージします（CIサーバーを介して別の実行が行われます）。

機能が完全ではないコードを必ず確認して、将来の機能の足場が整っていること、または少なくとも将来の機能の実装を妨げるものが何も置かれていないことを確認する必要があります。

また、コードレビューを遅くしたり同期したりする必要はありません。gerritやreviewboardなどのツールを使用すると、コードレビューを非同期でかなり痛みを伴わないようにできます。

（完全開示：以前はコードレビューツールであるCode CollaboratorのメーカーであるSmartBearで働いていました）

ペアプログラミングを設定しますか？

プロセスを拡張したり、別のステップを導入したりせずに、入力中のすべてのコードがレビューされます。

継続的配信の著者からの抜粋は次のとおりです。

Jez Humbleは次のように書いています。

現在、このトピックに関するブログ記事を書いています。短い答えはこれです：

• コードをレビューする最良の方法は、ペアプログラミングを使用することです
• 正式なレビュープロセスで、たとえば別のブランチを作成して-メインラインへのマージをゲートすることは悪い考えです。これにより、継続的な統合が妨げられます（悪い変更のリスクを減らす最良の方法です。これは、あなたが本当に達成しようとしているものです）。
• Gerritは素晴らしいツールだと思いますが、チェックイン後に使用する必要があります（実際、そのように設計されています）。上級開発者の仕事の一部は、すべてのチェックインを確認することです。たとえば、フィードを購読できます。

要約すると、コードレビューは良いです。ペアプログラミングとコミットのレビューを通じて、継続的にそれを行う必要があります。上級開発者が悪いコミットを見つけた場合、問題を解決するためにコミットした人とペアを組む必要があります。

正式なレビューでメインラインへのマージをゲーティングするのは良くありません。また、機能ブランチが悪いのと同じ理由で、そうするためのブランチを作成するのは非常に悪いです。

おかげで、

ジェズ

元のリンク：https : //groups.google.com/forum/#!msg / continuousdelivery / LIJ1nva9Oas / y3sAaMtibGAJ

それが最善の方法であるかどうかはわかりません...しかし、私たちはそれをどのように行うかを説明します。1人または複数の開発者が特定のブランチで作業し、他の方法では発生しなかったマージでの時間の浪費を避けるために、できるだけ頻繁にコードをコミットします。コードの準備ができたときにのみ、コードがヘッドにコミットされます。これがコミットとブランチ/ヘッドのことです。

コードレビューに関しては、Sonarを継続的インテグレーションツール（およびSonarと対話するためのMaven / Jenkins）を使用して、毎朝新しいテスト結果、コードカバレッジ、および自動コードレビューを提供します（ビルドは毎晩行われます）開発者は、毎朝最大1時間をかけて問題/コードのにおいを修正できます。各開発者は、作成している機能に対して責任を負います（誇りに思っています！）。今、それは潜在的な技術的/アーキテクチャ上の問題を見つけるのに最適な自動コードレビューですが、より重要なことは、これらの新しい実装された機能がビジネスが望んでいることを適切に行っているかどうかをテストすることです

そのために、統合テストとピアコードレビューの2つがあります。統合テストは、新しいコードが既存のコードを壊さないことを合理的に確信するのに役立ちます。ピアコードレビューについては、金曜日の午後に行っています。これは、それを行うためのもう少しリラックスした時間です:-)各開発者は、作業していないブランチに割り当てられ、最初に新しい機能を実行し、次に何が行われたかを確認します。彼の最も重要な仕事は、新しいコードが要件を前提として期待どおりに動作し、独自の「ルール」を破らないこと（そのためではなく、このオブジェクトを使用する）、読みやすく、それができることを確認することです簡単な拡張。

したがって、自動レビューと「人間」の2つのコードレビューがあり、レビューされていないコードをHEADブランチにコミットしないようにしています。さて...さまざまな理由で時々起こります。完璧とはほど遠いですが、品質とコストのバランスを保つように努めています（時間！）

@pjzも良い答えを提供し、彼はコードレビューツールに言及しています。私は一度も使用したことがないので、それについては何も言えません... すでにJIRAを使用しているので、以前はCrucibleで作業したいと思っていましたが。

役立つ主なコンセプトは、「ステージング」エリアのコンセプトだと思います。

はい、壊れたコードをチェックインしたくありません。ただし、コードを頻繁にチェックインする必要もあります。これは完璧を意味しますか？;）いいえ。複数の領域とgitのようなDVCSを使用するだけです。
このようにして、テストがパスするまでテストおよび開発中に変更を（ローカルで）頻繁にコミットします。次に、コードレビューのためにステージングエリアにプッシュします。

その後、ステージングから、ブラウザーテストやユーザーテストなどの他のQAの取り組みにプッシュする必要があります。最後に、ボリュームテストエリアに移動し、最後に本番環境に移動できます。

また、メインブランチで作業している人や、すべての作業に個々のブランチを使用している人など、ワークフローもあります。

継続的な統合自体も、複数のレベルで発生する可能性があります。「テストに合格するまで」開発者のマシンにローカルにすることができます。また、コードが渡されるステージング領域とqa領域にも配置できます。

コードレビューと継続的インテグレーションを分離します！

なぜ組み合わせたのですか？

リポジトリにはgit flowを使用し、developブランチへのマージに関してはコードレビューを行います。

開発中のものはすべて完全で、展開可能であり、コードレビューされています。

また、開発ブランチおよびマスターブランチ用にCIをセットアップしています。

これを自然に行うには、本当に本当にあなたがDVCS（例：水銀、git）が必要だと思います。CVCSを使用する場合、ブランチが必要になり、マージする地獄のない神に希望があります。

DVCSを使用する場合、コードがCIサーバーに到達する前にすでにレビューされているように、統合プロセスを階層化できます。DVCSがない場合は、コードレビュー担当者が変更を送信する前に各開発者のマシンでコードを確認しない限り、コードは確認前にCIサーバーに届きます。

それを行う最初の方法は、特に個人用リポジトリ（bitbucket、github、rhodecodeなど）の公開に役立つリポジトリ管理ソフトウェアがない場合、階層統合ロールを使用することです。次の図では、副官に開発者の作業をレビューさせ、独裁者を主なインテグレーターとして副官が作業をマージする方法をレビューさせることができます。

リポジトリ管理ソフトウェアを使用している場合の別の方法は、次のようなワークフローを使用することです。

リポジトリ管理ソフトウェアは、通常、リポジトリにアクティビティがある場合（電子メール、rssなど）に通知を送信するのに役立ち、プルリクエストを許可します。プルリクエストは通常​​、人々が会話に参加してコードを統合するため、プルレビュー中にコードレビューが有機的に行われます。このパブリックプルリクエストを例として取り上げます。統合マネージャは、実際にコードの必要性を修正する場合、コードは祝福されたリポジトリ（別名「中央リポジトリ」）に到着することを可能にすることはできません。

最も重要なことは、DVCSで集中型ワークフローを引き続きサポートできることです。必要ない場合は、別の派手で素晴らしいワークフローを用意する必要はありません... コードレビューセッションが完了したら、変更をdevリポジトリからCIリポジトリにプッシュする権限を誰かに与えます。

PS：画像のクレジットはgit-scm.comにあります

なぜ複数のリポジトリがないのですか？1つは「毎日」の作業、継続的な統合サーバーの駆動、すべての単体テストと統合テストの実行によるきついフィードバックループの取得、もう1つは「安定」な作業のコミットです。

変更がシステムを移動する際のパスに応じて、これはやや複雑なソリューションになる可能性があり、GitやMercurial Queuesなどのツールを使用するときに最適に機能する可能性があります（注意：どちらも怒りで使用していません）しかし、多くの組織が同様のことをしています。

これは、機能が完了したときにコードレビューを行う必要があることを意味しますが、その未レビューのコードはリポジトリに入りますか？

少なくとも3つのプロジェクトでそれが行われ、継続的インテグレーションを集中的に使用してきた方法はかなり上であり、私の記憶によればそれは魅力のように機能しました。この手法は、コミット後コードレビューと呼ばれます。詳細に興味がある場合は、この用語をウェブで検索してください。

• ^{一方、プロジェクトでCI を使用してプリコミットコードレビューを「結婚」しようとした唯一のケースは、かなり苦痛でした。まあ、物事が100％スムーズに進んだときは問題ありませんでしたが、まれな中断（メインレビューアとバックアップレビュアーが両方とも数時間利用できなかったときなど）でさえ、顕著なストレスになりました。また、チームの士気がやや低下していることに気づきました-対立が少なすぎました。}

まず、「継続的統合」の概念を明確にする必要があります。従来の開発方法では、継続的な統合とは、ソースコードリポジトリを毎日統合および構築できることを意味し、「統合地獄」の落とし穴を回避します。コードレビューは、コーディングとユニットテストの期間の間に常にあります。ブランチにマージするコードがエラーなしでコンパイルできることを保証する必要があります。インターフェイスの一貫性とコンパイルエラーの処理が難しいため、機能の一部がブランチにマージされる状況はほとんどありません。

エクストリームプログラミングプロセスでは、継続的インテグレーションが一般的です。テスト駆動開発では、ペアプログラミングが追加されます。これは、コードレビュープロセスの実際の一部であり、継続的な統合を簡単に実装できます。エクストリームプログラミング自体は、継続的なコードレビューと統合プロセスです。コードレビューはどこにでも存在します。

一部のオープンソースコミュニティでは、コードレビューは、コードがブランチにマージされる直前に実行されます。コードレビューを行い、コードをメインブランチにマージできるかどうかを判断するのは、常にこのチームの最も経験豊富な人々です。このように、継続的インテグレーションの期間は少し長くなりますが、コード品質は少し良くなります。

質問に戻ります。コードのレビューを行うタイミングについての標準的な答えはありません。また、元の開発プロセスと継続的インテグレーションの実際の実装に依存します。