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

2013-02-13 (Wed)  •  By 伊藤  •  活用のヒント  •  DVCS Git 翻訳

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

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

この 三部構成のブログ シリーズ では、Subversion から Git への JIRA コード ベースの移行について焦点を当てます。進行中の開発案件を犠牲にすることなく大規模なプロジェクトを Git に移行することを検討している方たちのために、弊社での移行体験をご紹介したいと思います。第 1 弾では、私たちが何故 Git に切り替える決断をしたか について取り上げました。第 2 弾では Subversion から  Git に切り替える際の技術的な側面 について焦点を当てました。今回の第 3 弾では移行の “人的側面” についてご紹介します。

移行 – 人的側面

技術的側面からは、コミットのダウンタイムを抑えてサポート インフラの高可用性を保証しつつかなりスムーズな移行ができることがお分かりいただけたと思います。では開発者たちは変化に対する準備ができているでしょうか?

移行に対する JIRA 開発者の意見はさまざまです。「Git は JIRA に起こった最も素晴らしいことだ」、「Git が SVN より優れているのは分かっているけど、トレーニングが必要だ」といった意見から「今 SVN でできることを Git でどうやるのか教えて欲しい」といったものまであります。こうしたさまざまな反応を見せる開発者たちのニーズに対応するのは非常に重要です。

私自身は開発者です。使用する VCS は (プログラミング言語、IDE、フレームワーク、およびライブラリなどの中核的なものと同様) コア ツールの 1 つであり、自分のスキルを磨くキーとなる領域の 1 つです。自分が使用する VCS は技術的な連絡や協同作業の手段です。開発者の潜在能力を最大限引き出すために、全員が同じ意識を共有していることを確認することが必要です。開発者が使用するツール、特に VCS について不安に思っていると、それが作業の大きな妨げになりえます。Atlassian はオープンであることに誇りを持っています。何の声も上げないよりも声を上げることをスタッフに奨励しています。私自身、スタッフたちが違和感を持つ問題について何も語らずに意見を押し殺しているような職場で働いた経験があります。

また、有能な開発者たちは自分が作成するコードとそのインフラに強い結びつきを感じます。生産性の高い開発者たちは自分の環境を自分のものにしているという意識を持っています。VCS ツールのように、その環境を変えてしまう場合は自分が大切にしているものを変える必要があります。

1. チームにトレーニングが必要

移行完了後に組織の誰もがすぐさま Git を使いこなせるようになると仮定するのは失敗の元です。Git は根本的に SVN とは異なります。このことを意識すること、開発者たちに意識してもらうこと、そして Git に対する心構えを持ってもらうことが移行を成功させるために重要なことです。

開発者が Git に慣れてもらうために弊社がまず行ったことは、Git のトレーニング セッションを開催することです。たとえば、「SVN でやっていたことを Git でどのようにするか」というテーマから始めました。そこでは、コミットなどを行う際の Git コマンドを紹介したり、どのようなツールを利用できるかを説明しました (Atlassian の開発者は IDE、SourceTree、gitg や、Git で動作するコマンド ラインを使用します)。さらに重要なこととして、SVN と Git 間の主な違いを説明するのに時間を割きました。リモート レポジトリのクローンであるローカル レポジトリを持つのはどのような意味があるのか? 作業コピーとは何か? ステージング エリアとは? 最後に、Git レポジトリのクローンを作成するための手順書と、作業を始めるためのガイドを作成し、エクストラネットで公開しました。

さらに、弊社の Confluence アーキテクトである Charles Miller 氏が Git の内部の仕組み (内部でどのようなデータ構造を使用しているか、作業のコミットなどの実際の操作がどのように行われるか) に関する深く掘り下げたセミナーを開催しました。これはすべての開発者にとって自由参加のセミナーでしたが、詳細部分の理解を深めた開発者もいました。また、深く掘り下げれば掘り下げるほど、Git がいかに洗練された内部アーキテクチャを持ち、コンピューター科学者にとっていかに学ぶ価値があるかが分かります。

弊社はこれらのトレーニング セッションを社内で開発しましたが、ご希望であれば社外の Git トレーニングを受けることもできます。

2. チームに移行の進捗を報告

移行の実行中、メールや弊社のリアルタイム グループ チャット ツール HipChat で移行ステータスをチームに状況報告していました。マイルストーンに達するたびにチームに報告しました。インフラを変更したときもそのたびにチームに報告しました。何か問題が発生したときの警告の意味もありますが、状況がどうなっているかを逐一知らせる意図もあります。チーム メンバーに「さっき君が作成したコード レビュー、Git レポジトリから作成したんだよ」と伝えるときは何とも嬉しい気分になります。変更期間中に何も問題が起きずにやり通したときは特にそうです。このチーム内からの定期的なコミュニケーションは、各開発者が常に最新情報を受け取っており、変化に関わっていると感じられる点において大きな意味を持ちます。最悪の結果は、この変更が外から強制されたものであるとチームが感じたり、彼らが毎日使用するツールが知らぬ前に変更されてしまうことです。

3. チームには “Git マスター” が必要

もう一度言います。Git は SVN とは違うものであり、適応するには時間がかかります。どれほど準備したり教育しても、開発者が実際に使い始めるときに問題にぶち当たることがあります。こうした問題を放置しておくと、生産性が落ちたり変化に対する敵意が生まれます。

移行後、私たちは Git 経験のある数人の開発者を “Git  マスター” に指名しました。問題が発生したり理解できないことがあったり、「今やった操作は何だろう?」「その仕組みは?」など単に知りたいことがある場合に、Git マスターを連れてきて助けてもらうことができます。これは変化を可能な限りシームレスにするために重要なことです。

実際、主にスタッフがぶちあたる壁はコマンドの違いではなく、作業コピー、ローカル レポジトリ、およびリモート レポジトリの概念モデルの違いにあります。開発者たちは SVN モデルを習得していました。それぞれの開発者が同程度の習熟度を Git で達成するには 2-6 週間かかると思います。

4. あまりに多くのワークフローを急激に変更しないこと

DVCS の “D” を司る高度な Git ワークフローがいくつか存在します。ブランチ、機能ブランチ、フォーク、およびプル リクエストはほんの始まりに過ぎません。移行と同時にこうした高度なワークフローに切り替えようとしている場合、あなたはノーベル賞受賞者のチームを率いるアルバート アインシュタインか、自ら落ちるための穴を掘っていることになります。弊社は “安定性を通した成功” の原理をワークフローにも取り入れ、SVN で使用したものとまったく同じワークフローで始めました。

  • バグ修正用に 1-2 の安定ブランチ、および
  • 新しい開発作業用のマスター ブランチ

上に述べたとおり、安定ブランチからトランクにバグ修正を移動するための SVN ワークフローは、手動で各コミットにパッチをあてることでした。Git に初めて移行するとき、このワークフローをそのまま使用しました。各バグ修正コミットは手動で選定されてマスターに含められます。このようにするのは何故か? Git はマージを行うよう設計されています。それが移行を行う理由の 1 つではないのか? 安定性を保つため、Git への変更自体が開発者にとって十分大きな変更であり、ワークフローを変更することは状況をさらに複雑にするものでしかないと考えました。

5. 小規模の反復的なワークフロー変更を

弊社での初めてのワークフロー変更は移行の 2 ヶ月後に行いました。自分で選んで移動する作業はもう行いません。各コミットごとに安定ブランチをマスターにマージします。

ここでもまた、今回の変更をチームに伝えることに時間を費やしました。変更の動機やそのための一連の手順などです。再度 Git マスターを召集して、問題を抱えているスタッフの支援を依頼しました。最終的に移行はスムーズかつ簡単に終わりました。小規模の理解しやすい反復的な変更を行うことが、各変更を成功に導きます。

現在の状況 – 分散 VCS、分散開発

マージのワークフローに慣れてきた時点で、Git が可能にする分散ワークフローを取り入れ始めました。

記事の最初で、弊社の主要製品の 1 つである JIRA が 2 週間ごとに弊社のホスト型プラットフォームにリリースされていると述べました。弊社では別々の支社に別々のチームを編成する傾向にあります。チーム間の作業をお互いから切り離すことで、頻繁なリリースを可能にしています。

  • 毎日の作業レベルでは、各チームの変更は他のチームに影響を与えることはありません。チーム A がビルドを壊しても問題はありません。彼らの変更は自分のチームのみに隔離されます。壊れるのは自分たちのビルドだけで、他のチームの開発スピードは影響を受けません。
  • 2 週間のリリース レベルでは、リリース基準を満たせなかったチームがあってもリリースには影響しません。チーム B がストーリーをすべて完成させなかった場合、イテレーションの最後でマージしません。リリースはチーム B 以外の全員のストーリーに基づいて進められます。

ただし、これ自体問題を生み出すことになります。イテレーションの最後に複数の変更セットをマージすると、統合の競合のリスクが発生し、バグを引き起こすことになりかねません。実際のところは、個々のチームがコード ベースの別々の領域を担当していることが多いので、こうした状況は軽減されます。しかし、チームが他のチームと競合しがちな領域を担当している場合、マスター ブランチで直接作業する傾向があります。個々のブランチで作業しているチームはこれらの変更を定期的に得るためにマスターから頻繁にプルし、深刻になる前に競合を把握します。今までのところ、意思疎通を頻繁にすることでこの種の競合が問題になるのを防いでいます。

別の複雑な要因として、地理的距離が挙げられます。JIRA のメインの開発はシドニーとグダニスクで行われますが、サンフランシスコ、ボルダー、またはアムステルダムの Atlassian チームからのコミットがいつあるか分かりません。別の都市のチームは別のブランチで活動している傾向があるので、コミュニケーション ギャップを埋めることができます。上に述べたような競合の可能性を伝えるために、1 対 1 のコミュニケーションやグループ通知に HipChat (弊社のグループ チャット製品) を使用しています。これは地理的に分散したチーム メンバーには非常に良く機能します。リアルタイムのチャット ルームで会話がそのまま残るため、別のタイムゾーンからの人がログオンした場合、会話の状況を確認してすばやく話についていくことができます。チャット ルームで開発者の名前が挙がるとその人に ping が送られ、会話全体を読み返さなくても誰かの質問にすぐに対応できます。

ブランチ戦略について一言。一部の人は、各ストーリーが機能ブランチで開発される ‘機能ごとのブランチ’ ワークフローを推奨しています。これは自分のプロジェクトに当てはまる場合は素晴らしいワークフローです。Atlassian の一部の製品ではこれを使用しています。JIRA では CI のオーバーヘッドは非常に高いです。開発対象の各ストーリーで ‘適度’ な CI を実行することは現実的な範囲内にあるものではありません。しかし、チームごとに 1 つのブランチというスタイルはうまくいきます。

成功

移行は大成功に終わりました。開発者がコミットできない無駄な時間は発生しませんでした。CI は継続的に実行され、移行の全過程を通して 5.0 のリリースを行える状態を維持できました。移行後、私たちは各変更にうまく対処し、開発者たちは今では DVCS の機能を十分に堪能しています。その証明として、弊社のリリースのテンポが完全に変わりました。DVCS なしでは 90 日のリリース サイクルから 14 日にシフトすることは到底かないませんでした。

これでもう 5 回目になると思いますが、開発チームへのコミュニケーションの重要性はいくら強調してもしすぎることはありません。移行中は、実際の技術的移行タスクよりもこの点に重きを置いてください。これにより開発者は変化を受け入れることができます。変化に対して消極的な開発者には意思疎通によって不安が解消され、Git を好きになってもらうことができます。やり方を間違えなければ、開発者から以下のようなコメントをもらうことになるでしょう。

Git の機嫌があまり良くなかったのでちょっと心配していたけど、スムーズに行きました。

結局のところこういう反応を求めていたんですよね?

切り替え

Git への切り替えをお考えですか? 切り替えの詳細については、以下を参照してください。

Git への切り替えの詳細


Related Articles

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

お問い合わせ