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ツール
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で実行している。
- リリースタグの作成
- github のリリース機能
- http://qiita.com/todogzm/items/db9f5f2cedf976379f84
- リリース通知(slack)
- 最近メールでしっかりした文章が欲しいと言われてる・・・
定型的な手順、操作は
hubot (ry
実はまだ完全にはできていない・・・
手動でリリースも
周辺ツールまとめ
- PullRequestのビルド確認
- jenkins ( https://jenkins-ci.org/ )
- PullRequest Builder Plugin
- レビューPRを忘れないために
- github checker extention( chrome )
- チャット
- Slack ( https://slack.com/ )
- ChatOps用Bot
- hubot ( https://hubot.github.com/ )
- ビルド
- jenkins
BizReachでは
ほぼ毎日勉強会を開催しています。
BizReachでは
ハッカー(エンジニア)
募集中です！！
