何だかんだで、今日唯一参加させていただいたセッションのメモ。
とりあえず、もうSubversionは捨てようと思います。
はてな
- 現在、従業員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 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 merge master
git運用はスムーズか
- やはりgitは難しい
- 覚えるコストがsvnと比べて高い
- よく嵌る
- 誤った方法でリポジトリ変更・pushすると悲惨
- masterにmergeするときにコンフリクト祭り
- windowsクライアントがない
- デザイナ・ディレクタがVMware＋LinuxからSamba経由で・・・
- TortoiseGitに期待
gitを利用したツール
- gitフックフレームワーク
- プロジェクト単位でリポジトリを作成しているので、フックスクリプトを全リポジトリに適用したい場合などに、symlinkをはったりとか。特定のリポジトリのみで使えるようにしたりとか。
- 例えば、コミット時に社内IRCへの通知など
- branchと連動したバーチャルドメイン作成
- ネオあしか
- チケット管理
gitサーバ運用
- 読み込み
- git-daemon
- 高速に動作
- git-submoduleの参照をこちらに
- git-daemon
- 書き込み
- sshd
gitユーザを作って、パーミッション周りの問題を防ぐ
gitのユーザ管理は、"~/.ssh/authorized_keys"で管理
まとめ
- git導入で、とても便利に
- gitのブランチが高速
- gitの導入コストは高い
- そんなにオススメはしない
- けど、もう分散VCSの波はきている
- 今のうちに使っておくのが吉
ここからは後半戦。
旧システムの問題点
- 保守性・拡張性
- テスタビリティ
- 他サービスとの密結合
実は、途中から少しノートPCが暴走気味で、ここでバッテリー切れを招くことに・・・orz
なぜ、フルスクラッチで作り直したのか、という視点から、旧システムの問題点を挙げ、どうされていったのかを解説されていました。
きっと、資料がアップされるか、素敵な方がレポートを挙げてくれるはず。
現在のサーバ運用状況が少し聞けたのは収穫だった。サーバ50台で、790万PV/日かぁ。
