Team Foundation バージョン管理から Git に移行するための旅路 (2)
免責事項
この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。
本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。 すべて "At your own risk" である。
はじめに
今回は、Team Foundation バージョン管理がどのようにファイルを管理しているのかについて話す。 これは、Git に移行する際に何に注意する必要があるのかについて理解するのに役立つ。
集中型バージョン管理と分散型バージョン管理
Team Foundation バージョン管理は「集中型バージョン管理方式」であり、Git は「分散型バージョン管理方式」である。 しかし、読者の中には「Git の場合もサーバー上で管理されているコードをみんなで取得したり発行したりしているのだから、Team Foundation バージョン管理のときとサーバー・クライアントの関係は同じなのでは？」と思うかもしれない。
答えは、その通り。ただし、ここでいう集中と分散という言葉が指しているのは、クライアント・サーバー間の関係ではなく、「履歴情報」である。
Team Founation バージョン管理の場合、指定されたコードのみがクライアントに渡るが、履歴情報のすべてを保持しているのは Team Foundation Server / Azure DevOps Server だけである。
一方、Git の場合は、基本的に履歴情報すべてを同期するので、クライアント側でも履歴情報が保持される。 これにより、万が一サーバーがダウンしてしまっても、開発者は履歴の変更も参照も問題無くできる、というわけだ。（システムダウン中に他者にコードを共有するのは簡単ではないが）
履歴がクライアントにもコピーされるとはどういうことか
上で、履歴がクライアント側にコピーされる、これによりサーバーがダウンしていても履歴の更新や参照が可能になる、という話をした。 では、この話はどのような問題があるのかを考えてみよう。 たとえば、次のような課題が思い浮かぶことだろう。
- リポジトリが巨大な場合は、クローンに時間がかかる（クライアント側の容量も心配になる）
- 履歴情報すべてがクライアントに保持されるので、情報漏洩時のリスクが高まる
- 細かい監査ができない
それぞれについて簡単にコメントする。
リポジトリが巨大な場合は、クローンに時間がかかる
Git リポジトリをローカルに取得する操作を「クローン (Clone)」と呼ぶが、この際にリポジトリの履歴情報すべて取得するので、リポジトリの容量が大きいほどダウンロードに時間がかかり、クライアントのディスク容量も消費される。
マイクロソフトの Windows チームが Git に移った当時のリポジトリ サイズは 300 GB を超えていたそうで、そのままクローンした場合は１日では終わらなかったそうだ。（実際、彼らはそれを解消するために独自のツールを開発することになるのだが、それは別の話。）
300 GB は極端な例にしても、バイナリファイルを大量に履歴に含めていると、数 GB 以上というケースはよくある。 これまでバージョン管理からバイナリ ファイルを取り除くかをこれまで説明してきた理由を理解していただけたと思う。
情報漏洩リスクが高まる
言うまでも無く、ソースコードは開発会社にとって「資産」である。ソースコードの漏洩だけで大きなリスクだが、Git リポジトリが漏洩した場合はすべての履歴情報だけでなく、何時、誰が（名前とメールアドレス）修正したのか、という情報も漏洩してしてしまう。
また、Git リポジトリの性質から、比較的簡単に外部のパブリック リポジトリ (GitHub.com など) に再発行できてしまうのもリスクの１つと言える。 最近は「あなたの適正給与を調べます」といったサイトで、Git リポジトリを分析するサービスもあり、「気軽な気持ち」で情報漏洩をしてしまった事例もあるので、注意が必要である。
これに対する対処は Git 単独ではできず、クライアント側のセキュリティ ソリューションと、Git をホスティングするサービス側で防衛する必要がある。 具体的にどのような方法があるのか興味がある読者も多いかもしれないが、今回の話とはずれてしまうので、また別の機会にする。
細かい監査ができない
これまで説明してきたとおり、Team Foundation Server からバージョン管理されているファイルを取得するには、都度 Team Foundation Server にアクセスしなければならない。このため、Team Foundation Server 側で誰が何時、バージョン管理にアクセスしたのかを把握することができる。 また、後述するサーバー ワークスペースの場合は、ワークスペース管理自体をサーバー側で行っているため、誰が、どのコンピューターに、いつ、どのファイルを取得したのか、というのが保持されている。
一方、Git の場合は、自身の作業が完了し Team Foundation Server / Azure DevOps Server にプッシュ (発行) するまで、サーバー側は関知することができない。
Team Foundation バージョン管理におけるリポジトリ
次に、Team Foundation バージョン管理のリポジトリと、Git リポジトリの範囲と管理について話す。
Team Foundation Server / Azure DevOps Server には、チーム プロジェクト コレクション (TPC) と呼ばれる複数のチーム プロジェクト (TP) を束ねる概念があるが、Team Foundation バージョン管理はチーム プロジェクト コレクションと１対１の関係として管理されている。 一方、Git はチーム プロジェクト (TP) の中に複数の Git リポジトリを管理することができる。
これだけを聞くと、Git リポジトリの方が柔軟でよさそうだが、いくつか問題がある。
たとえば、Git ではリポジトリ内のフォルダーやブランチ単位でアクセス制御ができない。 たとえば、リポジトリの docs フォルダー配下は、マニュアル担当者しか変更させたくない、といったことは実現できない。
Git は基本的にリポジトリ単位でアクセス権限を分けることになるため、上記の例でいえばドキュメント管理用のリポジトリを作成し、そこに適切なアクセス権限源を付与させることになる。このように、アクセス権限の単位や方法も変わる。
おわりに
さて、長くなってきたので、今回はこれで終わりにしたい。 次回は Team Foundation バージョン管理のワークスペースの種類の話をしよう。Git のようになりたかった Team Foundation バージョン管理が Git を参考にして追加した機能、そして失われた機能、そして Git ではどうするのか。 それでは、また次回。
