マジカル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