Git の慣習
技術とアーキテクチャ で解説されている通り、Wantedly のサービスは、各々が独自のリリース・サイクルを持つ多数のソフトウェア・コンポーネントの組み合わせによって動作しています。 それぞれにコンポーネントに対して 1 つの repository を管理しています。
このセクションでは技術領域に関わらない慣習を解説します。
一般には
main branch を default の branch として運用することが多くなって来ていますが、 Wantedly このでは数多くの repository の CI 設定や自動化フローにおいて master をハードコードして利用してきました。 短期間での移行が難しいため、 2022 年 1 月現在では master branch を default で利用している repository が多数派です。GitHub Flow を採用している背景から、殆どの場合一つの branch と一人の開発者がひも付きます。 不要なコンフリクトを避けるために branch は
<github-username>/<feature-name> のように命名します。Wantedly では伝統的に Pull Request の description をコミットメッセージよりも重視します。 コミットメッセージで深く悩まずにコミットを重ねて早めに Pull Request を作ると良いでしょう。 Pull Request の書き方は コードレビュー を参照してください。
このセクションではマイクロサービスの repository 特有の慣習について解説します。 バックエンド及びフロントエンドのコンポーネントがこれに該当し、 モバイルアプリ / 社内ライブラリ / 社内ツールなどは必ずしもこのセクションで解説する慣習をとっていないことがあります。
マイクロサービスは下の性質を持ちます。
- Kubernetes クラスタに Deploy される
- 1 つの GitHub repository をもつ
- 1 つの Kubernetes namespace (repository 名と同名)をもつ
- 1 つの Docker image をもつ
このため一つの名前で、GitHub repository, Kubernetes namespace, 一つの microservice など複数のものを指すことがありますが、 上記の対応関係のために混乱することは殆どありません。
- master branch から topic branch を切る
- master branch に対して pull request を作る
- master branch が更新されるたびに本番環境に反映される
これを維持するために commit を push するたびに Docker image が作成され、master branch の更新に合わせて自動で本番環境が更新されるようになっています。
最終更新 1yr ago