azukipochette's weblog

memory dump (mini)

Team Foundation バージョン管理から Git に移行するための旅路 (1)

免責事項

この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。

本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。すべて "At your own risk" である。

はじめに

この文書は Team Foundation Server (TFS) または Azure DevOps Server 上で Team Foundation バージョン管理を使っている方で、将来または今後 Git に移行しようと考えている方に向けて書くものである。タイトルに「旅路」と付けたのは、この移行作業が単純なものではなく、じっくりと理解し、時間をかけて準備・作業しなければ、上手くいかないという厄介さがあることを伝える為だ。

この作業は簡単ではないし、考慮事項も多い。だが、もしあなたの資産を正しく Git に移行したいのであれば、この文書が役立つだろう。

Team Foundation バージョン管理とは何なのか

Team Foundation Server を使っている人の中には、自分が使っているバージョン管理方式が「Team Foundaiton バージョン管理 (通称、TFVC)」であると知らない人もいる。それは、リリース当時、そのような名前は無かったことに起因している。

この名前は Team Foundation Server 2012 Update 2 以降、バージョン管理方式に Git が追加されたことに起因している。 以前は「Team Foundation Server のバージョン管理機能」という位置づけでよかったものが、Git と従来方式を選択できる（正確にはどちらも一緒に使うことができる）ことになったため、便宜上名前を後から付けたのである。

数十年前のソフトウェア開発を振り返る

読者の中には、20 年以上ソフトウェア業界に身を置いている人もいれば、そうでない人もいるだろう。 20 年前には、バージョン管理のツール自体は存在していた (「ごった煮版 CVS」とか懐かしい) が、まだ主流ということではなく、小規模なアプリ開発であればファイル共有フォルダーに "v1" "v2" といったフォルダーを作って世代管理をしていた時代だったように記憶している。

このような古（いにしえ）の時代の風習は、なぜか未だに残っており、Team Foundation バージョン管理の履歴を蝕んでいることがよくある。 たとえば、下記の項目に該当しないだろうか？

  • 作成したツールは開発当時のツール チェインから更新してはならない (VB 6 で開発したならば、現在の修正も VB 6 で行っている、ということ)
  • ビルドしたライブラリや実行ファイル (.dll, .lib, .exe) を成果物管理の目的でバージョン管理に入れている (コードもいれるし、ビルド後のバイナリも入れる)
  • ビルドしたファイルの日付で変更管理を行っている
  • コードを変更する度に誰がいつ変更したのかを各行にコメントとして挿入している
  • 開発ドキュメントをバージョン管理に入れている

それぞれについて私なりのツッコミをいれておきたい。

ツール チェインを更新しない

おそらくこのルールが適用された背景には、コンパイル ツールのバージョン更新でバイナリの内容が変わり、動作しなくなったというトラウマから来ているのではないかと思う。これは今でも希に見舞われる問題だが、そもそもセキュリティ上の問題でランタイムや OS 自体が強制的に更新される現代において、コンパイル ツールを「永遠に固定化」するメリットは小さい。少なくとも、サポート終了 (EOS) がアナウンスされる頃になったら、保守コストとメリットを天秤にかけて、ツールを更新する必要がある。

今更「ついに重い腰を上げて、VB 5 から VB.NET の最新に移行する気になりました！」と言われても、「既に移行ツール自体が EOS になっている/入手できない」という状況にもなりかねない。

自身の体調に違和感を感じたら自然と病院に行くように、EOS の足音が聞こえたら移行を検討すべきなのだ。

バージョン管理にビルド後のバイナリ ファイルを追加する

この話は、上の話に繋がっている。「ビルドする度に内容が変わるかもしれない」という不安から、バージョン管理にバイナリ ファイルを入れているのだ。 そして、v1.0 といったラベルを付与することで、ソースコードと関連するバイナリ ファイルを一元的に管理できるという面もある。

Team Foundation Server には自動ビルド (CI/CD) によってビルド後のファイルが成果物（アーティファクト）として保持されるので、こちらで管理すべきなのだが、Team Foundation Server を単純な「バージョン管理ツール」として見ている人ほどバイナリ ファイルを直接入れる傾向が強いようだ。（Visual Source Safe からの移行者など）

なお、これはバージョン管理の観点からも推奨できないのだが、話が長くなるので、また別の話とする。

ビルドしたファイルの日付で変更管理をしている

大規模なアプリ開発をしているケースでコンポーネント毎に出荷管理をしていると、「ファイルの作成日時・更新日時で棚卸しをしているので変更したくありません」と言われることがある。（実際、Team Foundation バージョン管理にはユーザーフィードバックによりチェックアウト日付になる機能が追加された過去がある）

これは先ほどの話と同じで、成果物のファイル単独で判断するのではなく、自動ビルド側で保持・管理をさせるほうが適切と言える。 もちろんファイル単独では判断できないが、ビルド ツールはいつ、どのコードを、誰の指示でビルドしたのかを保持しており、同時にビルドした成果物（バイナリ ファイル）も関連付けして保持している。棚卸しの情報としては、これで十分だと私は思う。

ソースコードに変更日付と変更者をコメントとしてを追記している

これを見た時に私は目を疑った。なぜなら、同じ情報をバージョン管理自身が保持しているからである。 「差分は分かっても誰がどの行をいつ修正したのかわからないじゃないか！」という人がいるとすれば、それは「注釈 (Annotate)」機能を知らないだけである。

どうでも良いが、Git ではこの機能を blame と呼ぶ。blame は「責任を負わせる」、「非難する」を意味し、確かに「ビルドが通らない！誰がこの行を変更したんだー！」という時に使う機能ではあるが、名前付けがダイレクトすぎるだろう、と思わなくもない。が、Team Foundation バージョン管理の場合は「注釈 (Annotete)」という名前がぼんやりしすぎていて、そんな機能だとは知られていないことがよくあるので、それに比べるとマシなのだろう。

開発ドキュメントをバージョン管理に入れている

これは先ほどの「ビルド後のバイナリ ファイルを追加している」ケースと殆ど同じ話である。 ドキュメントの世代管理をしたいならば、今は SharePoint であったり、オンライン ファイルストレージ系のアプリで世代管理をしてくれるので、そういった機能を使うことが推奨される。

もし、ソースコードと紐付けたいというのであれば作業項目 (Azure Boards) を使うことを検討してほしい。 作業項目には、ファイルを直接アタッチすることもできるし、リンクを追加することもできる。 もし管理したいファイルが Office ファイルならば、SharePoint 上で管理し、対象世代の URL を作業項目にリンクさせるのが一番簡単だと私は思う。

作業項目をどう管理すればいいのか、というのも議論のポイントだが、これも話が長くなるので、またいつかの話とする。

おわりに

長くなってきたので、今回はこれで終わりにしたい。

読者の中には、昔話をして終わりじゃないか！と思うかもしれないが、これらは Git に持ち込んではいけない過去の風習である。 今は便利なツールも機能もあるし、ソフトウェアの開発状況も変わっている。「よくよく考えてみると、不要なのでは？」となるものもあれば、代替手段が必要なものもあるだろう。その場合は、私が書いたコメントを参考にしてみてほしい。

次回は、Team Foundation バージョン管理がどうやってファイルを管理しているのかを通じて、Git 移行時に起きる問題点を考えてみよう。

それでは、また次回。