• Like
マジカルsvnとキュアgit
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

マジカルsvnとキュアgit

  • 27,395 views
Published

2012-03-22 techhills

2012-03-22 techhills

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
27,395
On SlideShare
0
From Embeds
0
Number of Embeds
16

Actions

Shares
Downloads
61
Comments
0
Likes
90

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

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 3 Reserved.
  • 4. 今日のアジェンダ• マジカルsvnとは• gitに移行して感じているメリット• 柔軟に移行するための戦略• 移行時の準備チェックリスト
  • 5. マジカルsvnとは• 「マジカル」直訳で「不思議な」• 現実には存在しない不思議なsvnの使い方
  • 6. 我々の取っていたブランチ戦略 Our subversion branches 6
  • 7. trunkstagingrelease 3 main branches 7
  • 8. trunkstagingrelease Commit to trunk 8
  • 9. trunkstagingrelease Cherry pick & test on staging 9
  • 10. trunkstagingrelease Release 10
  • 11. trunkstagingrelease Commit 11
  • 12. trunkstagingrelease Cherry-pick 12
  • 13. trunkstagingrelease Release 13
  • 14. マジカル 14
  • 15. マジカルsvnはなぜ発生するか 15
  • 16. の前に 16
  • 17. 理想の開発フローとは 17
  • 18. 世界中の開発者の中でpullrequest文化が主流になりつつあるので、普段の開発にも 取り入れたい 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. 移行期間を設ける git topic topicmaster subversiontrunk 32
  • 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