*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 1 月 22 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Technical Side"
このポストは、エンタープライズ開発のバージョン管理を Git に切り替えることに注目した連載記事（全三回）のうちの第二回目として、 Dr.Dobb's で紹介されました。最初の記事では、 今日、これほど多くのチームが切り替えを決断している理由 について議論しました。今回の記事では、アトラシアンが行った Git への切り替えにおける技術的な側面に焦点を合わせています。
この三部からなるブログシリーズでは、アトラシアンが行った最大の移行に注目します。これは、11年も蓄積された JIRA のコードベースを SVN から Git に移行するというものでした。私たちの前に立ちふさがった障害は何だったのか？私たちが学んだ教訓とは？そして最も重要なこととして、いかにして進行中の JIRA の開発を妨げることなく移行したのか？この経験を共有することで、同じような移行を行おうとしている人の助けになればと思います。
ここでは Git に注目します。それは JIRA を Git に移したからですが、このシリーズに書かれている内容はすべて Mercurial にも当てはまります。アトラシアンでは、 G i t と Mercurial の両方を使用しています。
移行の技術的側面
移行が簡単というわけではありませんが、脳手術ほど難しいものでもありません。アトラシアンは移行を管理するために、あるプロセスを採用しました。
1. Git へのリポジトリの複製
まず、 Git リポジトリの置き場所を選択します。私たちが JIRA を移行した際は、社内でホスティングしていた SVN リポジトリを、クラウド上の Bitbucket のプライベートリポジトリに移すことにしました。これは私たちにとってはとても都合のいいものでした。私たちのチームメンバーはシドニー、グダニスク、サンフランシスコというように地理的にバラバラな場所に住んでいたからです。それに加えて、在宅勤務をしていてもコミットが簡単にできるようになりました。また、 Bitbucket を選んだことは、社内で実施している「ドッグフーディング」プラクティスの一環でもありました。 Bitbucket も、私たちの DVCS コードホスティング用製品なのです。私たちはリポジトリを Atlassian Stash （社内のファイアーウォールの内側に配置した Git リポジトリ管理ツール）にもミラーリングしました（これも、ドッグフーディングのためです）。つまり、このガイドはどんな種類の Git リポジトリ（どうやってホスティングされていても、どこでホスティングされていても）を使う場合でも利用できるのです。
さて、あなたのコードのためにピカピカの家ができました。もう入れます。（お客さんのためのピザとビールの用意を忘れないでください。）そして、念のため、 git-svn clone によって SVN リポジトリを複製することをおすすめします。
基本的には git-svn clone を使って、ローカル PC 上に中間リポジトリを作りたいと考えるでしょう（それはデスクトップ PC かもしれないし共有 PC かもしれません。私たちは壁際に置いてあった PC を使いました）。その上で、中間の Git リポジトリから、「本物」の Git リポジトリにプッシュするのです。すべてのインフラと開発者は、この「本物」の Git リポジトリを読み書きするようになります。中間リポジトリではありません。
これは移行の中でも最も技術的な部分です。記事全体をこの部分だけで書き尽くすこともできます。実は Stefan Saasen（ Atlassian Stash の開発リーダー）が 素晴らしいガイド を書いてくれています。
2. SVN から Git へのミラー
移行が完了（ JIRA を git-svn clone するのに3日かかりました）したら、 SVN へのコミットをすべて Git へミラーリングするためのスクリプトを準備します。私たちが使ったバージョンのスクリプトは ここ で公開しています。
ミラーリングスクリプトを実行したユーザー以外からは Git リポジトリを読み取り専用にしておくことをお勧めします。もし Git リポジトリへ直接コミットし始めてしまうような貪欲な開発者がいると、ミラーリングスクリプトがマージ競合に出くわしてしまうかもしれません。そうすると、あなたが手作業で競合を解消する羽目になってしまいます。何としてでもそんな事態は避けましょう。
移行のこの段階では、開発者は全員、まだ SVN にコミットしていますし、すべてのインフラはまだ SVN を参照しています。
3. インフラの移行
次の段階では、インフラの SVN から Git への移行を反復的に実施していきます。
この手順にはとても時間がかかります。反復的に切り替えながら、インフラの各部分をテストします。私たちが行った各手順は次のとおりです。
- Git リポジトリを指すように Code Reviews を変更します。 FishEye/Crucible （私たちの Web ベースのコードレビューソフトウェア）のおかげで、どんなバージョン管理システムでもリポジトリとして追加するのは簡単でした。開発者は Git を使ってコードレビューを始めました。そこで初めて「本物」の Git リポジトリに触れたのです。それから
- SVN ビルドと並行して Git リポジトリからも実行できるように、 CI ビルドをいくつか複製します。
私たちはこれら二つの大きな変更を吸収しつつ、それ以外の技術的な変更を行い続けることによって生じる課題に対処しました。
- リリースプロセスの更新
- ソース配布物の更新。 JIRA のリリースごとにソースコードを公開するので、 Git リポジトリからリリースするソースコードを取り出すように、プロセスを変更しました。
- バージョンごとのビルド。 JIRA の各ページのフッターには、稼働しているバージョン番号が表示されます。これは Git のハッシュに変換する必要がありました。
- 内部ツールの変更。 JIRA には、リポジトリからローカルコピーを更新したとき、サブモジュールを再コンパイルする必要があるかどうかをチェックするための更新用スクリプトがあるのです。
このやり方なら、どんな変更であっても、全体としての移行に影響を与えることなく、巻き戻すことができるようになります。この手順が終わる頃には、全てのインフラが Git を参照している状態になります。ただし、開発者たちはまだ SVN にコミットしています。
切り替えのための準備ができるまで、私たちは上記のような変更を一週間以上受け入れつつ、いくつもの問題を修正してきました。あなたのチームが SVN から Git へ切り替える決定をしたなら、さまざまな課題を解決して前に進むためのコストは管理できるということをチーム全員が認識しなければなりません。
4. 切り替え
全てのインフラが移行できたなら、移行は最終段階です。開発者たちに SVN ではなく Git にコミットさせるようにしましょう。
いくつかアドバイスしておきます。
- 組織全体に向けて、切り替えを実施する期日をはっきりと大々的に宣言しましょう。
- 切り替えを実施したら、 SVN リポジトリは読み取り専用にしましょう。切り替えの完了後も SVN へのコミットが行われるようだと、あなたはそれらのコミットを手動で Git リポジトリへマージするという言いようのない苦痛を味わうことになります。
- SVN リポジトリを読み取り専用にしたら、最後にもう一度ミラーリングスクリプトを実行しましょう。
- アトラシアンにおける移行では、読み取り専用になった SVN リポジトリはそのまま残していました。こうしておくことで、 SVN リポジトリ内の何かを参照しているかもしれないものが壊れないようにできました。例えば、コードレビューに含まれる SVN リビジョン番号へのリンクや、非常に古いコードから作られるブランチなどです。
おめでとう！あなたのところで Git が動き始めました。
移行の人間的側面
技術的な側面だけ見れば、移行を非常に滑らかに実施できることが分かったと思います。コミットできない時間を最小化しつつ、インフラの高可用性を保証できるのです。ですが、開発者たちは準備できているのでしょうか？この連載記事の次稿では、Git に切り替えることの人間的側面について議論します。
SDタイムズウェビナー：自社に Git を導入しよう
エンタープライズで Git を採用したいとお考えですか？アトラシアンと大手オンライン旅行会社の Orbitz が Git へ移行するために何をしたのか直接聞いてみませんか？ 1/23（水） 12:30 PST（US） に開催されるウェビナーにご参加ください。 以下について学べます。
- 移行のための費用対効果分析
- Git への移行を管理するための “How-to”
- 効率的で俊敏かつ管理可能な ROI の開発
(注: ウェビナーは終了しています。後日ビデオを公開する予定です。)
(翻訳協力: グロースエクスパートナーズ株式会社)