PullRequest

ビズリーチにおける開発フローについて

株式会社ビズリーチ

スタンバイ事業部

マネージャ兼チーフエンジニア

西山 はじめ

アジェンダ

  • はじめに
  • Pull Request を出すまで
  • Pull Request 作成
  • レビュー
  • マージ
  • 本番へデプロイ

Profile

  • 西山はじめ
    • 株式会社ビズリーチ
      • スタンバイ事業部マネージャ兼チーフエンジニア
      • 2011年9月入社
      • ビズリーチ事業部、研究開発を経てスタンバイ事業部
      • 前職はSIer
      • java, scala, js, coffee-script, python, C#
    • ​github: hajimeni
    • twitter: @hajimen
  • 株式会社ビズリーチ
  • サービス

Github使ってます。

昔は使っていなかった。

Subversion -> Git -> codebreak; -> github

先月リリース

求人領域に特化した検索サービス「スタンバイ」

今日はスタンバイでの開発について

お話します。

開発メンバー30人

(2015年6月時点)

  • 複数チームで構成

    • ​1チーム 5 〜10 人

  • 各チームでリリースするシステムが違う

  • チームは違ってもフローは同じ

PullRequestを出すまで

ブランチの作成

Git-Flowを少し簡易化したフロー

  • master ブランチ
    • リリース履歴
  • develop ブランチ
    • 開発ブランチ。基本的にFeatureBranchはここから作成
  • topic ブランチ
    • チケット単位(機能単位)で作成。
    • JIRAを利用しているのでJIRAチケット単位
  • release ブランチ
    • リリース時に一時的に作成。
    • master にマージされたら消す

JIRAチケット単位でブランチ作成&PullRequest

これ1つ1つで

ブランチ作成

ブランチ名

命名規則: JIRAチケット番号_単語

Pull Request 作成時

  • 作業時間が長い場合
    • タイミング
      • ​First Commit時に作成
    • Title:
      • ​[WIP] ${JIRA_ISSUE_NO} PRの内容
    • ​Body
      • ​チェックボックスいれると便利。
    • ​※完成時に[WIP]を外す
      • ​​​Assigneeにレビュアーを指定する
  • 作業時間が短い場合
    • タイミング
      • ​完成時に作成
    • Title:
      • ​${JIRA_ISSUE_NO} PRの内容
    • ​​​Assigneeにレビュアーを指定する

Text

Title

レビュアー

Slackでレビューをお願いする。

レビュアーが忙しくても忘れない為に

Github Checker (Chrome Extention)

AssignされているPR一覧がわかる

レビュー

その前に・・・

何かのマーク・・・

PullRequestのBuild & Test

commit status を表示

https://github.com/blog/1227-commit-status-api

  • CircleCI、TravisCI、Jenkinsなどで、PullRequestに対してビルドやテストの実行を行うことができる。
  • テストが通ったものはチェックマークがつくので、マージの判断もできる。

 

  • ビズリーチでは、諸々あってJenkinsの "Pull Request Builder Plugin" を使っている。

Pull Requestにコメント

レビュアー

  • 基本的にチーフエンジニア、リードエンジニアが行う
  • チェックポイント
    • 仕様、設計通りに実装されているか?
      • 仕様はJIRA
    • おかしいコードを書いていないか?
      • コードレビュー

ローカルにcheckoutして確認する

  • オンライン(Github上)で "仕様通り動くかどうか"、"デザインが崩れていないか"、"コピペコードを作っていないか(←)"を確認するのは難しい。
  • デザインなどは、検証環境に載せて確認することもあるが、ローカル開発環境でテストや実行して確認する。
  • コードそのものの指摘はGithub上だけで完結させる "こともある" 

マージ

  • 差し戻す場合は、assigneeを作成者に戻す。
  • OKな場合はマージする。

マージ先は基本的にdevelop

  • develop: Staging用
  • master: 本番デプロイ用

デプロイ

まずはStaging環境で

  • いきなり本番にはDeployしません。
  • Staging環境による動作検証。
  • QAチームによる品質確認、サイトオーナーによるリリース判断、他チームとの連携 etc....
  • 諸々クリアしてから本番リリース
  • 予めリリース日を設定することもある。

ある日のビルド風景(Staging)

ブランチ指定でStaingに作った機能を

のせてみる

(※指定しない場合は develop )

Jenkins 起動

終わったら

教えてくれる

Hubot

GitHubが作成したBotツール

https://hubot.github.com/

ChatOps

メッセージ →

← イベントの通知

遊びも

nanapiさんの script いれたり

 http://blog.nanapi.co.jp/tech/2014/07/24/nanapi_chatops/

画像で癒されたり

監視の通知もSlackに

本番デプロイ手順

develop -> master に PR

SlackからPR作成

コマンド

prepare release ${target} ${version}

  • develop から リリースブランチが作成される
    • ブランチ名(ex.):  v1.2.3
  • リリースブランチから master に PullRequest が作成される。
    • Bodyには対象バージョンでリリース予定のチケット一覧が表示される。
  • staging 環境に リリースブランチからdeployされる。

定型的な手順、操作は

hubot さんにお任せ

リリース用 Pull Request

  • JIRAのリリース予定チケットとすり合わせる
  • Staging環境で動作の確認をする
  • 確認したらチェックボックスにチェックを入れる

マージする

ようやくリリース

Slack で release コマンド

コマンド

release ${target} ${version}

ScreenShot撮れませんでした。

すいません・・・

  • リリースブランチをmasterにマージ
  • master ブランチから本番に deploy
    • 実際はjenkinsで実行している。
  • リリースタグの作成
  • リリース通知(slack)
    • 最近メールでしっかりした文章が欲しいと言われてる・・・

定型的な手順、操作は

hubot (ry

実はまだ完全にはできていない・・・

手動でリリースも

周辺ツールまとめ

BizReachでは

ほぼ毎日勉強会を開催しています。

http://d-cube.connpass.com/

BizReachでは

ハッカー(エンジニア)

募集中です!!

ご静聴

ありがとうございました

bizreach-pullrequest

By hajimeni

bizreach-pullrequest

  • 1,384