イベント登録数1,996

第5回テックヒルズ Go to Git!~さらばSVN~

グリー・ドリコム・クルーズ・モバイルファクトリー・KLabの事例に見るGit移行のメリットと問題点まとめ~第5回テックヒルズ「Go to Git!~さらばSVN~」レポート
島田達朗 2013/3/28 え? バージョン管理まだGitじゃないの?  「Git」は高いパフォーマンス、強力なマージ機能、障害耐性などにおいて優れたバージョン管理システムの1つだ。今やWeb業界において、バージョン管理システムのデファクトスタンダードといっても過言ではない。会社として導入していなくとも、技術者であれば1度は耳にしたことがあるのではないだろうか。  また、Gitリポジトリをホスティングするサービス「GitHub」は「ソーシャルコーディング」というムーブメントを引き起こし、世界中の開発者たちの間で急速に広がっている。  こうした動きもあり、もともとバージョン管理システムとして、SVN(Subversion)などを使用していた企業が、Gitに移行する事例が出てきた。しかし、SVNとは異なるアーキテクチャであるため、会社単位での移行障壁は決して低くない。  本稿では、2013年3月22日に東京・六本木にあるアカデミーヒルズで開催された第5回テックヒルズ「Go to Git!~さらばSVN~」の模様を紹介。Gitへの移行で実際に感じたメリットや移行事例のポイントなどをピックアップしていく。  イベントでは、まず、Gitを導入したグリー、ドリコム、クルーズ、モバイルファクトリー、KLabの技術者が、導入の経緯などを簡単に紹介。その後、パネルディスカッションでGit移行のメリットや成功の秘訣などを語りあった。 SCMの歴史と、グリーにおけるSCMの変遷 ボトムアップで導入していったドリコムのGit環境 動くものを見せられないと、偉い人は分からんのですよ 熱心で慎重な人に任せよう―Git移行の3つの“山”とは GitHubのPullRequestを自動監視するオープンソース「Metahub」とは 経験者が語るGit移行で感じた壁と、その乗り越え方 SCMの歴史と、グリーにおけるSCMの変遷 グリー 開発本部 インフラストラクチャ統括部クラウド基盤チームマネージャー 大場光一郎氏  グリー 開発本部 インフラストラクチャ統括部クラウド基盤チームマネージャーの大場光一郎氏は、グリーにGitHub Enterprise(以下、GHE)を導入した人物である(参考:グリーの活用事例から見るGHEのメリットと問題点)。「本当のレガシーの話をしよう」と題した講演の中で、大場氏は最初にSCM(Software Configuration Management、ソフトウェア構成管理)の歴史について言及した。 SCMの歴史  SCMの歴史は「SCCS」(Source Code Control System)から始まる。ここから「バージョン管理」という概念が生まれ、その次に出てきたのがGNUライセンスで公開された「RCS」(Revision Control System)だ。しかし、RCSはファイルをロックする仕組みだったので、「ロックしたまま帰宅すると、別の作業者が操作できない」という欠点があった。これは、特にオープンソース開発のように地理的に離れている開発者同士が使うような条件だと、なおさら辛い部分である。  その欠点を補う方法が「マージ」である。このマージの概念は、「CVS」(Concurrent Versions System)によって生み出された。CVSにより、ロックの制約がなくなり、時間や場所を超えた開発プロジェクトが可能となったのは、記憶に新しいだろう。  その次に、今回の勉強会のタイトルにも含まれているSVNが出てくることになる。SVNは中央リポジトリやクリーンなアーキテクチャで多様な環境で動作することが魅力であった。  そして最後に、現在のGitに至る。SCMを用いてソースコードのメンテナンスコストが下がることにより、オープンソースは発展しやすくなっていった。「SCMの進化がソフトウェア開発のパラダイムシフトを後押しする」と大場氏は強調した。 グリーにおけるSCM活用の歴史  グリーでは、2004年頃の黎明期は田中良和社長が手作業で更新の管理をしていた。その後現在CTOを務める藤本真樹氏が2005年にSVNを導入。その5年後の2010年にGitに移行し、2012年の3月からはGHEを用いている。  Gitへの移行は藤本氏からの「トップダウンで移行が行われた」(大場氏)という。また、ブランチの管理については、Gitのブランチ管理があまりに自由過ぎたために、グリーでは「git-daily」というツールを開発して利用している。「git-daily」はオープンソースとしてGitHubで公開されているので、試用も可能だ。 git-dailyの概念図(大場氏の講演資料より) ボトムアップで導入していったドリコムのGit環境 ドリコム ソーシャルゲーム事業本部 大仲能史氏 SVNでは到達しづらい目標点に軽くたどり着くことができるGit  先ほどのグリーとは対照的にボトムアップでのGit移行を実現したのはドリコムだ。「ツールが文化を規定する」と語るのはソーシャルゲーム事業本部の大仲能史氏である。大仲氏は「マジカルSVNとキュアGit」と題した講演で、まずドリコムが取っていたブランチ戦略を「マジカルSVN」として紹介した。 「マジカルSVN」の例(大仲氏の講演資料より)  SVNの欠点としては、ブランチ作成コストが高いこと、動作が重いこと、マージの性能が良くないことを挙げ、これらの問題を解決してくれるのがGitだとした。「GitにはTiDD(Ticket-Driven Development、チケット駆動開発)を実行する周辺環境が揃っている」(大仲氏)。 社内の“大人の事情”にめげず、Gitを導入  「そんなに良いのであればGitにしよう」と個人的に移行することはできても、全社での移行はそう簡単ではない。もちろん移行には、さまざまな問題がある。まず、上司が気にするのはイニシャルコストであった。  当初、大仲氏はGHEを使いたいと考えていたが、GHEは20ユーザー/年間5000ドルの費用が掛かり、ドリコム社が利用する場合は「数百万になる」(大仲氏)ことが分かった。予算に組み込まれていなかったため、無料の「Gitlab」を使用することで、コストの問題を解決。周りの同僚に対しては、「Gitのメリットを提示することで自然に『Gitに移行しよう!』という雰囲気を作った」(大仲氏)とのこと。 SVNからGitへの移行(大仲氏の講演資料より)  具体的には、Gitを使用している元気なプロジェクトを見せて使い方をイメージしてもらい、推奨クライアントの設定やドキュメントを整備し、移行しない理由をつぶしていった。その他にも、IRCを使うことで、不満を言われたら、すぐに対応するなど草の根的な活動が実を結び現在の移行に至る。  今後は「【祝】issue 100」といった具合にキリ番を祝ったりと、さらなるGit環境の盛り上げを行っていくという。「pull request文化の輸入がゴール。ソフトウェアだけじゃなくて、チームや組織も設計するべき」と大仲氏は講演を締めくくった。 動くものを見せられないと、偉い人は分からんのですよ クルーズ 技術統括本部 梅田昌太氏  社内制度を使いGitへの移行を代表へ直接提案したのは、クルーズ 技術統括本部の梅田昌太氏。「Gitと出会って人生変わった」と題した講演で、梅田氏はGitへの熱い想いを語った。  梅田氏を突き動かしたのは現状の技術的負債。具体的には、クルーズではSVNが上手く利用されておらず、Git導入以前はトランクのみで運用していた。また、とあるプロジェクトでは、ソースコードに直接説明を加えたためにソースコードの48%がコメントだった。 トランクオンリーのSVN運用(梅田氏の講演資料より)  この状況を打破するべく、梅田氏はGitを導入。負債と向き合って150万行のコードと根気良く闘った。導入後はSVNと比較して「マージやクローンが爆速になった」(梅田氏)とのこと。  一般的に、新しいものを導入するときには上司にいろいろと言われて面倒なことが多い。そんなときは「勝手に作ってしまおう」というのが梅田氏の提案だ。 熱心で慎重な人に任せよう―Git移行の3つの“山”とは モバイルファクトリー 開発推進室室長 阿部正浩氏  続いての講演のタイトルは「Git移行の3つの山」。モバイルファクトリー 開発推進室室長の阿部正浩氏によると、3つの山とは「動機」「実行」「その後」のことを指し、Gitのメリットとしては「速さ」が最も説得力があり、導入「動機」の決め手となったという。 隠れた動機はJoel Spolskyの言葉(阿部氏の講演資料より)  「実行」に関して阿部氏は「若い人で技術を薦める人は2種類いる」と語る。2種類とは、「新技術だからと薦めてくる人」と「新旧に限らず良いと確信したものを薦めてくる人」である。  「前者は、ただの新しいもの好きで、新しいものを触ったり作ったりするところまでは良いのだが、移行までしっかりやってくれない。まさに今回の移行で中心となった人物は後者で、調査や勉強会、実作業などを主体的に行い移行を支えた」(阿部氏)  「その後」としては、「正直あまり発展はしていない」(阿部氏)が、標準のブランチ戦略を作りたい、デザイナなどにも使わせたい、日報やITSとの連携を改良したい、GHE使ってみたいなど、やりたいことは多くあるようだ。最後に阿部氏は、「専門職の嗅覚を信じよう。熱心で慎重な人に任せよう。明確な費用効果は期待しないように」として移行を検討している現場の管理職に向けてメッセージを送った。 GitHubのPullRequestを自動監視するオープンソース「Metahub」とは KLab 開発制作本部 第4開発制作部 エンジニアリングマネージャー 於保俊氏 KLabにおけるSCMの歴史  最後のセッションはKLab 開発制作本部 第4開発制作部 エンジニアリングマネージャー 於保俊氏、同社 開発制作本部 第2開発制作部 エンジニアリングマネージャー牧内大輔氏による講演「Metahub for github―git移行のその先にあるもの」。「元々Git抵抗勢力だった」と語り始めたのは於保氏。於保氏は実際に使用していく中で、Gitの良さに気付き、「推進派に変わっていった」という。  KLabもグリーと同様にコード管理はSVNから始まり、次にSVNに近いDVCS(Distributed Version Control Systems、分散型バージョン管理システム)として「Bazaar」が普及。於保氏は「Gitの前がBazaarだったことで、結果的に分散管理のハードルを下げた」と語った。現在は、GitHubを使いたいという要望もあり、リポジトリ管理体制の構築のためにGitを導入している。 限られた人数で多数のコードレビューさばくために生まれた「Metahub」  於保氏のようなエンジニアリングマネージャーは案件横断でコードのレビューを行う必要があった。しかし多数のレビュー要請を少数で行うことには限界がある。そこで、同社 開発制作本部 第2開発制作部 エンジニアリングマネージャー 牧内大輔氏が開発したのが「Metahub」である。 KLab 開発制作本部 第2開発制作部 エンジニアリングマネージャー牧内大輔氏  KLabのリポジトリの特徴としてベースのフレームワークを使用しているために、案件間の差異が比較的少ない。そこに目を付け、PullRequestをパターンマッチで検出・フィルタリングし自動監視するMetahubを作成した。パターンマッチは正規表現を用いて行われており、新しいパターンが見つかった場合には随時追加を行う。 Metahubの使用例(於保氏・牧内氏の講演資料より)  Metahubを導入すると、タイポやSQLインジェクションなど、さまざまな問題を自動検出できる。残念ながら正規表現のパターンは公開されていないが、Metahub本体はオープンソースとしてGitHubに公開されているので、同じ問題を抱えている方はぜひ試用を検討してはいかがだろうか。 経験者が語るGit移行で感じた壁と、その乗り越え方  各社が導入の経緯などを簡単に紹介した後、パネルディスカッションで、Git移行のメリットや成功の秘訣などが議論された GitとSVNの比較 司会 クルーズでGitとSVNを比較した表を作成したが、こちらの認識は各社でも合っているか? クルーズが作成したGitとSVNの比較表 大場氏 まぁSVNと比べたら、そうだよねという感じ。ただ、お互い同じ領域をカバーしているわけではないので、あくまで一面でしかないという印象。例えば、分散させるために「SVK」を入れますという話になったら、Gitよりはるかに複雑なアーキテクチャになる。 梅田氏 コミットハッシュで管理するという方法は、バージョン管理自体を全く知らないという人にはアレルギーを引き起こすかもしれない。 リポジトリが分散するメリットは? 司会 各社の話の中で「分散」というキーワードが良く出てきた。例えば、Gitでサーバ側にリポジトリを作って、クライアント側でそれを普通にクローンする形にした場合、SVNの中央リポジトリと全く同じなのか? 分散リポジトリで開発するメリットは何なのか? 於保氏 確かに構造的には一緒になる。ただGitだと、手元でバージョン管理ができるようになるし、ブランチがかなり切りやすい。開発者が手元でテスト的にコードを書くのが非常にやりやすくなるといった部分は実際使ってみてメリットを感じている。 司会 例えば、打ち消しが楽であるとか? 於保氏 はい。後は、いらないと思ったらブランチを消せば良いわけなので。そういったところの柔軟性は大きい。 司会 他に何かメリットを具体的に感じる部分はあるか? 大仲氏 分散して良いこととして、手元にログがあるから対応するのが速くなる。 梅田氏 最近、日曜プログラマとかがRailsとjQueryを使って、サイトを作るとか流行っているが、そういうのをデニーズとかでも、できるようになったのが、一開発者として楽だと思う。ネットワークがつながってなくてもローカルにコミットして、家でオンラインになったときにGitHubにプッシュできるので、気が向いたときにコードを書き始めることができるようになった。 SVNからGit移行する際の問題 司会 Git移行には、なぜ抵抗が生まれるのか? 梅田氏 SVNとコマンド体系が大きく違うので、そこが嫌な人は嫌なのだろう。 司会 確かに1個前に戻すのにも、いろいろなやり方がある。そこは人によっては混乱するかも。 梅田氏 微妙にコマンドが似ているのが分かりにくいのかもしれない。 於保氏 僕自身、Gitへの移行に抵抗していたが、そういう意味では「バージョン」という考え方がガラッと変わってしまうのが非常に大きい。今までSVNだと連続した「バージョン」だったのが、Gitだと「ネットワーク」になる。そこを理解していないと、やったばかりの変更を戻す操作も「どうやれば良いんだろう?」となってしまうので、難しいだろう。逆にいうと、そこを理解してしまえばGitを使うことでできるのでは。 司会 Gitを移行するときの過去のSVNの履歴は、どうしている? 大場氏 グリーの話をすると、そこは割り切った。GitからSVNを使うときに「git-svn」というツールがあるが、SVNの都合をGitで吸収するみたいな設計思想になっているので、普通にGit移行のために使うと、なかなかGitらしい使い方ができない。なので、プロジェクトごとにはなるが、都合の良いタイミングで「git - svn export」してGitに突っ込んで移行した。 大仲氏 git-svnは、すごく重い。うちの28万リビジョンを移行するのにホントに1カ月かかった(笑)。 司会 デザイナのようなプログラマ以外の職の人に結構、抵抗感を持たれるんじゃないかと思うが、その辺りはどうしたのか? 阿部氏 そもそもデザイナがSVNを使うときはGUIのツールが多い。それがGitでもできるかできないかで大きな違いがある。 於保氏 やはり大きいのがGUIツール。ある案件で「TortoiseGit」を使っていたが、このとき担当者は使い方を教えるのに、かなり苦労したと聞いている。 Git移行を成功させるためには? 司会 困ったら聞ける環境は、すごく重要。結論から言うと、Gitのことを上から下まで知っている人は、1人いれば良いのだろうか? 大仲氏 2人は必要だろう(笑)。1人だと、その人に質問が集中してしまうので。負荷分散しないと1人が休んだときに上手く回らなくなる。 司会 単一障害点になるということで。 於保氏 KLabだとIRCでGitについて相談できるところがあり、そこに積極的に関わってくれるGitの推進チームがある。後は、良いレビューを活性化させるために良いレビューをしてる人を表彰するような場を作っている。 Gitを使って良かったことは? 司会 Gitへの移行が完了して、運用していて良かったことは? 大仲氏 もともと、あまりコードレビューをしていなかったので、そういう環境から自分のコードにレビューを入れてくれる環境にシフトしたのが良かった。それまで1日数回のコミットしかしなかった人がリクエストをバンバン送ってくれるようになったり、人が考えていることが見える化された。 大場氏 SVNのコミッタはとても強い権限を持ち、特別な存在だったが、Gitはそのコミッタのハードルを下げた。これにより、コードをコミットしやすくなった。 エンジニアとして新しいことを覚えたくない人はクビ!?  Gitへの大規模移行には、さまざまな痛みを伴うことがあるが、各社それぞれの問題に対応し、それらを乗り越えていった。その結果、Gitに移行することで大きなメリットを享受している。  会場からの「Gitの移行に興味のないエンジニアはどうしたら良いか?」という質問に対して「エンジニアとして新しいことを覚えたくない人はクビ!」という過激な発言が大場氏から飛び出たが、冗談として受け取りつつも賛同する声が多く見られた。  新しい時代の流れに対応できる企業を創るには、Gitに限らず「新しいもの取り入れて、変えていく」ことを企業の文化として持っておくことが重要なのではないだろうか。 参考資料  本イベントで使われた講演資料は、「第5回テックヒルズ Go to Git!~さらばSVN~」から一覧できるので、参照してほしい。 著者プロフィール 島田 達朗(しまだ たつろう) 「おばかアプリ選手権」2012 夏 大賞受賞作品「アルプスの丘で~」開発者の1人。おばかアプリやデータ解析に興味あり。Twitter:@tatsushim。オンラインギャラリーサービス「Creatty」(クリエッティ)を制作・運用。 「イベントカレンダー+ログ」レポート投稿募集中! このレポート記事が掲載されている本サービス「イベントカレンダー+ログ」では、イベント登録者がレポートを投稿したり、資料を一覧できるまとめページを作成できます。新着レポートは一覧に表示され、こちらのRSSにも配信されるので、ぜひご活用ください。