Deb2009

1,713 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,713
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Deb2009

  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. ご静聴ありがとうございました

×