*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 1 月 31 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Human Side"
この記事は、エンタープライズ開発チームが Git に切り替えることに注目した連載記事の一つとして、 Dr. Dobb's で紹介されました。
この 3 部からなるブログシリーズ では、私たちが JIRA のコードベースを Subversion から Git へ移行したことに注目しました。私たちは、自分たちの移行で経験したことを、巨大なプロジェクトを Git へ移行することを検討している皆さんと共有したいと思っています。それも、進行中の開発を妨げること無く移行するやり方についてです。最初の記事では、 私たちがGitに切り替える決断をした理由 について述べました。二番目の記事では、 Subversion から Git への切り替えにおける技術的な詳細 を探りました。三番目、つまりこの連載の最終回では、移行における「人間的」な側面をどうやって管理したのかということについて述べていきたいと思います。
移行の人間的側面
技術的な側面だけ見れば、移行を非常に滑らかに実施できることが分かったと思います。コミットできない時間を最小化しつつ、インフラの高可用性を保証できるのです。ですが、開発者たちは準備できているのでしょうか？
JIRA 開発者たちの移行に関する意見は様々でした。「 Git は JIRA にとっていまだかつてないほどに素敵なものになる」から「 Git は SVN よりいいものだってことは知っていますが、私にはトレーニングが必要です」や「いままで SVN でやっていたことを Git ではどうやるのかやってみせて欲しい」まで。このようにあらゆる方面に渡る開発者たちのニーズに対応することが欠かせません。
私は一開発者です。あなたの使う VCS は、プログラミング言語や IDE 、フレームワーク、ライブラリといったものと並んで、あなたの開発にとって中核となるツールであり、これまであなたの磨いてきた開発スキルにとって、主たる分野の一つでもあるでしょう。あなたにとって VCS は、技術的なコミュニケーションやコラボレーションのためのツールなのです。あなたは、開発者全員が自身の可能性を最大に活かせるような環境を確保しなければなりません。開発者たちの使うツールが、何がしか不確実であったり、未解決の問題があったりすると、仕事が著しく妨げられてしまう可能性があります。 VCS の場合は特にそうです。アトラシアンは「オープンである」ことを誇りとしています。声に出して、その結果失敗することの方が、何も話さないことよりも推奨されるのです。しかし、仮に不満に思っていても、課題について話し合わずに隠してしまうような会社で働いていたことも私はあります。
また、有能な開発者というものは、自分の書いたコードや利用しているインフラとの結びつきを感じているのです。きわめて生産的な開発者たちは、自分たちの環境を所有していると感じています。VCSツールのような環境を変えようとしているなら、彼らがその変化を自分のものとし、受け入れてくれるようにしなければならないのです。
1. チームにはトレーニングが必要
組織内の全員が、移行が終わった後で普段の仕事をしながら Git のことを学習できると考えているなら、失敗は約束されたようなものです。 Git は根本的に SVN とは違うのです。それを意識し、開発者にも意識してもらうこと、そして Git を使う準備をしてもらうことこそが、移行を成功させるうえで欠かせません。
開発者たちに準備してもらうために、私たちはまず、数回からなる Git のトレーニングセッションを開催しました。具体的には、「 SVN で行なっていたことを Git で行うには」というセッションから始めました。このセッションでは、コミットのような Git コマンドを取り上げました。そして、 Git ではどんなツールが使えるのかを実演しました。（アトラシアンの開発者たちは、各々が選んだ IDE や SourceTree 、 gitg 、 Git と連携する CLI のコマンドを使っています。）とりわけ重要なのは、このセッションが SVN と Git の主たる相違点について説明することに集中していたということです。リモートリポジトリの複製をローカルリポジトリに持つとはどういうことでしょう？作業コピーとは？ステージング領域とは？最終的には、 Git リポジトリを複製してすぐに作業にとりかかるためのステップ・バイ・ステップガイドが紹介され、アトラシアンのエクストラネット (注：社内のオンライン コミュニケーション スペース) にも公開されました。
さらに、Charles Miller（当社の Confluence アーキテクト）は、 Git の内部動作についての詳細に踏み込んだセミナーを開催しました。内部的に使われているデータ構造や、コミットがどんな風に処理されているのか、といった内容のセミナーです。このセミナーには開発者全員が参加することができて、何人かが深く学んだことで移行を進める助けになりました。また、 Git について徹底的に掘り下げるほど、 Git の内部的なアーキテクチャが素晴らしくエレガントであることがわかるでしょう。このアーキテクチャを学ぶことは、あらゆるコンピュータ科学者にとって価値があるのです。
私たちは社内でトレーニングセッションを開発しましたが、 Git のトレーニングを行なっている会社はいくつもありますし、お好みで選ぶのもよいでしょう。
2. チームは移行の進捗度合いを知りたがっている
移行を進めている間、私たちはメールや HipChat （私たちのリアルタイムグループチャット）を使って最新の状況をチームに伝え続けて来ました。マイルストーンに到達するたび、それをチームに伝えるようにしたのです。インフラを変更したときは、いつもそのことをチームに伝えていました。何かが壊れてしまったときに警告するためだったこともありましたが、そうでなくても最新の進捗状況を伝えました。チームメンバーにこう伝えるときはうれしいものです。「やぁ。今、君が作ったばかりのコードレビューだけど、それは Git リポジトリを参照しているやつなんだよ」途中で何一つ失敗せずに変更できた場合などは、とりわけそうでした。チーム内で日常的に交わされるこうしたコミュニケーションは、それぞれの開発者が常に最新の情報を知らされていると感じ、変更を自分のものと感じるうえで大きな役割を果たしました。最悪なのは、チームが、外部から変更を強制されていると感じてしまったり、日々使っているツールが知らないところで変更されていると感じてしまったりすることなのです。
3. チームには ” Git チャンピオン” が必要
もう一度言わせてください。 Git は SVN とは別ものです。そしてそれを受け入れてもらうにはいくらか猶予が必要になります。どれだけ準備しても、どれだけ教育しても、実際に Git を使い始めると、開発者たちは問題に直面することになるのです。こうした問題を放っておくと、生産性を大幅に低下させ、変化に対する敵意を生み出す負の螺旋に陥ってしまいます。
移行のあとで、私たちは Git を経験したことのある開発者数人に ” Git チャンピオン” の称号を与えました。問題を抱えていたり、わからないことがあったり、単に知りたいことがあるなら、「どうすればいいの？」、とか、「これどうすればうまくいくの？」、といった風に ” Git チャンピオン” へ気軽に質問できるようにしました。これは変化をできる限りシームレスにするために欠かせませんでした。
実際のところよくつまずくことになるのは、コマンドの相違ではなく、作業コピー、ローカルリポジトリ、リモートリポジトリといった概念モデルに関する相違であることが分かりました。開発者たちは SVN のモデルを内面化していたのです。開発者が同じくらいの親近感を Git に持つようになるまで、 2 ～ 6 週間はかかったのではないかと思います。
4. ワークフローを急に変えすぎない
世間には、 DVCS に「 D 」(注：Distributed 分散) と入れさせるだけのことはある Git の先進的なワークフローがいくつもあります。ブランチやフィーチャーブランチ、フォーク、プルリクエストなどはほんの始まりにすぎません。移行と同時にこれらの先進的なワークフローに切り替えようというのは、アルベルト・アインシュタイン率いるノーベル賞受賞者チームでもない限り、失敗が目に見えています。私たちはワークフローを改善する際にも、「安定を通じた成功」の原則に従いました。まずは、 SVN の時とまったく同じワークフローから始めたのです。
- バグ修正のための安定版ブランチを一つ二つ
- 新規開発のためのマスターブランチ
前述したように、私たちの SVN のワークフローでは、安定版ブランチで行ったバグ修正の trunk への取り込みは手動で行っていました。 Git への移行の第一段階ではこのワークフローを引き継ぎました。個々のバグ修正は cherry-picked で master へ取り込むことにしたのです。このやり方にしたのは何故でしょうか？ Git はマージをしやすくするように設計されています。それこそが私たちが移行することにした理由の一つではなかったのでしょうか？物事を安定させておきたかったのです。 Git への変更はそれだけで開発者にとって十分に大きな出来事なので、ワークフローまで変えてしまうのは物事を複雑にしてしまうだけだと思いました。
5. ワークフローの変更は細かく、反復的に
移行から二ヶ月ほど経ってから、最初のワークフローの変更を行いました。もう cherry pick しなくてもよいのです。安定版ブランチはコミットごとに master ブランチへマージするようになりました。
繰り返しになりますが、私たちはこの変更についてチームとコミュニケーションすることに力を注ぎました。なぜ移行するのか、あるいは、移行するための一連の手順についてなどです。誰かが困っているときにはいつでも、手助けするために「 Git チャンピオン」を復活させました。移行は、スムーズで、簡単であることがわかりました。変更を細かく、わかりやすく、反復的にしたことで、一つ一つの変更がうまくいったのです。
開発現場の現在 – 分散 VCS と非中央集権的な開発
マージによるワークフローを確立した後、私たちは Git によって可能になる分散ワークフローに取り組みました。
最初の記事で言及したように、当社の主要製品の一つである JIRA は、今では対応しているプラットフォームすべてについて 2 週間ごとにリリースしています。当社では別のチームが別のブランチで作業することが多くなっています。分割されたチームがそれぞれ切り離して仕事をできるようにすることで、こうして頻繁にリリースできるようになっているのです。
- 日々のレベルでは、 1 チームの変更は他のチームに影響しません。チームＡがビルドを壊したら？何の問題もありません。彼らの変更は自分たちだけに隔離されています。彼らは自分たちのビルドを壊したというだけのことで、他のチームの開発スピードにはなんの影響もありません。
- 2 週間毎のリリースのレベルでは、たとえあるチームがカットオーバーできないとしても、リリースには影響しません。チーム B がすべてのストーリーをリリースラインに乗せられなかったなら、イテレーションの最後に彼らの仕事がマージされないだけです。リリース自体はチーム B のストーリーを除いて進められます。
このやり方には独自の課題があります。イテレーションの最後に複数の変更セットをマージすると、統合時に競合するリスクが生じます。これはバグの原因になり得ます。実際には、個々のチームがコードベース上の離れた領域で作業しているため、この問題はある程度緩和されています。しかし、あるチームが他のチームと競合しやすい領域で作業する場合、直接 master ブランチ上で作業することが多いようです。個々のブランチで作業しているチームは、定期的に master ブランチから変更をプルすることで、致命的な状況になる前に競合を検出しています。今までのところは、コミュニケーションラインをオープンに保つことで、こういった競合が問題化することを防いでいます。
もう一つ、問題を入り組んだものにする要因が拠点の場所です。 JIRA の主な開発はシドニーとグダニスクで行われています。しかし、サンフランシスコ、ボールダー、アムステルダムのアトラシアンチームからコミットを受け取る可能性も常にあります。異なる都市のチームは異なるブランチで作業することで、コミュニケーションギャップを乗り越えることができます。こうした競合の可能性についてコミュニケーションしやすくするため、私たちは HipChat （当社のグループチャット製品）を 1 対 1 のコミュニケーションとグループへの周知、コミュニケーションに使っています。これは分散したチームのメンバー間で非常にうまく機能しています。リアルタイムチャットルームでは会話が常に継続しているため、別のタイムゾーンから誰かがログオンした場合も、会話の状況をチェックしてすぐに流れに乗れました。チャットルームでメンションされると開発者には通知が飛ぶので、会話を全部読まなくても誰かからの問いかけに答えられます。
ブランチ戦略に関するメモ：「ブランチ・パー・フィーチャー」ワークフローを支持する人もいます。これは、個々のストーリーをフィーチャーブランチで開発する、というものです。プロジェクトにうまく合う場合、これは素晴らしいワークフローです。アトラシアンのいくつかの製品ではこれを採用しています。 JIRA では CI のオーバーヘッドが非常に高価になります。個々のストーリーの開発において私たちが「適切」と考える CI を実行するのは、現実的であるとは思えません。それでも、チームごとのブランチはうまくいっています。
成功
移行は大成功を収めました。コミットのできない無駄な時間は一切ありませんでした。 CI は継続して実行され、移行中もバージョン 5.0 をリリースできました。移行の後も、私たちは変更をいくつも成功させて今に至ります。開発者たちは DVCS の与えてくれる力を享受しています。リリースサイクルが完全に一新されたことが、このことを証明しています。 90 日かかっていたリリースサイクルを 14 日にまで縮めることは、 DVCS が無ければ不可能だったでしょう。
この話題はたぶん 5 回目ですが、開発チームに対するコミュニケーションの重要性はいくら強調しても足りません。移行期間中においては、実際の技術的なタスクよりコミュニケーションの重要度を高くすることを恐れないでください。コミュニケーションによって、開発者が変化を自分のものにできるのです。変化を嫌がる人にとって、コミュニケーションをすることで不安が減り、開発者が Git を好きになれるのです。移行を適切に行えば、開発者からこんなコメントをもらえることでしょう。
「 Git は少しばかり気難しいのでちょっと怖かったんだけど、やってみたら快適だった」
これこそが私たちの成し遂げたかったことをすべて言い表していませんか？
移行する
Git への移行を検討していますか？移行のやり方についてはこちらでもっと多くのことをご覧になれます。
(翻訳協力: グロースエクスパートナーズ株式会社)