SVN から Git へ : Atlassian がどのように進行中の開発案件を犠牲にすることなく切り替えを行ったか – 技術面

2013-01-24 (Thu)  •  By 伊藤  •  活用のヒント  •  DVCS Git 翻訳

今回の記事は、Git に関するアトラシアン ブログ「From SVN to Git: how Atlassian made the switch without sacrificing active development – the technical side 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

今回の記事は、Dr. Dobb’s 誌で特集された企業での Git への切り替えに関する三部構成のシリーズの第 2 弾です。第 1 弾では、多くのチームが何故今切り替えを行う決断をしたか について取り上げました。今回の記事では Atlassian が実際に Git への切り替えをどのように行ったかを技術面に焦点を当てて紹介します。

今回の記事は 3 回にわたって Atlassian が行った最大の移行作業、11 年分の JIRA コードベースを SVN から Git に移行する作業についてご紹介します。どのような障害があったか? どのような教訓を得たか? そして最も重要な事項として、JIRA で進行中の開発案件を犠牲にすることなくどのように移行を行ったか? この経験が似たような移行作業を行おうとしている皆さんのお役に立てれば幸いです。

JIRA が Git に移行済みのため Git に焦点を当てますが、このシリーズ中の内容はすべて Mercurial にも適用できます。Atlassian では両方利用しています。

移行 — 技術面

安定的な移行は手強い挑戦ではありますが、脳外科手術のような難しさがあるわけではありません。Atlassian が採用し、移行を行いやすくしたプロセスがあります。

1. レポジトリを Git に複製

まず、Git レポジトリの場所を選択します。私たちが JIRA を移行したときは、社内でホストしている SVN レポジトリからクラウドの非公開 Bitbucket レポジトリに移動することにしました。このやり方は私たちにはしっくり来ました。弊社のチームはシドニー、グダニスク、サンフランシスコと地理的に散らばっているため、自宅で勤務している人はコミットしやすくなります。さらに、Bitbucket は弊社の DVCS コード ホスティング製品であるため、社内の “自社製品活用” の慣行の一環でもあります。また、弊社のファイアウォールを介した Git レポジトリ マネージャーである Atlassian Stash にレポジトリをミラーリングしました (これも “自社製品活用” の目的です)。とは言え、このガイドはホスティングの場所や方法にかかわらずあらゆる Git レポジトリに対して適用できます。

コードの新しい家ができたので、そこに移動できます。(全員分のピザとビールをお忘れなく。) git-svn クローンを使用して SVN レポジトリを Git に複製することをお勧めします。

SVN-Git クローン

基本的に、git-svn クローンを行うのはローカル マシン (デスクトップまたは共有マシン) に中間レポジトリを作成するためです。その後、この中間 Git レポジトリから使用する ‘本物’ の Git ホストにプッシュします。全インフラおよび開発者は中間レポジトリではなく、この ‘本物’ の Git ホストに対して読み書きします。

ここが移行の最も技術的に難しい部分です。この部分にのみ焦点を当てた記事を 1 本執筆できるぐらいです。実際、Stefan Saasen 氏 (Atlassian Stash の開発リーダー) が これに関する素晴らしいガイド を作成しています。

2. SVN から Git へのミラーリング

移行の完了後 (JIRA の初回 git-svn クローンの実行には 3 日掛かりました)、各コミットを SVN から Git にミラーリングするスクリプトをセットアップします。私たちが使用したスクリプトのバージョンは こちら です。

アドバイスとしては、ミラーリング スクリプトを実行するユーザー以外に対しては全員 Git レポジトリを読み取り専用にすることです。Git レポジトリに対して直接コミットし始める熱心な開発者がいると、ミラーリング スクリプトはマージの競合に遭遇し、手動で解決せざるを得なくなります。これはなんとしてでも避けてください。

移行のこの段階では各開発者はまだ SVN にコミットしており、インフラもすべて SVN から読み取りを行っています。

3. インフラの移動

次の段階では、インフラを SVN から Git に反復的にカットオーバーします。

カットオーバー

この手順はかなり時間が掛かります。反復的にカットオーバーし、各インフラをテストします。弊社で行った手順は以下のとおりです。

  1. Git レポジトリにポイントするようにコード レビューを変更します。FishEye/Crucible (弊社の Web ベースのコード レビュー ソフトウェア) は任意のバージョン管理システムでレポジトリを追加しやすくします。開発者は Git に対してコード レビューの作成を開始し、この時点で実際の Git レポジトリに初めて触れることになります。次に、
  2. SVN ビルドと並行して Git レポジトリから実行する複数の CI ビルドを複製します。

私たちはこの 2 つの大きな変更をしばらく様子見し、以下のようなその他の技術的変更による問題に対処しました。

  • リリース プロセスの更新
  • ソース ディストリビューションの更新。JIRA の各リリースでソース コードをリリースしているため、このプロセスを変更して Git レポジトリからソースをリリースするようにしました。
  • ビルド バージョン。JIRA の各ページのフッターに実行中のバージョンが表示されますが、これを Git ハッシュに変換する必要があります。
  • 内部ツーリング。JIRA にはレポジトリから更新したときに再コンパイルの必要があるサブモジュールがあるかどうかを確認する更新スクリプトがあります。

この方法では、移行全体に影響を与えることなく 1 つの変更を元に戻すことができます。この手順をすべて終えるとインフラはすべてGit から動作するようになりますが、開発者は引き続き SVN にコミットします。

カットオーバーの準備ができる頃には、上記の変更をすべて 1 週間以上様子見し、いくつかの問題を修正しました。チームが一度 SVN から Git へのカットオーバーを決めたら、問題が発生したときの費用や手間をやりくりできる状態でいなければなりません。

4. カット オーバー

全インフラが移動したら、最終カットオーバーの準備は完了です。開発者は SVN ではなく Git にコミットすることになります。

最終カットオーバー

いくつかアドバイスを。

  • 今回の変更の日時を確実に組織全体に通達します。
  • 一定のタイミングで SVN レポジトリを読み取り専用にします。カットオーバーの完了後に開発者が SVN にコミットを行ってしまうと、Git レポジトリにそのコミットを手動でマージするという計り知れない苦痛な作業が発生します。
  • SVN レポジトリを読み取り専用にしたら、最後にもう一度だけミラーリング スクリプトを実行して最後に残ったいくつかのコミットを拾い上げます。
  • Atlassian での各移行作業において、私たちは読み取り専用の SVN レポジトリを常に稼働状態にしておくことにしました。これにより、SVN の何かにポイントしている可能性があるものとのつながりが途切れます。たとえば、コード レビューでの SVN リビジョン番号へのリンク、またはソースからビルドするコードの古いブランチなどです。

これで Git から実行できるようになりました。

移行 — 人的側面

技術的側面からは、非常にスムーズな移行を実行し、コミットのダウンタイムを抑えてインフラの高可用性を保つことができることがお分かりいただけたと思います。しかし、開発者たちは変化に対する準備ができているでしょうか? このブログ シリーズの次回の記事では、Git への切り替えの際の人的側面について取り上げます。

SD Times ウェビナー : 企業における Git の導入

組織で Git の導入をご検討ですか? Atlassian とオンライン旅行業界におけるリーディング カンパニー Orbitz がいかに Git への移行を行ったかをじかに聞いてみましょう。1 月 23 日 (水) 12:30 PST (米国時間) に開催されるウェビナーにどうぞご参加ください 。内容は以下のとおりです。

  • 移行の費用対効果
  • Git への移行管理の “ハウツー”
  • 効率性、俊敏性、およびコントロールにおける ROI の向上

Related Articles

お気軽にお問い合わせください

お問い合わせ