プルリクエスト作成
プルリクエストの質を高めることで、将来発生しうるバグの回避やバグの早期発見・改修につなげることができます。
当社ではプルリクエストの質を高め、標準化するため、プルリクエストに記載する観点を明確にし、標準的な確認項目リストを定めています。
プルリクエスト作成の際の行動指針#
プルリクエストを作成する際は、下記の観点を含めて作成します。
プルリクエストサンプルと併せて確認しましょう。
- タイトル
- 変更内容
- 変更理由
- 期待値
- エビデンス
- コーディング確認
- 動作確認
タイトル#
プルリクエストのタイトルには、対応するBacklogチケットのタイトルをコピー&ペーストします。
フロントエンド(=FE)なのかバックエンド(=BE)なのか、画面実装なのかAPI結合なのかなど、スコープが明確に伝わるタイトルにしましょう。
例
- FE/デザイン/ログイン画面
- FE/ロジック/ログインAPI結合
- BE/API/ログイン
変更内容#
修正した不具合や追加した新機能など、変更内容を説明します。
レビュー不要なソース(自動フォーマットによる差分など)がある場合はその旨も記載しましょう。
レビュー不要箇所の記載方法として、該当するソースの箇所へコメントでもOKです。
変更理由#
変更が必要になった経緯について記載します。
その際、変更によってどのようなメリットがあるのかがレビュアーに伝わる説明にしましょう。
期待値#
変更後のあるべき状態について記載します。
仕様がわかるデザインファイル(figmaなど)への参照リンクも併せて添付し、期待値が一義的に伝わるように工夫しましょう。
エビデンス#
変更内容が適切であることがわかるエビデンスとして、UI/ログの動画/キャプチャなどを添付しましょう。
コーディング確認#
観点リスト(プルリクエストサンプル参考)にもとづいて確認し、チェックボックスにチェックします。
未チェックがある場合、レビュアーはレビュー結果NGで返信することになります。
もしチェック不要な項目がある場合は「その他」で理由とともに補足しましょう。
動作確認#
観点リスト(プルリクエストサンプル参考)にもとづいて確認し、チェックボックスにチェックします。
未チェックがある場合、レビュアーはレビュー結果NGで返信することになります。
もしチェック不要な項目がある場合は「その他」で理由とともに補足しましょう。
レビュー依頼について#
一般的にレビューはエンジニアが行いますが、当社では品質確保の観点から、UI変更がある場合はデザイナーもレビューに参加します。
レビュー時点で仕様の実装不備を検出することにより、後工程でバグ検出するよりも工数の抑制が期待できます。
具体的なレビュー依頼時の作業は以下の通りです。
- GitHub
- Reviewers: デザイナー1名以上、エンジニア1名以上を設定
- Assignees: 実装者自身を設定
- Mattermost(チャット)
- レビュアーに対してGitHubリンク付きでレビュー依頼をコメント