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

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

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

今回の記事は、Dr. Dobb’s 誌において Git への切り替えを行うエンタープライズ チームに注目したシリーズの一部です。

Atlassian では何年も前から DVCS を非常に愛用してきました。また、DVCS への多大な投資も行っています。クラウド DVCS レポジトリ ホスト である Bitbucket を買収したり、ファイアウォール越しの Git レポジトリ マネージャー Stash を開発したりしました。さらには、コード閲覧および検索ツール FishEye に DVCS サポートを追加しました。また、課題追跡ツール JIRA に数え切れないほどの DVCS コネクタを追加してきました。

弊社は DVCS がソフトウェア開発を大きく前進させたと信じており、その中で弊社の製品やライブラリのコードベースを中央バージョン管理システム (通称 SVN) から DVCS に移行しました。かなり大規模な移行作業になったこともありました。今では DVCS への移行はお手の物です。

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

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

DVCS を使用する理由

大規模なコード ベースの移行には代償が付きものです。自分自身、自分の上司、さらには同僚たちに対して答える必要のある第 1 の問いは、DVCS が何をもたらしてくれるか、移行の代償に見合うものか、ということです。

私は多くのプロジェクトで SVN を問題なく使用してきました。Atlassian も同様です。また、この記事を読んでいる皆さんの多くも SVN を問題なく利用してきたと思います。移行の代償は常に付きものであるため、「これまで何年も Subversion が自分のバージョン管理ニーズを満たしてきたのに、今さら変えなくてはいけないのは何故?」と疑問に思うでしょう。私にしてみれば、これは間違った質問です。正しい質問は、「今できていることをどのように DVCS がさらにより良いものとしてくれるか」です。

Git はさまざまなことで知られています。コードを扱う開発者にとっては高速である点が知られています。Git では機能ブランチ、フォーク、およびプル リクエストなどの高度なワークフローが可能です。理論的にはこれらのワークフローはすべて SVN でも可能ですが、Git と比べて SVN でのマージの難しさは受け入れがたいものがあります。しかし、SVN からの移行を計画している人にとって、Git の主な利点はその軽量なブランチ機能と簡単なマージのおかげで、既定の SVN ワークフローを SVN よりもうまく行えることです

どのような意味か? 弊社が実際にどのようにソフトウェアを開発し、リリースしているかについてお話しましょう。ほとんどの方はソフトウェアのリリース済みバージョンが少なくとも 1 つある状態で作業していると思います。これを “安定” ブランチと呼びます。”開発” ブランチ (使用している VCS によってはトランク/マスター/既定とも呼ばれます) で新機能を開発しながら、安定ブランチにバグ修正を盛り込みます。

ブランチ

安定ブランチにバグ修正をコミットする際、マスターにも含める必要があります。SVN マージは面倒なことで知られており、実際のコンテンツではなくリビジョン履歴でのみ機能します。結果として多くの人がこれを避けて多用しないようにしたり、日々のワークフローの一部に含めなくなります。安定ブランチと開発ブランチが分岐を始め、その分岐が広がりすぎて一箇所に戻すのが困難になるようなプロジェクトにいくつ関わってきましたか? これが起こったプロジェクトを私は確実に経験してきましたし、他の開発者たちの話を聞いても SVN でよく起こることのようです。これに対処するにはいくつかの戦略があります。たとえば、弊社の課題追跡ソフトウェア JIRA ではマージを無視し、各安定ブランチと開発ブランチに個々にコミットを行って、正しく行われたかどうかを QA に委ねます。

Git を利用するとこうした苦痛を取り除いてくれます。Git ではマージが非常に簡単に行えるため、安定ブランチ全体をコミットごとに開発ブランチにマージすることが現実のものとなります。これが私たちの既定のワークフローです。そのため、機能ブランチやフォーク、プル リクエストを今すぐに使用したくない場合でも、Git は導入 1 日目からメリットをもたらしてくれます。

そして準備が整ったら、Git が可能にする高度なワークフローを利用できる立場にいることができます。DVCS に切り替える前は、弊社の主要製品は 90 日のリリース サイクルを目標にしていました。この 90 日リリースは 2 つのプラットフォームに適用されました。クライアントが自身のサーバーにインストールするダウンロード製品と、クライアントが毎月手数料を支払って利用するホスト型クラウド プラットフォーム (Atlassian OnDemand) へのリリースです。開発ワークフローの中核部分としてブランチを使用することで、主要製品を 2 週間おきにクラウドにリリース できるまでに短縮できるようになりました。

切り替え作業

JIRA には 11 年分の履歴があり、約 21,000 ファイルにわたって47,228 件のコミットがあり、移行対象としてはかなり大きなコード ベースです。2 週間の間に平均して約 30 名のコミッターが参加します。さらに、VCS は JIRA のようなプロジェクトにとっては真の主力製品になります。製品ディストリビューションとソースの両方のリリースのためのビルド、コード レビュー、スクリプト。これらはすべてソース コード管理システムに大きく依存します。

移行における主な目標は、開発者の作業中断を最小限に抑えることでした。これはコードをコミットできるかどうかだけではなく、ソフトウェア開発を取り巻くインフラに関するものです。

FishEye-Crucible SVN 移行

弊社は JIRA のコード レビュー システムに 3.5 年分の履歴を持っています。

Bamboo SVN 移行

JIRA には CI が多数登録されています。弊社ではさまざまな構成やブランチで約 60 のビルド プランを実行しています。

これ以外の依存関係もあります。JIRA のリリース プロセスはやや複雑で、複数のソースからコードをプルする必要があります。また、ソース コードを顧客にリリースしており、これには異なるセットのビルド スクリプトが関わってきます。

ここで、いかにすばやく移行できるかとどの程度安定的にそれを行えるかの間でトレードオフが生じます。原則として、私たちはスピードよりも安定性を訴求しました。移行の期限を設定してそれが延びた場合、最悪のシナリオとして何が起きるでしょうか? 開発者はもう 1 週間かそこら SVN にコードをコミットすることになるだけです。この世の終わりということではありませんね。移行によって開発者が作業できずに締め切りに間に合わないような事態の方がずっと深刻です。

最終的に移行は 14 日間かかり、開発者がコードをコミットできなかったのは合計で 2 時間だけでした。このとき、弊社の最新リリースである JIRA 5 の開発サイクルの終盤に差し掛かっており、リリース候補を出せないという状況は一度もありませんでした。

準備

移行を準備するにあたり、気を付けるべき点がいくつかあります。

1 点目として、移行には時間がかかります。SVN レポジトリの全コミットを取得して Git にレプリケートする実際の git-svn クローンは 3 日間かかりました。

2 点目に、お使いのインフラが VCS に対して依存しているものをすべて考え、準備することです。さらに、皆さんのインフラが弊社のインフラと同様に複雑なものである場合、夢にも思わなかったようなことが起こりうること、問題が出てから初めて分かる可能性があることを知ることです。ですから、ドラゴンに遭遇したときに自分を責めることはしないでください。討伐してそのままクエストを続けてください。

このような移行作業は一晩でできるものではなく、週末中にできることでもありません。一定の期間かけて管理する必要があります。

移行の技術面

安定的な移行は手強い挑戦ではありますが、脳外科手術のような難しさがあるわけではありません。Atlassian が採用し、移行を行いやすくしたプロセスがあります。Subversion から Git への移行の技術的な詳細や順を追った移行手順については、Atlassian の Git への移行シリーズの第 2 部でご紹介します。

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

企業において Git を導入した際の影響は? 利点とトレードオフは? 企業がどのように新しい業務モデルを採用し、非従来的なソフトウェア構成で作業する際のリスクを軽減できるか? どのように開発者を “再教育” し、知識を伝達し、必要なサポートを得るか?

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


Related Articles

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

お問い合わせ