Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • 一般の慣習
  • master branch の利用
  • branch 名に username を入れる
  • Pull Request 重視
  • マイクロサービス開発における Git
  • Kubernetes / Docker との対応
  • GitHub Flow の採用

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発プロセス

Git の慣習

前へ開発プロセス次へポストモーテムの取り組み

最終更新 1 か月前

役に立ちましたか?

で解説されている通り、Wantedly のサービスは、各々が独自のリリース・サイクルを持つ多数のソフトウェア・コンポーネントの組み合わせによって動作しています。 それぞれにコンポーネントに対して 1 つの repository を管理しています。

一般の慣習

このセクションでは技術領域に関わらない慣習を解説します。

master branch の利用

一般には main branch を default の branch として運用することが多くなって来ていますが、 Wantedly では数多くの repository の CI 設定や自動化フローにおいて master をハードコードして利用してきました。 短期間での移行が難しいため、 2022 年 1 月現在では master branch を default で利用している repository が多数派です。

branch 名に username を入れる

GitHub Flow を採用している背景から、殆どの場合一つの branch と一人の開発者がひも付きます。 不要なコンフリクトを避けるために branch は <github-username>/<feature-name> のように命名します。

Pull Request 重視

Wantedly では伝統的に Pull Request の description をコミットメッセージよりも重視します。 コミットメッセージで深く悩まずにコミットを重ねて早めに Pull Request を作ると良いでしょう。 Pull Request の書き方は を参照してください。

マイクロサービス開発における Git

このセクションではマイクロサービスの repository 特有の慣習について解説します。 バックエンド及びフロントエンドのコンポーネントがこれに該当し、 モバイルアプリ / 社内ライブラリ / 社内ツールなどは必ずしもこのセクションで解説する慣習をとっていないことがあります。

Kubernetes / Docker との対応

マイクロサービスは下の性質を持ちます。

  • Kubernetes クラスタに Deploy される

  • 1 つの GitHub repository をもつ

  • 1 つの Kubernetes namespace (repository 名と同名)をもつ

  • 1 つの Docker image をもつ

このため一つの名前で、GitHub repository, Kubernetes namespace, 一つの microservice など複数のものを指すことがありますが、 上記の対応関係のために混乱することは殆どありません。

GitHub Flow の採用

  • master branch から topic branch を切る

  • master branch に対して pull request を作る

  • master branch が更新されるたびに本番環境に反映される

これを維持するために commit を push するたびに Docker image が作成され、master branch の更新に合わせて自動で本番環境が更新されるようになっています。

Kubernetes 概要および Wantedly における運用については を参照してください。

バックエンド及びフロントエンドでは を採用しています。 したがって下のようなスタイルの開発になっています。

技術的な詳細は を参照してください。

技術とアーキテクチャ
コードレビュー
プロダクト開発のための Kubernetes 入門
GitHub Flow
リリース・デプロイ戦略を支える技術