Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

デブサミ2009 はてなの開発戦略

17,118 views

Published on

  • SVN\(^o^)/オワタ
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Wouldn't it be nice if more companies would believe 'employee first, customer second'?

    www.freereversecellnumbers.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

デブサミ2009 はてなの開発戦略

  1. 1. 株式会社はてなの開発戦略 株式会社はてな 舘野祐一
  2. 2. 自己紹介 舘野祐一 id:secondlife  はてなブックマークリードプログラマ  Perl, JavaScript ... 社内開発環境の整備  開発環境改善大好き!  Development Environment Conference 開い たり
  3. 3. アジェンダ 最近のはてなでの開発 はてなブックマーク・リニューアル への道
  4. 4. 最近のはてな 従業員数60名(アルバイト含む) うち、エンジニア30名  インフラ8名、アプリケーション22名 結構な規模に 一年間で・・・
  5. 5. 開発の変化 2008年・大きな変化が 一言で言うと…
  6. 6. git
  7. 7. そもそも git とは 分散 VCS  好きなだけレポジトリの複製  どこからでもコミット (svn と比べて)動作が高速 低コストなブランチ作成 賢いマージ SHA1 によるデータ管理  リビジョン1000などという概念はない
  8. 8. 単一?分散? 単一レポジトリ  レポジトリが中央に一つ  基本的に誰でもチェックアウト可能  コミットには権限が必要 分散  レポジトリを誰でも複製(clone ) 可能  もちろん複製したレポジトリにコミット可能  大本のレポジトリの反映 ( push )には権限
  9. 9. 2008年初頭・世の中git 期 Rails などが git に移行 の出現  以前は分散 VCS 難しそう…と  これを気に使ってみる
  10. 10. git を使ってみた [これはべんり]  コミットしてリモートに即反映とか怖い!  ブランチ作成一瞬  ちょくちょくコミット→安心感  仕事でも git-svn を使うように git ベンリスwww  git 厨期 数年後は分散VCSが主流な予感
  11. 11. しかし… 実際に業務で使うか?  cvs/svn に比べて操作難しい たくさんのコマンド  分散の概念の理解 リモート?ローカル?はたまた別のレポジトリ?  windows の GUI クライアントがない デザイナー・ディレクターに使ってもらうには酷  業務への導入はまだまだ先かな
  12. 12. git への道 svn から git へ…
  13. 13. はてなが git へ移行できた たった一つの方法
  14. 14. 時は 2008年 4月末
  15. 15. SVN レポジトリ
  16. 16. 壊れた (^o^)/
  17. 17. \(^o^)/ \(^o^)/ \(^o^)/ \(^o^)/
  18. 18. \(^o^)/\(^o^)/ \(^o^)/\(^o^)/ \(^o^)/\(^o^)/ \(^o^)/\(^o^)/ r35000 \(^o^)/\(^o^)/ \(^o^)/\(^o^)/ \(^o^)/\(^o^)/ \(^o^)/\(^o^)/
  19. 19. svn レポジトリが壊れた! まさかのレポジトリ破壊 チェックアウト・コミットできない デプロイできない  capistrano 経由の svn up デプロイ このときは ssh + rsync で転送  死ぬる…
  20. 20. 復旧できなかったの? RAID 1 でレポジトリを運用 片方の HDD が物理的に壊れる もう片方の FSFS ( svn のレポジ トリDB ) も一部壊れる(壊れてた) 特定リビジョン・特定ファイルが取 り出せない svnadmin 等で復旧試みるも無理
  21. 21. どうしよう… もういちどまっさらなSVNを構築? git に移行すべき?  git で運用できそうなら git に  現在の svn システムを移行できるか調査
  22. 22. git への移行は可能か デプロイ  capistrano 2.2 で git 対応  レシピ書き換えればできる svn からの移行  git-svn で、ディレクトリ単位のコンバートが 可能  リビジョンの指定が可能 壊れているリビジョンを飛ばし,コンバート可能
  23. 23. git から svn へ svn からのデータコンバート  git-svn で驚くほど簡単に デプロイ  capistrano にちょっと手を入れレシピ書き  svn と比べ、デプロイ速度が1000%ぐらい高 速に(当社調べ)
  24. 24. 構成の変更 svn プロジェクトすべて一つのレポジトリ git プロジェクトごとに細かく作成
  25. 25. はてな開発での一番のメリット ブランチ  ブランチ作成速度・一瞬  ディレクトリ変更無しにブランチ切り替え ファイルパス変更いらず  svn の頃は作成面倒・切り替え重い… 実用的でない  いかにスムーズに開発可能かが重要
  26. 26. ブランチ作成ポリシー origin/master  本番デプロイファイルのみ origin/機能ごとのブランチ名  機能ごとにブランチを作成 ローカルでは適宜ブランチ作成  リモートには反映されないのでどんどん
  27. 27. ブランチとコードレビュー 適宜コードレビュー  ブランチを切ることで、簡単に追いかけられ る git でのコードレビュー  git diff master...branchname  '...' で、共通の親からの変更点を表示
  28. 28. はてなでのgit 開発の流れ git checkout -b example コード書いて適宜 git commit リモートにブランチ反映したい / git-publish-branch  リモートからブランチに反映 / git pull か git pull --rebase  git diff master...example master に反映 git merge master # master からマージ, コンフリクト解決  git checkout master  git merge example # example から master へマージ  コンフリクト発生を防ぐ
  29. 29. git 運用はスムーズか? やっぱり git 難しい  覚えるコストが svn と比べて高い  よく嵌る  誤った方法でリポジトリ変更・ push すると悲 惨に master に merge するときコンフリクト祭り windows クライアント無い  デザイナ・ディレクタが VMWare+Linux から..  TortoiseGit に期待
  30. 30. git を利用したツール git に移行ついでにいろいろ作成  gitフックフレームワーク  branch と連動したバーチャルドメイン作成  ネオあしか
  31. 31. git フックフレームワーク svn でのフックスクリプト  すべて一つのレポジトリで運用  一つ書けば OK git では  プロジェクトごとに別レポジトリ  git レポジトリをサーバに作成時に hooks/* ファイルを symlink
  32. 32. git フックフレームワーク すべてレポジトリを監視  push などの変更により実行 特定レポジトリのみフック  WebAPI を叩いてサーバをリロードなど projects/Bookmark に push  以下のスクリプトが実行 /globals/update/* /projects/Bookmark/*
  33. 33. スクリプト例 社内IRCにコミットを知らせる module Grit::Hooks class PostIrc < Hook def execute(refname, oldrev, newrev) 13:29:43 gittan: commit = @grit.commit(newrev) [projects/hatena-bookmark] # ... yuichi tateno: ヘッダ色固定 irc.post('git', message) https://git.local.hatena.ne.jp/git/projects/ha tena-bookmark/commit/71abae8949b
  34. 34. ブランチと連動したドメイン作成 git のブランチをリモートに push 開発サーバのドメインとブランチ をひも付け $ git checkout mobile # カスタム capistrano タスクを実行 $ cap @vhost vhost:auto_create:mobiletest http://mobiletest.local.hatena.ne.jp/
  35. 35. テスト用ドメイン? なんで作成するの? 本番サーバと同じ環境  apache/mod_perl/ディストリビューション 外部ネットワークからの閲覧  誰でもUI や機能の確認に  全員がすべてのプロジェクトをローカルで動 かせる訳ではない
  36. 36. ネオあしか タスク管理システム  git やはてなアイデアと連携 Rails + git-ruby
  37. 37. ネオあしか 開発の経緯 git ブラウザ欲しい チケット管理システムほしい しっくりくる物が見つからない 社内用途にマッチした機能で実装
  38. 38. 基本機能 チケット登録  担当者・タグ・期限・優先度・etc... アイデア連携  はてなアイデアからの連携
  39. 39. git ブラウザ 複数人コミット前提のインターフェイス github ブラウザで使いにくい点を改良
  40. 40. git ブラウザ URL を git コマンドっぽく  /bookmark/diff/HEAD..HEAD~  /bookmark/diff/e87bb6f3...81f0d24ec2b
  41. 41. git コミットと連携 コミットログに [#1000] とタスク番 号を 自動でタスクとひも付く  gitフックフレームワークで一括処理 タスク <-> コミットのひも付け
  42. 42. git サーバ運用 git サーバを建てる  読みこみ / git-daemon 高速 git submodule (svn:externals のような) の参照 もこちらに  書き込み / sshd
  43. 43. git サーバ運用 git ユーザを作ろう  git@hostname:/projects/path  パーミション周りの問題のため git ユーザ管理  ~/.ssh/authrized_keys でユーザ管理 git ユーザのログインシェル  git-shell ・git 関係のコマンドのみ通してくれ るシェル
  44. 44. まとめ git 導入から始まり、とても便利に  git のブランチ最高 svn でも同じことができる・けど実運用に耐 えれるかどうかが重要  はてなアイデア・あしか・git git の導入コストは高い  そんなにオススメはしない  けど、分散VCS の波はもう来ている  今のうちに使っておくのは吉
  45. 45. はてなブックマーク リニューアルへの道
  46. 46. はてなブックマーク ソーシャルブックマークサービス ユーザ数  21.6万 ページビュー  790万pv/日 サーバ台数  約50台
  47. 47. はてなブックマーク 2008年 11月末リニューアル 開発期間約9ヶ月 20 08年 8月からコミット 自分は 8月から専属の開発メンバー4人 現在5人
  48. 48. diff hatebu1..hatebu2 デザイン刷新 ユーザインターフェイス改善 検索機能 お気に入り強化 カテゴリ刷新
  49. 49. リニューアル? 本当にフルスクラッチでリニュー アルする必要は? 旧サービス問題点振り返り
  50. 50. 旧システム問題点 保守性・拡張性 テスタビリティ 他サービスとの密結合
  51. 51. 保守性・拡張性の問題 2002年に作られたはてなフレーム ワークを利用 今使うにはちょっと古い設計  クラス継承ベースでのコントローラの実装  一つの機能を使いたいがために多重継承  継承しすぎ or コピペしすぎ  冗長な view へのマッパクラスの作成
  52. 52. 保守性・拡張性の問題解決 Ridge (社内フレームワーク) の利 用  Rails/Catalyst ライクな軽量 WAF MVC -> MVAC
  53. 53. テスタビリティ問題 はてなフレームワーク  テスト考慮されてない 旧ブックマーク  ほとんどテスト無い
  54. 54. テスタビリティの解決 Ridge/MoCoでテストが書きやすく 移行部分の機能の仕様は確定  そこは完全に TDD 新機能  テストが実装の後になる場合も MVAC の MA を重点的にテスト
  55. 55. 他サービスとの密結合問題 サービス拡張による密結合 DB から直接  データ加工などの実装が必要 他サービスの Perl コードを利用  ライブラリ依存問題
  56. 56. 他サービスとの密結合解決 祖結合 WebAPI利用  RSS  JSON
  57. 57. 既存の MVC の問題点 ORM に処理が集中  データソースが RDB だけならまだ良い 他のデータソースを扱う場合は?  適当にクラス作成?  コントローラに実装?
  58. 58. MVAC MVAC  Model / View / Applicaiont / Controller アプリケーションレイヤの作成  コントローラとモデルの間に挟んで抽象化
  59. 59. はてなブックマークでは データソース層 サービス層 アプリケーション層 という3層構造
  60. 60. データソース層 ORM のクラス  基本的な機能  リレーション情報
  61. 61. サービス層 ドメインロジックの実装 例:人気エントリーの取得 my $service = H::B::S::Hotentry->new; $service->threshold(5); $service->category('life'); my $entries = $service->entries(0, 10); // 10件取得
  62. 62. アプリケーション層 サービス層を利用して実装 ページャの作成・キャッシュ操作など my $app = H::B::A::Hotentry::Top->new; $app->show_detail = 1; # view で必要な項目なども設定 $app->offset(0); $app->limit(10); my $entries = $app->entries; my $pager = $app->pager;
  63. 63. 冗長? サービス・アプリケーションと分け るのは冗長? アプリケーションはビューとのつな ぎ込み サービスはドメインロジック  CUI アプリも簡単に作れるように
  64. 64. フレームワークを切り離す さきほどの3層は、WAF を一切利 用していない 単体テストが断然書きやすく WAF では  URL/コントローラ/ビューのマッピングのみ  コントローラでクエリパラメータをアプリ・サー ビスにマッピング
  65. 65. リニューアル開発 当初・id:naoya が一人で  黙々とテスト・実装 後半・多人数開発  ポストイット + ホワイトボード ポストイット便利  git を利用しての機能開発 master はテストが通ったコードのみ コードレビュー
  66. 66. スケジューリング 社内スケジュール通り ただ、最後はテストがおろそかに.. リリース直後の高速化などでどた ばた  実はリリース直後、全テスト通ってなかった 教訓を得た
  67. 67. テストが青い 全部通る!気持ちよい! こんなにテストがあるよ  ならきちんとテスト書かないと  やたーテスト増えたよ
  68. 68. テストが赤いと 全部テスト通らない!やる気が…  このテスト通らないの自分のせいじゃないし.. 別にテスト増やさなくていいかな… テスト赤い→やる気でない→テス ト書かない→赤い 負のスパイラル
  69. 69. 現在は 100 個以上のテストファイル 2000 個以上のアサーション all tests successful. files=103, tests=2077, 327 wallclock secs ( 1.81 usr 0.59 sys + 170.40 cusr 110.59 csys = 283.39 cpu) result: pass
  70. 70. 「テストの」高速化 テスト時間  以前は合計10分強  1テストでも、fixture (DB) を使うと10秒ほど テスト実行時間がストレスに  もっとさくっと終わって欲しい!
  71. 71. fixture の高速化 YAML -> ORM -> RDB  数百件のデータを ORM 経由で insert  遅い  テストメソッドごとに走る テスト -> 実装 -> テスト -> 実装  テストの時間 MOTTAINAI !
  72. 72. 局所高速化 YAML -> ORM -> RDB -> mysqldump  YAML のタイムスタンプが変更無い  mysqldump のデータ insert 一行 fixture テストが 10秒→4秒に 全体のテストも 10分→6分に  life-changing
  73. 73. まとめ こんな感じでリニューアル開発  適度な抽象化  適度なテスト
  74. 74. 終わりに 全体の開発環境を向上させる  ストレスレスで開発したい!  開発しやすい環境も重要  楽しい開発を!
  75. 75. ご静聴ありがとうございました

×