マジカルsvnとキュアgit

2013-03-22 第5回テックヒルズ『Go to Git !』～さらばSVN～

Transcript

1. マジカルsvn と キュアgit 2013-03-22 #techhills 大仲 能史 a.k.a. @onk
2. 宣 伝 Platinum Sponsor of Rubykaigi2013
3. 自己紹介 • 大仲 能史 • @onk • 普段の仕事 – アプリケーションエンジニア – ソーシャルゲーム開発部 – 前線でアプリ開発をしています copyright© DRECOM Co., Ltd All Rights Reserved. 3
4. 今日のアジェンダ • マジカルsvnとは • gitに移行して感じているメリット • 柔軟に移行するための戦略 • 移行時の準備チェックリスト
5. マジカルsvnとは • 「マジカル」直訳で「不思議な」 • 現実には存在しない不思議なsvnの使い方
6. Our subversion branches 我々の取ってい たブランチ戦略 6
7. 3 main branches 7 trunk staging release
8. Commit to trunk 8 trunk staging release
9. Cherry pick & test on staging 9 trunk staging release
10. Release 10 trunk staging release
11. Commit 11 trunk staging release
12. Cherry-pick 12 trunk staging release
13. Release 13 trunk staging release
14. 14 マ ジ カ ル
15. マジカルsvnは なぜ発生するか 15
16. の前に 16
17. 理想の開発 フローとは 17
18. 世界中の開発者の中でpull request文化が主流になりつ つあるので、普段の開発にも 取り入れたい 18
19. 理想の開発フローとsvnとgit • チケット駆動開発をしたい – OSSで成功しているモデルだし、作業管理がし やすくなる • svnは各所でTiDDを妨げてくる – ブランチを切るコストが高い – mergeが頭悪い • gitにはTiDDを実行する周辺環境が揃って いる – githubとpull request、travis-ci等
20. svnではできないのか • svnは重い • 1.7で緩和したけどまだまだ重い • 本当に重いです。やりたい開発フローに 合わせられない重さ – そしてマジカルsvnが生まれる • 「trac-svnのリポジトリブラウザ便利だ わー」と言っている人は世界を知ってく ださい
21. svnではできないのか • ツールが文化を規定する – 速くなる、楽になるだけで世界が変わる • svnでは到達しづらい目標点に軽くたどり 着くことができる • 「知の高速道路」「巨人の肩」 • 乗らない手はない
22. 今日話すこと • 話すこと – みんなでgit化する方法 • 話さないこと – 一人でgitを始める方法 – 例えばgit-svnで今すぐ中央svnリポジトリ<-> 自分はgitで開発、とするとか – git-svnは1年半ほど使い倒したので興味があ る方は直接聞きに来てください
23. gitに移行して感 じているメリッ ト 23
24. gitに移行して感じているメリット • 十分に速いリポジトリブラウザ • TiDDをやりやすい • メンバーの意識改革につながった
25. 十分に速いリポジトリブラウザ • github、bitbucket、gitlab、etc.. • tracやredmine＋svnとは桁が違う閲覧性
26. TiDDをやりやすい • ブランチを切るコストが低い • ブランチをマージするコストが低い • diffを見ながら会話し、1クリックでマー ジできるpull requestという仕組み
27. メンバーの意識改革につながった • ちゃんとコードを見てもらえる安心感 • ちょっとした思いつきをcommitする障壁 が下がる • みんなが知っていれば僕だけが悪いん じゃないという逃げ腰の人にとって、ペ アプロやコードレビューはものすごく幸 せな環境
28. 外に出ていくようになる • 「githubにアカウントを持っていなかっ たけど作りました」 • github Organization Accountで運営して いたプロジェクトに気軽にpull request を送ってもらえる環境を作れた • OSSに貢献しやすくなる
29. git移行時の フロントエンド選定ポイント • web UI • ユーザ管理やリポジトリ管理等もwebから 行える • pull request相当の機能がある • 継続してメンテナンスできる • OSSに貢献する敷居を下げる
30. 柔軟に移行する ための戦略 30
31. 柔軟に移行するための戦略 • 新規アプリには勝手に始めてもらう – やる気がある人を妨げない環境があればいい – 中央のgitリポジトリだけ用意すると開発が始 まる • 既存の数年運用してきたアプリをどう移 行するかが最大の肝だった – クロスコミットで解決
32. subversion git 32 trunk master topic topic 移行期間を設ける
33. 移行期間を設ける • クロスコミットするようにした – git-svn-bridge • svnにcommit / gitにpushどちらでもいい – 「重要なので、svnで失礼します」 – リリースフローはsvnのまま変えない • まずgitに慣れてもらって、その間に cherry-pickが必要なリリースフローを直 す
34. 移行後の開発フロー • git-flow、github-flowは夢物語 • リリースし続けるアプリケーションでは github-flowが理想 – リリースできないものをmasterに入れない • ブランチをdeployしてテストする環境整 備とか。。 • まだ試行錯誤中です。
35. 移行時の準備 チェックリスト 35
36. 「社内に1人は居るgit好 き」に任せると漏れがち になる部分を重点的に 36
37. 移行時の準備チェックリスト • 上を倒す • 横を倒す • 継続的に運用する手段の確保
38. 上を倒す • githubの説明、レビュー文化の説明 • 「正しい文化だから取り入れましょう」 – コードレビューが改善として上がる状況なら これは納得してもらえる • GHEを入れるほどは倒せなかった – 予算に組み込まれてないので数百万のイニ シャルコストはまずい – 継続的なコストはそこまで気にしていないの で勝手にgitlab化を進めた
39. 横を倒す • 横とは – (svnを上手に使えていない)非エンジニア – svnで回ってるので移行する理由がない人
40. 横を倒す • メリットを提示する – そもそも変更履歴という概念があまりなく、共有 サーバとして使っている – 画像の差分が見られるよ • 元気なプロジェクトで試して便利そう楽しそ うに見せる – pull requestでワイワイする – 全ユーザが全プロジェクトを見れるようにし、 回ってるプロジェクトを見せて使い方をイメージ してもらう
41. 横を倒す • 移行しない理由を潰す – 推奨クライアントの設定、ドキュメント整備 • windowsがネック。SourceTree出ましたね！ • エンジニア向けにはtigやfugitive、magitの説明 – 全プロジェクト、勝手に同期しておく – 全社的に移行する姿勢を見せる • ドメインを会社のトップレベルにした – 使い始めてくれたプロジェクトのIRCを張って、 不満を言われた瞬間に直す
42. 横を倒す • 移行しない理由を潰す – 詰まった時にすぐ聞ける環境を作る – 各プロジェクトに2人以上gitのコミットオブ ジェクトを理解している人を配備 – 置き換えるための不安を潰し続ける • 今やってる～の作業、gitではこの手順書を見てく ださい • コンフリクトが起きたらコミットツリーを描いて 何故おきたのか、どうすればいいのかを説明する
43. 継続的に運用する • バックアップ • 冗長化 – gitoliteのミラーリング – mysqlのレプリケーション • gitlabのコミッタ数名 – vagrantを用意 – gitlabの更新手順を用意
44. 全てのプロジェクトを移行する • gitでの様々な手順書を用意する • 上手い使い方を発表してもらう • キリ番を祝う – 【祝】issue 100 • 移行してないプロジェクトは仲間外れだ よね、カッコ悪いよねという空気の醸成 – 「開発者はうまく怒らせるとすごい生産性を 発揮する」
45. gitである必要は あったか 45
46. 結論を言うと 「ない」 46
47. 十分に速いソースコード リポジトリと、TiDDをや りやすい周辺環境が揃っ ていれば何でも良い 47
48. svnには欠けていた gitには揃っている 48
49. リポジトリをgitにするだけじゃダ メなの？ • ワークフローはツールが規定する – UIが使われ方を決める。UI大事。 • web UIが無かったら？ – ほぼsvnと同じ使われ方をします – ゴールは「pull request文化の輸入」 – 個人で幸せになってていいのは小学生まで – チームの生産性最大化を考えよう
50. ソフトウェアだけじゃな く、チームも、組織も、 すべてを設計せよ 50
51. ご清聴 ありがとうございました 51