SVN から Git へ:進行中の開発に影響を与えずに Git へ移行したアトラシアンの方法

*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 1 月 3 日、Jonathon Creenaune 投稿 “From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development

このポストは、エンタープライズ開発チームが Git に切り替えることに注目した連載記事の一つとして、Dr.Dobb’s で紹介されました。

アトラシアンでは、ここ何年もの間、DVCS に熱狂していました。私たちは DVCS に多額の投資を行ってきたのです。Bitbucket (クラウド DVCS リポジトリのホスト) を買収し、Stash (社内環境での Git リポジトリマネージャ) を開発しました。さらに、FishEye (コードの閲覧検索ツール) に DVCS サポートを追加しました。そして、課題管理ツール JIRA に、DVCS へのコネクタを数多く追加しました。

私たちは DVCS がソフトウェア開発における飛躍的な前進だと信じています。そのため自分たちのプロダクトとライブラリのコードベースを、中央集権的なバージョンコントロールシステム(通常は SVN)から DVCS に移行しました。中には大掛かりな移行になったものもあります。いまでは、DVCS への移行についてかなり経験が溜まりました。

この三部からなるブログシリーズでは、アトラシアンが行った最大の移行に注目します。これは、11年も蓄積された JIRA のコードベースを SVN から Git に移行するというものでした。私たちの前に立ちふさがった障害は何だったのか?私たちが学んだ教訓とは?そして最も重要なこととして、いかにして JIRA に対して進行中の開発を妨げることなく移行したのか?この経験を共有することで、同じような移行を行おうとしている人の助けになればと思います。

ここでは Git に注目します。それは JIRA を Git に移したからですが、このシリーズに書かれている内容はすべて Mercurial にも当てはまります。アトラシアンでは、Git と Mercurial の両方を使用しています。

なぜDVCSか?

巨大なコードベースを移行するにはコストがかかります。自分自身に対して、上司に対して、あるいは同僚に対して最初に答えるべき問いとは、DVCS によって何がもたらされるのか、そして、移行コストをかける価値があるかどうか、です。

多くのプロジェクトで SVN を使ってうまくいってきました。私はそうですし、アトラシアンもです。そして、この記事を読んでいる人の多くも SVN をうまく使っていると信じています。移行コストというものは常に存在しますが、あなたは特にこう訊きたいと思うでしょう。「もう長いこと Subversion でバージョン管理の要求を満たせてきたのに、どうして変える必要があるのか?」私からすると、それは間違った質問です。本当にするべき質問はこうです。「DVCS を使うと、今やっていることがどう良くなるのか?」

Git について、知られていることがいくつかあります。コードを書く開発者にとって、Git の方が高速です。Git を使うと、より応用的なワークフローが使えるようになります。たとえば、フィーチャーブランチ、フォーク、プルリクエストなど。理論的には、こうしたワークフローはすべて SVN でも可能です。しかし、Git と比べて SVN はマージが難しいことから、SVN で行うというのは考えられません。しかし、SVN から移行する人であれば誰にとっても、Git の恩恵は、軽量なブランチングと容易なマージになるでしょう。 Git を使えば、普段の SVN で行っているワークフローを SVN よりもうまくできるのです。

これはどういう意味でしょうか?私たちが実際にどのようにソフトウェアを開発しリリースしているかをお話ししましょう。私たちのほとんどは、少なくとも一回はソフトウェアがリリースされている環境で作業しています。そのソフトウェアのことを私たちは「安定」ブランチと呼んでいます。私たちは保守やバグフィックスを安定ブランチに対して行いつつ、新しいフィーチャの開発は「開発」ブランチ上で行います(使っている VCS に応じて、trunk や master、default などと呼ばれます)。

安定ブランチにバグフィックスをコミットした場合、それを master にも取り込む必要があります。SVN のマージはつらいことで有名で、この作業は実際の内容に対してではなく、リビジョン履歴に対してのみ行われます。その結果、多くの人がマージを避けたり、頻度を下げて、日々のワークフローでは行わないようにしたりしています。あなたがこれまで携わったプロジェクトで、安定ブランチと開発ブランチが乖離し始めたり、乖離しすぎて元通り一緒にするのに実際のプロジェクトと同じくらいコストがかかるようになってしまったりしたことが、どれだけ多くあるでしょうか?私はそういうことが起きたプロジェクトにいたことがあります。そして、他の開発者の話を聞いても、こうしたことは SVN ではよく起きるのです。この問題を扱う戦略はいくつかあります。たとえば、私たちの課題管理ソフトウェアである JIRA の場合、私たちはマージを無視し、開発者に各安定ブランチと開発ブランチに同じコミットをしてもらいます。そして、正しく行われているかどうかは、QA に確認してもらいます。

Git を使えば、こんな苦労をしなくてよくなります。Git ではマージがとても簡単なので、コミットのたびに安定ブランチをすべて開発ブランチにマージするということが現実的なのです。今やこれが私たちの標準的なワークフローになりました。もし、フィーチャブランチやフォーク、プルリクエストをすぐに使いたいと思っていなかったとしても、Git は使い始めたその日からいいことがあります。

そして、準備ができれば、Git のおかげで可能になる応用的なワークフローの恩恵を受けれるようになります。DVCS に切り替える前は、私たちの主要なプロダクトは 90 日のリリースサイクルを目標としていました。この 90 日のリリースは二つのプラットフォームに行われます。クライアントが自分のサーバにインストールするためのダウンロード用プロダクトと、私たちがホストするクラウドプラットフォーム(アトラシアン オンデマンド)です。後者の場合、クライアントは月当たりの値段を払います。ブランチを開発ワークフローの中核にすることで、この間隔を短くすることができました。 いまではなんと、主要なプロダクトをクラウドに対して2週間おきにリリースしているのです。

切替

JIRA はコードベースの移行対象としては、そこそこ大きいものです。11 年もの歴史があり、21,000 ファイルについて、47,228 ものコミットが行われてきました。我々は、コミッター 30 人がかりで、2 週間かけてことに当たりました。それ以上に、VCS は JIRA のようなプロジェクトにとって、まさに馬車馬のように働いてくれました。ビルド、コードレビュー、リリーススクリプト、製品配布用のスクリプト、そしてソースコード…これらのすべてがソースコード管理システムに入れられ、複雑な依存関係をタペストリーのように描き出していたのです。

移行における私たちの主な目標は、開発者への割り込みを最小限にすることでした。それも、単にコードをコミットできればよいというものではなく、ソフトウェア開発を取り巻くインフラストラクチャ全般に関してです。

コードレビューシステムの中には 3 年半にわたる JIRA の歴史が刻まれています。

JIRA にはたくさんの CI が設定されています。私たちは、およそ 60 個ほどの別々の設定、別々のブランチからなるビルドプランを動かしています。

私たちは他にもいくつか依存関係も抱えていました。JIRA のリリースプロセスは複雑で、複数のソースリポジトリからコードを集めてひとまとめにしているのです。それだけではなく、我々はお客様に対してソースコードも公開しています。そして、そこには様々な組み合わせのビルドスクリプトも含まれているのです。

どれだけ早く移行できるのか、と、どれだけ安全に移行できるのか、という問題の間にはトレードオフが存在します。そして私たちは、早さよりも安全さに最適化する方針をとっていました。移行のための期限を決めてそこから遅れそうになったとしたら、最悪の事態として何が引き起こされることになるのでしょうか?開発者たちが、あと 1 週間ほどの間、コードをコミットする先が SVN になります。ただそれだけのことです。世界が終わってしまうわけではありません。移行による割り込みで、開発者が期限に間に合うように仕事をすることが妨げられるなら、そちらのほうがはるかに悪いことなのです。
最終的に、移行には 14 日間かかりましたが、開発者がコードをコミットできないのは合計で 2 時間だけでした。最新版である JIRA 5 の開発完了間近でしたが、リリース候補版を切り出すことのできない瞬間はまったくありませんでした。

準備

移行のための準備には、いくつか注意すべき点があります。

まず最初に、準備には時間がかかります。実際のところ、git-svn clone が SVN リポジトリから全てのコミットを取得して、Git に複製するために3 日間もかかりました。
2 つ目に、あなたのインフラストラクチャが VCS に対して持っているあらゆる依存関係について検討しておかなければなりません。そして、あなたのインフラストラクチャが(我々のように)複雑に絡まり合っているのなら、まさかそんなものがあるとは夢にも思わず、壊れて初めてわかるようなものが存在するのだということを理解しましょう。ドラゴンに出くわしたからといって、そう自分を責めるものではありません。さっさとやっつけて、あなたの冒険を続けましょう。

このように、この種の移行はあなたが一晩かけたところで、たとえ週末を使ったとしても、終わるものではありません。続けられる程度に区切った時間で管理する必要があります。

移行の技術的側面

移行が簡単というわけではありませんが、脳手術ほど難しいものでもありません。アトラシアンは移行を管理するためにあるプロセスを採用しました。アトラシアンの「 SVN から Git へ 」シリーズ第 2 弾では、Subversion から Git への移行に関する概要、手順、技術的な詳細などを紹介します。

SD Times ウェビナー:自社に Git を導入しよう

自社に Git を採用する意味は何でしょうか。そのメリットやトレードオフは?あなたの組織において、どのように新しい仕事の仕方を採用すればよいでしょうか?そして、従来とは異なるソフトウェア構成での作業に伴うリスクをどのように制限したらよいでしょうか。あるいは、バージョン管理の新しいやり方について、エンジニアの教育は?どのようにノウハウをためたらいい?必要なサポートを得るには?

アトラシアンと大手オンライン旅行会社のOrbitzがGitへ移行するために何をしたのか直接聞いてみませんか。 1/23(水) 12:30 PST(US)に開催されるウェビナーにご参加ください。

(翻訳協力: グロースエクスパートナーズ株式会社)