nanapi ignitionチームの開発フローとその構築
DESCRIPTION
【nanapi x はてな】はてなとnanapiの開発フロー 資料TRANSCRIPT
nanapi IGNITIONチームの 開発フローとその構築
株式会社nanapi 遠山 晃(@Vexus2)
自己紹介• 遠山 晃 / @vexus2
• サーバサイドエンジニア
• 趣味はPhpStorm
• 継続的インテグレーション、自動化周りが 得意分野
Our Service
nanapi
• 生活の知恵が集まるサイトhttp://nanapi.jp/
• 様々なハウツーを提供するサービスとしてリリース
• 2009年9月1日リリース
• 月間2500万UU
answer
• 即レスコミュニケーションアプリhttp://answer.jp/
• 5分以内のコメントが84%以上
• 40万コメント/day
• iOS版2013年12月リリース
• Android版2014年5月リリース
IGNITION
• http://ignition.co/
• Your everyday source for inspiration and motivation
• 2014年4月リリース
今日話すこと
IGNITIONチームにおける開発フロー チームに適切な開発フローをどう選定するか
今日話すこと
IGNITIONチームにおける開発フロー チームに適切な開発フローをどう選定するか
今日話さないことPhpStormのこと
開発フロー
開発体制
ディレクター 1人
編集者 1人
エンジニア 2人
デザイナ 1人
開発の流れ
チーム内外から起案でタスク発生
↓ スクラムでタスク化
↓ ＼開発／
↓ リリース → ディレクタ確認
スクラム
物理カンバンを廃止
• 付箋とIssuesとの二重管理になってしまった
• イテレーション振り返りのたびに物理カンバンの移動が面倒
• ログとして残すためにはアナログ管理は辛い
物理カンバンの代替
Pivotal Tracker導入• 各チケットでの優先度付けが楽/優先度順に並ぶ
• チケットのフローがシンプル(Unstarted/Started/Finished/Deliverd/Accepted/Rejected)
• Slackなど外部コミュニケーションツールとの連携が楽
• GitHubとの連携もそこそこ
• (改めて考えてみるとPivotalTrackerじゃなきゃだめな理由は特にない)
朝会は自席の モニタの前で
開発
基本はGitHub Flowに則る
• masterブランチは常にリリース可能に保つ
• masterへの取り込む際は常にfeatureブランチからのPull Requestを経由させる
• エンジニア・デザイナ問わずコードレビューに参加
陥りがちな罠
例外はある程度設けておく• 「○○さんが居ないのでコードレビューする人がいないのでリリースできない」
• →テストを書いてあるならリリースしてもOK (後でリファクタ可能なので)
• →CSSやHTML数行程度の見栄え修正であればそのままリリースOK
• 場合によってはmasterへの直PUSHも可
例外はある程度設けておく• 「○○さんが居ないのでコードレビューする人がいないのでリリースできない」
• →テストを書いてあるならリリースしてもOK (後でリファクタ可能なので)
• →CSSやHTML数行程度の見栄え修正であればそのままリリースOK
• 場合によってはmasterへの直PUSHも可
型にハマりすぎるあまり 開発効率が落ちるのは✕
継続的インテグレーション
PUSH
PUSH
Trigger
PUSH
Trigger
Trigger
PUSH
TriggerDeploy
Trigger
PUSH
TriggerDeploy
NotificationTrigger
なぜCircle CIを使うか
• スペック的にCircleCI > TravisCI
• Bundle Installとかで決定的な速度差
• SSH Access可なのでCI環境内にSSHで入れる
• ドハマり時の調査やデバッグが捗る
テストが落ちたらSlackにMentionを付けて通知
？
Jenkinsは使わない• カスタマイズ性が高いがメンテコストも高い
• メンテナが固定化されて各ジョブが秘伝のタレ化し、Jenkins職人(通称Jenkinsおじさん)が発生する
• デベロッパープロダクティビティ的なチームがメンテし続けれるなら良いかも
• IGNITIONは一切使っていない nanapi側もJenkinsを使わなくする予定
デプロイ
Pull Requestを経由してリリース
Masterへのマージで自動デプロイ
Slack上からHubot経由で手動デプロイ
リリースは全てCircleCI経由
開発フロー構築で 気をつけていること
あまり欲張り過ぎない
• 高機能過ぎるツールや煩雑なフローをチームに根付かせるのは大変
• チーム自体の成熟度を客観的に見てツールを選定する
IGNITIONの場合
グローバルスタンダードを重視
• 海外向けのメディアサービスなので、システム側も全てグローバル化
• 海外を含めてデファクトスタンダードとなっているものをそれぞれ選択
• 日本だけで流行っている、ようなものは選択しなかった
http://bit.ly/1onjmaL
社内のエヴァン ジェリストになる
新規ツール導入後あるある
• ツールを導入したけどみんなが使ってくれない
• 結果すぐ使わなくなってしまった
• 「想定した使い方をみんなしてくれない。うちのチームには向いていなかった」
新規ツール導入後あるある
• ツールを導入したけどみんなが使ってくれない
• 結果すぐ使わなくなってしまった
• 「想定した使い方をみんなしてくれない。うちのチームには向いていなかった」
「明日から○○使うからみんな使ってね」
では絶対に根付かない
nanapiの場合
誰よりもそのツールを使い、チーム/社内に伝播させる
モダンな環境を求め続ける
• アーリーアダプターになる必要はないが、アーリーマジョリティではいるべき
• 流行っていたりデファクトになりつつあるものをキャッチアップする仕組みを自分なりに作る
自分が追いかけて おきたい情報を tagで登録
[PR]
nanapiではエンジニアを募集中です！
(非公式ですが)こんな取り組みやってます
nanapiのpodcast “nanapod”
• http://nanapod.kozyty.com/http://goo.gl/zBNNjp
• テックな内容から社内のことまで色々話します
• 毎週配信予定！外部ゲスト歓迎！
• iTunesのPodcastでも配信中
Thank You!