トップ > IT > デブサミ2009「株式会社はてなの開発戦略」講演メモ

デブサミ2009「株式会社はてなの開発戦略」講演メモ

IT

何だかんだで、今日唯一参加させていただいたセッションのメモ。
とりあえず、もうSubversionは捨てようと思います。


「株式会社はてなの開発戦略」

講演者

  • 舘野 祐一 氏
  • id:secondlife
  • 株式会社はてな
  • 現在は、はてなブックマークのリードプログラマ
    • PerlやらJava Scriptやら
  • 社内開発環境整備
    • 開発環境改善好き

はてな

  • 現在、従業員60名(アルバイト含む)
    • うちエンジニア30名
    • インフラ8名、アプリケーション22名

2008年、はてなの開発に変化が・・・

git!

git

  • 分散VCS
  • svnと比べて動作が高速
  • 低コストなブランチ作成
  • 賢いマージ
  • SHA1によるデータ管理
    • コミットの情報など、全てがSHA1で管理される
    • リビジョン1000などの概念はない

2008年初頭の世間の変化

  • RailsのVCSがgitへ移行
  • githubの出現

gitのこれはべんり

  • svnだと、コミットしてリモートに即座に反映とか怖い
  • gitなら、ローカルでちょくちょくコミットできるので安心
  • ブランチの作成が一瞬
  • 仕事でもgit-svnを使うように

これは、数年後には分散VCSが主流な予感、とのこと

しかし・・・

  • cvs/svnに比べて操作が難しい
    • たくさんのコマンドがある
  • 分散の概念の理解
    • リモート？ローカル？
    • 他の人になかなか説明しづらい、理解に時間がかかる
  • windowsのGUIクライアントがない
    • デザイナー・ディレクターに使ってもらうには酷

業務への導入は、まだまだ先かな、とのこと

gitへの道

はてながgitに移行できた、たった1つの方法。

2008/04にSVNリポジトリが壊れた！

リビジョン35000くらいのリポジトリ破壊！

おわたおわたー！

  • まさかのリポジトリの破壊
  • チェックアウト/コミットできない
  • デプロイできない
    • capistrano経由のsvn upでデプロイしていたが・・・
  • このときはssh+rsyncでデプロイ
    • 超大変

復旧できなかったのか？

  • リポジトリのサーバはRAID1で運用していた
  • 片方のHDDが物理的に壊れる
  • もう片方のHDD内のsvnのFSFS(リポジトリDB)も一部壊れてた
  • 特定リビジョン・特定ファイルが取り出せないといった状態
  • svnadminを使っての復旧を試みるも無理

ちゃんとダンプをとって、別のディスクにバックアップすべきです！とのこと

どうしよう？

  • gitで運用できるか？を検証
  • svn前提のはてなのシステムを移行できるか？を検証
    • せっかくのきっかけなので、これをいい機会と捉えた

gitへの移行

  • デプロイ
    • capistrano2.2でgit対応された
    • レシピを書き換えればOK
  • svnからの移行
    • git-svnで、ディレクトリ単位のコンバートが可能
    • svnリビジョンの指定が可能
      • 壊れているリビジョンを飛ばしてコンバート可能

gitからsvnへ

  • git-svnの利用で、驚くほど簡単にできた
  • capistranoのレシピを作り直した
  • svnと比べ、デプロイ速度が1000%高速に
    • はてなダイアリーのサーバは30台程あるので、これは良かった
    • 最初のうちは、デプロイが速過ぎて、半信半疑になって実際にサーバに入って確認してたくらい

構成の変更

  • svnでは、すべてを1つのリポジトリに
  • gitでは、プロジェクトごとに細かく作成

はてな開発での一番のメリット

  • ブランチの作成
    • 作成速度が一瞬
    • ディレクトリ変更なしにブランチが切り替えられる
      • ファイルパス変更いらず
    • svnの頃は作成が面倒、切り替えも重い

いかにスムーズに開発可能かが重要、とのこと

ブランチの作成ポリシー

  • origin/master
    • 本番デプロイファイルのみ
    • 完全にテストが通ったもののみ入れている
  • origin/機能ごとのブランチ名
    • 機能ごとにブランチを作成
  • ローカルでは適宜ブランチ作成

ブランチとコードレビュー

  • 適宜コードレビュー
    • ブランチを切ることで簡単にコードを追いかけられる
  • gitでのコードレビュー
    • git diff master...branchname
      • "..."で、共通の親からの変更点を表示できる

gitでの開発の流れ

  • git checkout -b example
  • コード書いて適宜commit
    • リモートにブランチ反映 / git-publish-branch
    • リモートからブランチに反映 / git pull か git pull -rebase
  • git diff master...branchname
  • masterに反映
    • git merge master
      • masterからマージ、コンフリクトを解決
    • git checkout master
    • git merge example
      • exampleからmasterへマージ
      • コンフリクト発生を防ぐ

git運用はスムーズか

  • やはりgitは難しい
    • 覚えるコストがsvnと比べて高い
    • よく嵌る
    • 誤った方法でリポジトリ変更・pushすると悲惨
      • masterにmergeするときにコンフリクト祭り
  • windowsクライアントがない
    • デザイナ・ディレクタがVMware＋LinuxからSamba経由で・・・
    • TortoiseGitに期待

gitを利用したツール

  • gitフックフレームワーク
    • プロジェクト単位でリポジトリを作成しているので、フックスクリプトを全リポジトリに適用したい場合などに、symlinkをはったりとか。特定のリポジトリのみで使えるようにしたりとか。
    • 例えば、コミット時に社内IRCへの通知など
  • branchと連動したバーチャルドメイン作成
  • ネオあしか
    • チケット管理

gitサーバ運用

  • 読み込み
    • git-daemon
      • 高速に動作
      • git-submoduleの参照をこちらに
  • 書き込み
    • sshd

gitユーザを作って、パーミッション周りの問題を防ぐ
gitのユーザ管理は、"~/.ssh/authorized_keys"で管理

まとめ

  • git導入で、とても便利に
    • gitのブランチが高速
  • gitの導入コストは高い
    • そんなにオススメはしない
    • けど、もう分散VCSの波はきている
    • 今のうちに使っておくのが吉


ここからは後半戦。

新はてなブックマーク

  • ユーザ数：21.6万
  • PV数：790万PV/æ—¥
  • サーバ台数：50台
  • 2008å¹´11月にリニューアル
  • 開発期間約9か月
    • 最初の4ヶ月くらいは、id:naoyaさんが1人で

旧システムの問題点

  • 保守性・拡張性
  • テスタビリティ
  • 他サービスとの密結合


実は、途中から少しノートPCが暴走気味で、ここでバッテリー切れを招くことに・・・orz
なぜ、フルスクラッチで作り直したのか、という視点から、旧システムの問題点を挙げ、どうされていったのかを解説されていました。
きっと、資料がアップされるか、素敵な方がレポートを挙げてくれるはず。


現在のサーバ運用状況が少し聞けたのは収穫だった。サーバ50台で、790万PV/日かぁ。

追記

講演者のid:secondlifeさんが講演資料を公開してくださっています！

関連リンク

rx7 読者になる

関連記事
コメントを書く