【nanapi x はてな】はてなとnanapiの開発フロー 資料

1. nanapi IGNITIONチームの
開発フローとその構築
株式会社nanapi 遠山 晃(@Vexus2)

2. 自己紹介
• 遠山 晃 / @vexus2
• サーバサイドエンジニア
• 趣味はPhpStorm
• 継続的インテグレーション、自動化周りが
得意分野

5. Our Service

6. nanapi
• 生活の知恵が集まるサイト
http://nanapi.jp/
• 様々なハウツーを提供する
サービスとしてリリース
• 2009年9月1日リリース
• 月間2500万UU

7. answer
• 即レスコミュニケーションアプリ
http://answer.jp/
• 5分以内のコメントが84%以上
• 40万コメント/day
• iOS版2013年12月リリース
• Android版2014年5月リリース

8. IGNITION
• http://ignition.co/
• Your everyday source for
inspiration and motivation
• 2014年4月リリース

9. 今日話すこと
IGNITIONチームにおける開発フロー
チームに適切な開発フローをどう選定するか

10. 今日話すこと
IGNITIONチームにおける開発フロー
チームに適切な開発フローをどう選定するか
今日話さないこと
PhpStormのこと

11. 開発フロー

12. 開発体制
ディレクター 1人
編集者 1人
エンジニア 2人
デザイナ 1人

13. 開発の流れ
チーム内外から起案でタスク発生
↓
スクラムでタスク化
↓
＼開発／
↓
リリース → ディレクタ確認

14. スクラム

17. 物理カンバンを廃止
• 付箋とIssuesとの二重管理になってしまった
• イテレーション振り返りのたびに物理カンバンの
移動が面倒
• ログとして残すためにはアナログ管理は辛い

18. 物理カンバンの代替

20. Pivotal Tracker導入
• 各チケットでの優先度付けが楽/優先度順に並ぶ
• チケットのフローがシンプル
(Unstarted/Started/Finished/Deliverd/Accepted/Rejected)
• Slackなど外部コミュニケーションツールとの連
携が楽
• GitHubとの連携もそこそこ
• (改めて考えてみるとPivotalTrackerじゃなきゃだめな理由は特にない)

21. 朝会は自席の
モニタの前で

22. 開発

23. 基本はGitHub Flowに則る
• masterブランチは常にリリース可能に保つ
• masterへの取り込む際は常にfeatureブランチか
らのPull Requestを経由させる
• エンジニア・デザイナ問わずコードレビューに参加

24. 陥りがちな罠

25. 例外はある程度設けておく
• 「○○さんが居ないのでコードレビューする人が
いないのでリリースできない」
• →テストを書いてあるならリリースしてもOK
(後でリファクタ可能なので)
• →CSSやHTML数行程度の見栄え修正であれ
ばそのままリリースOK
• 場合によってはmasterへの直PUSHも可

26. 例外はある程度設けておく
• 「○○さんが居ないのでコードレビューする人が
いないのでリリースできない」
• →テストを書いてあるならリリースしてもOK
(後でリファクタ可能なので)
• →CSSやHTML数行程度の見栄え修正であれ
ばそのままリリースOK
• 場合によってはmasterへの直PUSHも可
型にハマりすぎるあまり
開発効率が落ちるのは✕

27. 継続的インテグレーション

29. PUSH

30. PUSH
Trigger

31. PUSH
Trigger
Trigger

32. PUSH
Trigger
Deploy
Trigger

33. PUSH
Trigger
Deploy
Notification
Trigger

35. なぜCircle CIを使うか
• スペック的にCircleCI > TravisCI
• Bundle Installとかで決定的な速度差
• SSH Access可なのでCI環境内にSSHで入れる
• ドハマり時の調査やデバッグが捗る

36. テストが落ちたらSlackに
Mentionを付けて通知

37. ？

38. Jenkinsは使わない
• カスタマイズ性が高いがメンテコストも高い
• メンテナが固定化されて各ジョブが秘伝のタレ
化し、Jenkins職人(通称Jenkinsおじさん)が
発生する
• デベロッパープロダクティビティ的なチームが
メンテし続けれるなら良いかも
• IGNITIONは一切使っていない
nanapi側もJenkinsを使わなくする予定

39. デプロイ

40. Pull Requestを経由してリリース

41. Masterへのマージで自動デプロイ

42. Slack上からHubot経由で手動デプロイ

43. リリースは全てCircleCI経由

44. 開発フロー構築で
気をつけていること

45. http://bit.ly/1CGwVff
チームに最適な
ものを選択する

46. あまり欲張り過ぎない
• 高機能過ぎるツールや煩雑なフローをチームに根
付かせるのは大変
• チーム自体の成熟度を客観的に見てツールを選定
する

47. IGNITIONの場合

48. グローバルスタンダードを重視
• 海外向けのメディアサービスなので、システム側
も全てグローバル化
• 海外を含めてデファクトスタンダードとなっ
ているものをそれぞれ選択
• 日本だけで流行っている、ようなものは選択
しなかった

49. http://bit.ly/1onjmaL
社内のエヴァン
ジェリストになる

50. 新規ツール導入後あるある
• ツールを導入したけどみんなが使ってくれない
• 結果すぐ使わなくなってしまった
• 「想定した使い方をみんなしてくれない。うちの
チームには向いていなかった」

51. 新規ツール導入後あるある
• ツールを導入したけどみんなが使ってくれない
• 結果すぐ使わなくなってしまった
• 「想定した使い方をみんなしてくれない。うちの
チームには向いていなかった」
「明日から○○使うからみんな使ってね」
では絶対に根付かない

52. nanapiの場合

57. 誰よりもそのツールを使い、
チーム/社内に伝播させる

58. http://bit.ly/1rJSw30
現状に満足せず
常に改善し続ける

59. モダンな環境を求め続ける
• アーリーアダプターになる必要はないが、
アーリーマジョリティではいるべき
• 流行っていたりデファクトになりつつあるもの
をキャッチアップする仕組みを自分なりに作る

60. 自分が追いかけて
おきたい情報を
tagで登録

61. [PR]

62. nanapiではエンジニアを
募集中です！

63. 詳しくはこちら
http://recruit.nanapi.co.jp/engineer/

64. (非公式ですが)こんな取り組み
やってます

65. nanapiのpodcast “nanapod”
• http://nanapod.kozyty.com/
http://goo.gl/zBNNjp
• テックな内容から社内のことまで色々話します
• 毎週配信予定！外部ゲスト歓迎！
• iTunesのPodcastでも配信中

66. Thank You!