はじめに

このページでは、フロントエンドの開発プロセスを説明し、通常のマージリクエストサイクルがどのようなものかを紹介します。フロントエンドチームの組織についてはハンドブックをご覧ください。

初めてのマージリクエストには考慮すべきことがたくさんあり、圧倒されるかもしれません。フロントエンドオンボーディングコースでは、GitLabフロントエンドに貢献する方法を学ぶための6週間の体系的なカリキュラムを提供します。

開発者のライフサイクル

ステップ1：イシューの準備

作業に取り掛かる前に、自分に割り当てられたイシューに目を通し、必要な部署がすべて関与していることを確認してください。必要に応じてコメントに目を通し、不明な点があれば、イシューに作業内容を要約したコメントを投稿し、エンジニアリングまたはプロダクトマネージャーに確認の連絡を入れてください。すべてが明確になったら、イシューに正しいワークフローラベルを貼り、マージリクエストブランチを作成します。イシューから直接作成した場合、デフォルトでイシューとマージリクエストはリンクされます。

ステップ 2: 実装を計画します

コードを書く前に、以下の質問を自問自答し、明確な答えを持ってから開発を始めましょう：

  • どのAPIデータが必要ですか？私たちのAPIですでに利用可能か、それともバックエンドに問い合わせるべきでしょうか？
    • これがGraphQLの場合、クエリの提案書を作成し、BEの担当者に確認を取ってください。
  • GitLab UI コンポーネントは使えますか？どのコンポーネントが適切で、必要な機能をすべて備えていますか？
  • GitLab プロジェクトの中に、使えそうな既存のコンポーネントやユーティリティはありますか？
  • この変更は機能フラグを立てるべきですか？
  • このコードはどのディレクトリに置くべきですか？
  • この機能の一部を再利用可能なものとして構築すべきでしょうか？もしそうなら、コードベースのどこに置くべきでしょうか？
    • 注：今のところ、これはまだ検討中ですが、vue_shared フォルダが GitLab 全体のコンポーネントのための望ましいディレクトリであることに変わりはありません。
  • どのようなテストが必要ですか？単体テストと 機能テストを考えてみましょうか？SETに指導を仰ぐべきでしょうか？それともテストを実装することに問題はないでしょうか？
  • この変更の規模は？差分（diff）はせいぜい500以上にしてください。

これらの質問すべてに答えがあれば、安心してコードを書く作業に移ることができます。

ステップ3：コードを書く

進捗状況や、計画したイシューに長期間取り組めない場合は、必ずチームに連絡してください。

サポートが必要な場合は、ブランチをプッシュしてマージリクエストをチームメイトに直接伝えるか、Slack の#frontend チャンネルで共有し、今後の進め方についてアドバイスをもらいましょう。マージリクエストに下書きマークをつけておくと、まだレビューの準備が整っていないことを明確に伝えることができます。常に恥じることなく、必要なときに助けを求めることを忘れないでください。

コードを書くときには、変更点を徹底的にテストするようにしてください。コードをテストし、期待通りに動くことを確認し、既存の動作を壊していないことを確認するのは作成者の責任です。レビュアーはその点で助けになるかもしれませんが、期待しないでください。異なるブラウザ、モバイルビューポート、予期せぬユーザーフローを必ずチェックしてください。

ステップ4：レビュー

コードをレビューに送るとき、かなりストレスがかかるかもしれません。コードレビューガイドラインに目を通して、何を期待されるかを理解することをお勧めします。最も重要なアドバイスのひとつは、シンプルなものです：

[…] レビュアーとの不必要なやりとりを避けるために、[…] 自分自身のマージリクエストのセルフレビューを行い、コードレビューガイドラインに従ってください。

小さなミスを見つけたり、レビュアーが不明な部分や疑問に思う部分にコメントを残すことができるからです。これにより、プロセスが飛躍的にスピードアップします。

ステップ 5: 検証

コードがマージされたら（おめでとうございます！）、本番環境で動作し、エラーが発生しないことを確認してください。