継続的インテグレーションを行うときにコードレビューを行うタイミング
継続的インテグレーション環境への切り替えを試みていますが、コードレビューをいつ行うかは不明です。私が継続的インテグレーションについて読んだことから、1日に何度もコードをチェックインしようとしているはずです。私は、これはまだ完成していない機能についても意味していると思います。
だから問題は、いつコードレビューをするのですか？
コードをチェックインする前にそれを行うことはできません。これは、1日あたりの複数のチェックインはもちろんのこと、毎日のチェックインを実行できないプロセスを遅くするためです。
また、チェックインするコードがコンパイルのみで機能が完全ではない場合、コードのレビューを行っても意味がありません。ほとんどのコードのレビューは、機能が完成したときに行うのが最善です。これは、機能が完了したときにコードレビューを行う必要があることを意味しますが、レビューされていないコードはリポジトリに格納されますか？
IMO、メインラインに公開される前にコードを確認して、メインラインに最高品質のコードのみが含まれるようにしてください。
OTOH、「CIテストの自動化が実行されていないかどうかを確認する必要があるのはなぜですか？」 。このようにして、最初にコミットしてそこにプッシュします。その後、合格するとレビューされ、メインラインにマージされます（そこでCIサーバーを介して別の実行が行われます）。
機能が完全ではないコードを必ずレビューして、将来の機能の足場が整っているか、少なくとも将来の機能の実装を妨げるようなものが何もないことを確認してください。
また、コードレビューは低速または同期である必要はありません-gerritやreviewboardなどのツールを使用すると、コードレビューを非同期にしてかなり苦痛なくすることができます。
（完全な開示：以前はコードレビューツールであるCode CollaboratorのメーカーであるSmartBearで働いていました）
ペアプログラミングを設定しますか？
すべてのコードは、プロセスを拡張したり、別のステップを導入したりせずに、入力中にレビューされます。
以下は、継続的デリバリー作成者からの抜粋です。
Jez Humbleは次のように書いています：
私は現在、このトピックに関するブログ投稿を書いています。短い答えはこれです：
- コードをレビューする最良の方法は、ペアプログラミングを使用することです
- 正式なレビュープロセスで、たとえば別のブランチを作成して、マージをメインラインにゲートすることはお勧めできません。これは継続的な統合を阻害します（悪い変更のリスクを減らす最善の方法であり、これは実際に達成しようとしていることです）。
- 私はGerritは素晴らしいツールだと思いますが、後でチェックインを使用する必要があります（それが実際に設計されている方法です）。上級開発者の仕事の一部は、すべてのチェックインを確認することです。たとえば、フィードを購読できます。
要約すると、コードレビューは適切です。とても良いです。私たちは、ペアプログラミングとコミットのレビューを通じて、継続的にそれを行う必要があります。上級開発者が不適切なコミットを見つけた場合は、コミットした人とペアを組んで、問題の修正を支援する必要があります。
正式なレビューでメインラインにマージをゲーティングすることは悪いことであり、それを行うためのブランチを作成することは、機能ブランチが悪いのと同じ理由で、さらに悪いことです。
おかげで、
ジェズ。
元のリンクは： https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ
それが最善の方法であるかどうかはわかりません...しかし、その方法を説明します。 1人以上の開発者が特定のブランチで作業し、できるだけ頻繁にコードをコミットします。コードの準備が整ったときにのみ、コードがヘッドにコミットされます。これで、コミットとブランチ/ヘッドの処理が完了しました。
コードレビューについては、毎朝の新鮮なテスト結果、コードカバレッジ、および自動コードレビュー（ビルド）を提供するために、継続的統合ツール（およびSonarと対話するためのMaven/Jenkins）として Sonar を使用します私たちの開発者が問題/コードの臭いを修正するために毎朝最大1時間費やすことができるように、毎晩行われます。各開発者は、自分が書いている機能に対して責任を負います（誇りに思っています！）。さて、それは自動コードレビューです。これは潜在的な技術的/アーキテクチャ上の問題を見つけるのに最適ですが、さらに重要なことは、これらの新しい実装された機能がビジネスに求めていることを適切に実行しているかどうかをテストすることです。
そのためには、統合テストとピアコードレビューの2つがあります。統合テストは、新しいコードが既存のコードを壊さないことを合理的に確信するのに役立ちます。ピアコードのレビューについては、金曜日の午後に行います。これは、少しリラックスした時間です:-)各開発者は、自分が作業していないブランチに割り当てられます。最初に新機能、次に何が行われたかを確認します。彼の最も重要な仕事は、新しいコードが期待どおりに機能することを確認することです独自の「ルール」を破らないようにします（このオブジェクトをそれは、それではなく）、読みやすく、簡単に拡張できるようにします。
したがって、2つのコードレビューがあり、1つは自動、もう1つは「人間」であり、レビューされていないコードをHEADブランチにコミットしないようにしています。さまざまな理由で発生することがあります。完璧からは程遠いですが、品質とコスト（時間！）のバランスを保つよう努めています。
@pjzも良い答えを提供しており、彼はコードレビューツールについて言及しています。私は何も使用したことがないので、それについては何も言えません...過去に [Crucible を使用するように誘惑されてきましたが、すでに [〜＃ 〜] jira [〜＃〜] 。
役立つ主なコンセプトは、「ステージング」エリアのコンセプトだと思います。
はい、壊れたコードをチェックインしたくありません。ただし、コードを頻繁にチェックインする必要もあります。これは完璧を意味しますか？ ;）いいえ。複数の領域とgitのようなDVCSを使用するだけです。
この方法で、変更をローカルで行い、テストに合格するまでテストおよび開発しながら頻繁に変更をコミットします。次に、ステージング領域にプッシュしてコードレビューを行います。
その後、ステージングから、ブラウザーテストやユーザーテストなどの他のQA作業にプッシュする必要があります。最後に、量産試験エリアに行き、最後に生産に行くことができます。
この中には、メインブランチで作業している全員やすべての作業に個別のブランチを使用しているようなワークフローもあります。
継続的な統合自体も、複数のレベルで発生する可能性があります。これは、「テストに合格するまで」、開発者のマシンのローカルである場合もあれば、ステージング領域やqa領域にある場合もあり、コードがそれらに行き渡ります。
コードのレビューと継続的な統合を切り離す！
なぜそれらを組み合わせたのですか？
リポジトリには git flow を使用し、developブランチへのマージに関してコードレビューを行います。
開発中のものはすべて完全で、デプロイ可能で、コードがレビューされています。
また、開発ブランチとマスターブランチ用にCIを設定しています。
これを自然に行うには、DVCS（Mercurial、Gitなど）が必要になると本当に本当に本当に思っています。 CVCSを使用すると、ブランチが必要になり、マージしている地獄が存在しないすべての神に期待します。
DVCSを使用する場合は、統合プロセスを階層化して、コードがCIサーバーに到達する前にコードでレビューされるようにすることができます。 DVCSがない場合でも、コードレビューアーが変更を送信する前に各開発者のマシンでコードをレビューしない限り、コードはレビューの前にCIサーバーに到着します。
これを行う最初の方法は、特に個人リポジトリ（bitbucket、github、rhodecodeなど）の公開に役立つリポジトリ管理ソフトウェアがない場合は、階層的な統合の役割を持つことです。次の図では、中尉に開発者の作業をレビューしてもらい、主任インテグレーターとして独裁者に中尉が作業をどのようにマージしたかを確認させることができます。
リポジトリ管理ソフトウェアがある場合は、次のようなワークフローを使用することもできます。
リポジトリ管理ソフトウェアは通常、リポジトリ（e-mail、rssなど）でアクティビティが発生した場合に通知を発行し、pull-requestsを許可します。プルリクエストは通常、人々に会話をさせてコードを統合させるため、コードレビューはプルリクエスト中に有機的に発生する可能性があります。例として this public pull-request を取り上げます。 統合マネージャーは、コードを修正する必要がある場合、実際にはコードをblessされたリポジトリ（別名「中央リポジトリ」）に到達させることができません。
最も重要なのは、DVCSを使用して集中型ワークフローをサポートできることです。必要がない場合は、別の素晴らしいワークフローを用意する必要はありませんが、DVCSを使用すると、中央開発リポジトリをCIから分離できます。サーバーになり、コードレビューセッションが完了したら、誰かに開発リポジトリからCIリポジトリに変更をプッシュする権限を与えます。
PS：画像のクレジットは git-scm.com に移動します
これは、機能が完了したときにコードレビューを実行する必要があることを意味しますか？
以上は、継続的インテグレーションを集中的に使用していた少なくとも3つのプロジェクトで行われた方法であり、私の記憶によれば、それは魅力のように機能しました。この方法はコミット後のコードレビューとして知られています。詳細に興味がある場合は、この用語をウェブで検索してください。
- 一方、プロジェクトでCIを使用してpre-commitコードレビューを試みようとした唯一のケースは、かなり苦痛でした。まあ100％スムーズに進んだら問題はありませんでしたが、頻繁ではない中断（メインとバックアップの両方のレビュアーが数時間利用できなくなった場合など）であっても、顕著なストレスが生じました。また、チームの士気がやや低下していることに気づきました-対立が多すぎました。
なぜ複数のリポジトリを持たないのですか？ 1つは「毎日」の作業、継続的インテグレーションサーバーの駆動、すべての単体テストと統合テストの実行によるニースのタイトなフィードバックループの取得、もう1つは「安定した」作業の場合です。この場合、コミットの頻度は低くなりますが、レビューを行う必要があります。
システム内を移動するときに変更がたどる経路によっては、これはやや複雑なソリューションになる可能性があり、GitやMercurial Queuesなどのツールを使用するときに最適に機能する可能性があります（注意：どちらも怒りで使用していない）しかし、多くの組織が同様のことをしています。