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