シップ / ショー / アスク

プルリクエストで継続的インテグレーションを行うにはどうすればよいですか？

プルリクエストは、多くのソフトウェアチームで広く採用されています。プルリクエストを好む人もいれば、ブランチを作成せず、チームが常に変更をまとめる継続的インテグレーションの時代を懐かしむ人もいます。

いくつかの点で、プルリクエストはゲームチェンジャーです。コードホスティングツールは素晴らしいコードレビュー機能を提供しています。テストの実行やコード品質のチェックから、本格的なプレビュー環境のデプロイまで、プルリクエストで実行できるサービスを提供するSaaSプロバイダーはたくさんあります。

しかし、コードを貢献する主要な方法としてプルリクエストを採用したことで、問題が発生しました。継続的インテグレーションを行っていた頃の「すぐにシップできる」というメンタリティが失われつつあります。進行中の機能は、統合を遅らせることで邪魔にならないようにするため、継続的インテグレーションが対処しようとした低頻度統合の落とし穴に陥ってしまいます。

プルリクエストが放置されて古くなってしまったり、レビューを待っている間に何に取り組めばいいのか分からなくなったりすることがあります。「せっかくここまできたのだから、ついでにこれもやってしまおう」と考えて、プルリクエストが肥大化してしまうこともあります。

また、レビューしなければならないプルリクエストの数が多すぎて、コードについて話し合うのをやめてしまいます。注意を払うのをやめ、「承認」をクリックするか、「問題ありません」と言うだけになってしまいます。

シップ / ショー / アスクの紹介

チームで使用してきたソフトウェアブランチのアプローチがあります。これは非常にうまく機能したので、皆さんと共有したいと思います。

変更を加えるたびに、シップ、ショー、アスクの3つのオプションから1つを選択します。

シップ

図1：変更はメインラインに直接反映されます

これは、継続的インテグレーションに最も近い感覚です。変更を加えたい場合は、メインラインで直接変更します。この場合、誰かが変更を本番環境に適用するのを待つ必要はありません。コードレビューを求めているわけではありません。いつもの継続的インテグレーションの手法で安全に変更を加えるだけです。

うまくいく場合

• 確立されたパターンを使用して機能を追加しました
• 簡単なバグを修正しました
• ドキュメントを更新しました
• あなたのフィードバックに基づいてコードを改善しました

ショー

図2：フィードバックのためにPRを開きますが、すぐにマージします

これは、継続的インテグレーションの考え方を取り入れながら、プルリクエストのすべてのメリットを活用するところです。ブランチで変更を行い、プルリクエストを開き、誰かの承認を待たずにマージします。自動チェック（テスト、コードカバレッジ、プレビュー環境など）を待つ必要がありますが、変更を本番環境に適用するために誰かのフィードバックを待つ必要はありません。

そうすることで、変更を迅速に本番環境に適用しながら、フィードバックと会話の場を設けることができます。チームはプルリクエストの通知を受け取り、行った内容を確認できます。アプローチやコードについてフィードバックを提供したり、質問したり、行ったことから学ぶことができます。

うまくいく場合

• このコードをどのように改善できるか、フィードバックをいただければ幸いです
• この新しいアプローチまたはパターンをご覧ください
• Xをリファクタリングしたので、今はこのようになっています
• 興味深いバグですね！どのように修正したかをご覧ください。

アスク

図3：フィードバックのためにPRを開き、マージする前に待ちます

ここで一時停止します。ブランチで変更を行い、プルリクエストを開き、マージする前にフィードバックを待ちます。正しいアプローチを取ったかどうか分からない場合や、コードに満足していないが、どのように改善すればいいのか分からない場合があります。実験を行って、人々の意見を聞きたい場合もあるでしょう。

最新のコードレビューツールは、この種の会話に最適な場を提供し、チーム全体でプルリクエストを見て議論することもできます。

うまくいく場合

• これはうまくいくでしょうか？
• この新しいアプローチについてどう思いますか？
• これを改善するために助けが必要です
• 今日はこれで終わりです。明日はマージします

ルール

• コードレビュー、つまり「承認」は、プルリクエストをマージするための要件ではありません。
• 各自が自分のプルリクエストをマージできます。こうすることで、変更が「ショー」なのか「アスク」なのかを自分でコントロールし、いつ本番環境に適用するかを決定できます。
• メインラインをリリース可能な状態に保つのに役立つ、優れた継続的インテグレーションと継続的デリバリーのすべてのテクニックを使用する必要があります。フィーチャートグルを例に挙げましょう。
• ブランチは長く存続させてはならず、メインラインに頻繁にリベースする必要があります。

会話

プルリクエストは変更について話し合うのに便利な方法ですが、落とし穴もあります。最も魅力的なアンチパターンは、プルリクエストが他の会話方法に取って代わることができるという考えです。

ブランチのよくある問題の1つは、議論せずにアプローチを決めてしまうことです。プルリクエストが開かれる頃には、最適ではない解決策に時間が費やされています。レビュー担当者は、選択された解決策に影響を受け、代替アプローチを提案するのが難しくなります。変更セットが大きく、ブランチの存続期間が長いほど、この問題は深刻になります。作業を開始する前にチームと話し合って、より良いアイデアを得て、やり直しを避けられるようにしましょう。

プルリクエストは、ショーやアスクを行う唯一の方法ではないことを忘れないでください。電話をかけたり、誰かのデスクまで歩いて行ったりしましょう。作業を早期かつ頻繁に示しましょう。早期かつ頻繁に助けとフィードバックを求めましょう。タスクを一緒に作業しましょう。

プルリクエストを開かないことは、コードについて話し合わない理由にはなりません。チームが良いフィードバック文化を持ち、考えや学んだことについて互いに話し合うことが重要です。

バランス

3つのオプションがありますが、どれをより頻繁に選択すべきでしょうか？

状況によります。各チームには、その時々に応じた独自のバランスがあると思います。

確立されたパターンで機能を提供している場合は、「シップ」することが多くなります。チームに高い信頼があり、全員が同じ品質基準を共有している場合は、「シップ」することも多くなります。

しかし、まだお互いをよく知らない場合や、全員が新しいことをしている場合は、会話の必要性が高いため、「ショー」と「アスク」が多くなります。ジュニアエンジニアはしばしば「ショー」と「アスク」を行い、シニアエンジニアは多くの場合「シップ」しますが、時には全員が試してみるべき新しいテクニックやリファクタリングを「ショー」することがあります。

柔軟性のないチームもあります。特定の業界は厳しく規制されており、すべての変更に承認またはレビュープロセスが必要になります。これを実装するには、ブランチを作成するかどうかなど、さまざまな方法がありますが、ここでは説明しません。

チームはこのアプローチを採用すべきでしょうか？

すでにそうなっています。

チームの働き方を考えてみると、シップ/ショー/アスクのバランスが取れていることに気付くでしょう。私が見てきたほとんどのチームは、「ほとんどシップ」または「ほとんどアスク」の2つのいずれかに分類されます。

結論

では、シップ/ショー/アスクとは何でしょうか？基本的には、2つのことです

1つ目は、両方の長所を得るためのトリックです。フィードバックを待たずに自分のプルリクエストをマージし、フィードバックが来たら注意を払いましょう。

2つ目は、ブランチ戦略をより包括的で動的に見ることができる方法です。シップ/ショー/アスクは、各チームのアプローチが「常にシップ」と「常にアスク」の間のどこかに位置することを思い出させてくれます。それぞれの変更について個別に考え、「シップ、ショー、アスクのどれを行うべきか？」と自問自答することを促します。