マジカルsvnとキュアgit

30,642 views
30,478 views

Published on

2012-03-22 techhills

0 Comments
94 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
30,642
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
68
Comments
0
Likes
94
Embeds 0
No embeds

No notes for slide

マジカルsvnとキュアgit

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

×