1.
Adtech College #7
GitHubを中心とした
開発フロー
2014年12月4日
山田直行
アドテクスタジオ Smalgo

2.
目次
❖ Smalgoでのタスク管理システムとしてのGitHub
❖ Pull Requestとレビュー
❖ Jenkinsでの自動テスト・ビルド
❖ Slackとの連携
❖ 開発/リリースフローとgitのブランチ

3.
Smalgoについて
❖ Smalgo
❖ スマホ向け成果報酬課金DSP
❖ RTBと第三者配信
❖ リリース回数
❖ 平均3.5回／週(106回÷30週)
❖ Pull Request
❖ 平均5個／日(502個÷86日)

4.
SmalgoのGitHubレポジトリ
❖ https://github.com/xxxxxxxx/xxxxxxxx
❖ 配信、管理画面、インフラまで全てこの1つのレポジトリに集約

5.
Issue
❖ 開発タスク・バグ報告などは
全てここに上げる
❖ [PACE] などのようにタイトル
にPrefixをつけるルール
❖ ラベル・担当者・マイルストー
ンとひもづける

6.
Milestones
❖ タイトル・説明・期限の3つを
設定可能
❖ Issueとひもづける
❖ 大きな粒度の開発項目
❖ 数日～2週間で取り組む大きさ

7.
HuBoardを使って全体管理
❖ https://huboard.com

8.
Wiki
❖ GitHubのWikiはそれ自体がgit
レポジトリになっている
❖ Markdownで記述
❖ Issueとは違って、ずっと使い
続けるような情報をストックす
る場所
❖ プロジェクトのイントロダクショ
ン・開発環境構築方法・運用
マニュアル・仕様の整理など

9.
Pull Request
❖ Issueに対応する開発ができた
らそれをPull Requestとして
上げる
❖ レビューラベル「レビュー依頼」
「レビュー中」「レビュー完了
❖ smalgo-lotto
（くじでレビュワーを決める）

10.
レビュー・マージ
❖ レビューはなるべく偏らないよ
うにしていて、詳しくない場所
でもレビュワーを担当する
❖ 基本レビュワーは1人だが、重要
な箇所は複数人が見る
❖ LGTM(Looks Good To Me)サ
インをもらい、Pull Requestを
出した本人がマージする
❖ masterブランチまたはfeature/
*ブランチへのPull Request。
masterにマージされたものは
”リリースready”

11.
Jenkinsでの自動ビルド
❖ マージをHookしてビルドが走る
❖ Pull Request BuilderでPull RequestをHookしてビルドもしている
→テストが通らないものはマージしない

12.
Slackとの連携
❖ 通常のチャットのチャンネルとは別にnotification用チャンネルが
あり、GitHubとJenkinsの通知を流している

13.
開発・リリースフロー
❖ masterブランチまたはfeature/*ブランチに向けたPull Requestが
マージされると、Jenkinsでビルドが走る
❖ ビルドが完了すると、development環境にデプロイ可能なパッケー
ジ(arfifact)がzipファイルにまとめられてS3にアップロードされる
❖ fabricコマンドでホスト別・ロール別にデプロイ

14.
gitのブランチ
master release
RC-xxxx
feature/xxxx
Before After
master
2014-xxxx-xxxx
2014-xxxx-xxxx
2014-xxxx-xxxx
2014-xxxx-xxxx
masterブランチ＋tagのみmaster=開発用、かつリリースしてよいもの!
release=リリース済みのもの
feature/xxxx

15.
stagingへのリリース手順
❖ https://github.com/xxxxxxxxxxxx/wiki/
Release手順
❖ Jenkinsの「stagingビルド」ジョブを実行
↓
❖ GitHub上にリリース用Issueが作成され、Pre-release
フラグでreleaseが自動で作成される
↓
❖ リリース担当者はリリース内容を確認し、リリー
ス手順を整理して、staging確認内容を全体に通
知する
↓
❖ stagingビルドが終わるとSlackに通知される

16.
productionへのリリース手順
❖ stagingにデプロイして確認を行う
↓
❖ Jenkinsで「productionビルド」ジョブを
実行
↓
❖ productionビルドが終わるとSlackに通知
される
↓
❖ production環境にデプロイする
↓
❖ リリース用IssueをCloseしてリリース完了

17.
リリースごとのリリースノート作成を自動化し、
各リリースをgitのtag, GitHubのrelease機能と連動させている
❖ リリースノートはマージされたPull
Requestのリスト
❖ 各Pull RequestとリリースIssueへ
のリンクを付ける
❖ datetimeをベースとしたtag名
❖ 緑はreleased(リリース済み)、オレ
ンジはPre-release（staging止ま
り）
❖ リリースを自動更新するRakeタスク
これをJenkinsのジョブ内で実行
https://github.com/xxxxxxxxxxxxx