PlasticSCM（Unity Version Control）でUnityアセットをバージョン管理する
はじめに
株式会社QualiArtsでTA（テクニカルアーティスト）をしている見原です。
本稿では、弊社のUnityプロジェクトにおいて、アセットのバージョン管理にPlasticSCM（UnityVCS）を導入した事例を紹介します。
これまでのアセットのバージョン管理
QualiArtsではこれまでアセットのバージョン管理にSVN（Subversion）を使用していました。
アセットのバージョン管理システムとして求める最低限の要件は満たしていたものの、以下のような課題がありました。
- 大量ファイルのコミット、ダウンロードが遅い
- 実際のファイルサイズの倍のストレージを消費する
- しばしばDBの破損やqueueの状態による問題が発生する
- TAやエンジニアがsqliteを操作して復旧作業を行う必要がある
そんな折、PlasticSCMがUnityファミリーに加わったため、今後のUnityエディターとの連携の可能性などに期待し、検証の上でPlasticSCMの導入を決めました。
PlasticSCMの特徴
PlasticSCMは集中型と分散型を選択できるという特徴のあるバージョン管理システムです。 集中型はSVNライクに、分散型はGitライクに使用できます。
同じリポジトリにおいてエンジニアは分散型で作業、デザイナーは集中型で作業という形をとることもできます。
ロック機能もあるため、排他制御をすることも可能です。
また、クラウド版とエンタープライズ版が選択でき、クラウド版であれば自社でサーバーの管理をする必要がありません。 クラウド版ではユーザーごとの月額に加え、ストレージサイズに応じた月額がかかる形になります。詳細は公式ページをご覧ください。
クライアント
GUIクライアントはモードごとに使い分ける形になります。
分散型の場合はPlasticSCM、集中型の場合はGluonというクライアントを使用します。
ちなみに2022年8月現在PlasticSCMのクライアントは移行期にあり、新GUI（PlasticX、GluonX）と旧GUI（LegacyPlastic、LegacyGluon）が存在します。 デフォルトでは新GUIが使用されますが、任意で旧GUIを使用することができるという状態になっています。 こちらに関して一部注意点があるので、後ほどご紹介します。
VersionControlプラグインを使用してUnity上で操作をすることもできます。
また、コマンドラインクライアントやREST APIも存在するので、CIツールでの利用や、効率化や自動化のための開発も可能です。
認証と権限管理
ログインにはUnityIDまたはPlasticSCMの独自のIDを使用できます。 （エンタープライズ版の場合はLDAPやActive Directoryが使用できるようです）
グループ機能もあり、管理権限があれば自由にグループの追加削除、メンバーの管理が可能で、こちらを活用してリポジトリ、ディレクトリ、ファイルといった単位でread、write、viewといった権限の切り替えができます。
たとえば「3D_Designer」といったグループを作ったら、3D関連の作業領域以外はreadのみ付与する、という運用もできると思います。
また、クラウド版ではグローバルIPでの制限をかけることもできるようになっています。
用語の対応関係
PlasticSCMは各バージョン管理ツールと 用語が異なります。 本稿をお読みいただくにあたって、他のバージョン管理ツールと呼び方は一致してるけど意味が違うといったものもあるので、以下をご参考にしていただければと思います。
| PlasticSCM | Git | SVN | Perforce |
|---|---|---|---|
| workspace create | clone | checkout | sync |
| checkin | commit | commit | submit |
| push | push | (commit) | push |
| update | pull | update | sync |
| undo | reset | revert | clean |
PlasticSCMによるアセットの管理
今回はSVNの代替として使用したかったので集中型を選択しました。 （前述の通りエンジニアは分散型を使用するという選択もできますが、ソースコードの管理は行わないため、エンジニアもデザイナー同様に集中型で作業をする方針としています。）
SVNを使用していた際はMaya作業用のリポジトリとUnity作業用のリポジトリを分けており、PlasticSCMでも同じ方針としまし た。
Unityプロジェクトのアセット管理
Unityプロジェクト自体はGitHubで管理しているため、SVNで管理しているときはAssets以下のあるディレクトリに対してSVNリポジトリをチェックアウトする、というような形になっていました。
PlasticSCMを使用する場合も同じ形にすることは可能ですが、UnityのVersionControlプラグインを使用する場合はその限りではありません。 VersionControlプラグインはプロジェクトルートとPlasticSCMのworkspaceのルートが一致してはじめて動くため、VersionControlプラグインを使用する場合はそのルールに則る必要があります。 恐らくソースコードなども含めてUnityプロジェクト全体を管理する前提の想定なのだとは思うのですが、このタイミングでソースコードも含めてPlasticSCMに移すメリットよりもデメリットの方が多いと判断し、もともとSVNで管理していたアセットの管理のみをPlasticSCMへ移行する形にしました。
つまりGitHubからUnityプロジェクトをクローンし、その中のプロジェクトルートにPlasticSCMのワークスペースを作成することになるのですが、当然結果としてGit的にもPlasticSCM的にも双方の管理ファイルがチェックイン候補として上がってしまいます。
したがって、GitリポジトリではPlasticSCM管理のディレクトリをignoreし、PlasticSCMリポジトリではその逆を行うという対応をしています。
PlasticSCMではリポジトリ直下に ignore.conf というファイルを作成することで .gitignore のような除外ルールの管理ができます。
VersionControlプラグインの検討
上でVersionControlプラグインについて記載していますが、弊社では現在VersionControlプラグインは明示的に削除しています。
理由としては、VersionControlプラグインに含まれるImporterの挙動が弊社のフローにマッチしなかったというところです。
具体的には AssetPostprocessor.cs が OnPostprocessAllAssets メソッドを実装することで移動や削除を検出し、自動的にコマンドを発行するようになっているようで、たとえばインハウスのImporterでFBXをインポートしたときMaterialの再生成を行うような処理になっていると、削除コマンドと追加コマンドが発行されることになります。
結果、こんな感じになってしまうわけです。
Unity上で更新やチェックインといった操作を完結できるのは非常にメリットを感じるのですが、この挙動が致命的で削除に至りました。 他にもワークスペースの操作がロックされたまま返ってこないケースなどもありましたが、そちらはバグ報告をして6月頃に解消しています。
ちなみにVersionControlプラグインを使用することでmetaファイルのチェックイン漏れが防げるというメリットも期待していたのですが、こちらに関してはGluonでもmetaに対応するファイルをチェックしたとき自動的にmetaもチェックが入るため、VersionConrtolプラグインなしでも恩恵を享受できました。
部分ダウンロード
集中型の大きなメリットの1つとして部分ダウンロードができるという点が挙げられます。 Unityプロジェクトには3D、2D、サウンドなどさまざまな職種が関わり、日々アセットを更新しますが、サイズの問題に加えてUnityはどうしてもImport処理にある程度の時間がかかるので、できれば不要なアセットはダウンロードしたくありません。
Gluonではかなり手軽に部分ダウンロードの切り替えができるため、ある程度上位の階層で各セクションの管理ディレクトリを分け、初期設定時に必要なものだけをダウンロードする形にしています。
Shelves
分散型にはもともとGitのStashに相当する機能であるShelvesがあったのですが、なんと2022年7月に集中型でも使用できるようになりました…！
Gitを普段使用されていない方向けに簡単に説明すると、リモートに反映はしたくないけど自身のローカルの変更を退避していつでも戻せる状態にしておく機能です。
ただ、GUIでは前述の新しいGUIでしか利用できないので注意が必要です。 本来であれば「新しいGUI使えばいい じゃん」という話ではあるんですが、2022年8月現在は一部の日本語が正常に表示されず、チェックインのコメントにも日本語を正しく入力できない問題があるので、日本語を使用したい場合は旧GUIを使わざるをえない状況にあります。
Tips
チェックインのオプション
チェックインの判定方法は標準ではタイムスタンプの差分で判断されますが、この状態だと誤検知が多く、弊社ではハッシュの比較も有効にしています。
また、PlasticSCMにはPlasticSCM自体の機能を使用せずに移動やリネームを行った際、ファイルの類似度などからそれを移動と判定してくれる機能があります。 ただ、どうしても誤検知もあるのあと、一気に大量の移動をした場合に操作不能になるケースがあるため、弊社では基本的に無効にするのを推奨しています。 ただ、少ないファイル数であればある程度判定してくれるので、時と場合によって一時的に有効にするような運用になっています。
どうしても大規模な移動や一斉リネームを必要とする場合はTAがコマンドラインクライアントを活用して実施するようにしています。
非表示ファイル
上で ignore.conf ファイルを用いて除外ルールの管理ができるという話をしましたが、これに加えて hidden_changes.conf というファイルを用意することで非表示ファイルのルールの管理ができます。
非表示ルールに加えることで、「チェックアウト」という操作で明示的にそのファイルを操作する宣言しない限り、対象ファイルがチェックインの候補に挙がらなくなります。ScriptableObjectでツールの設定を管理するようなケースで、管理はしたいが各個人の変更をチェックインする必要はない、といったケースで活用できます。
他にも、以下のようにファイルベースで振る舞いを定義できるものがいくつかあります。
- cloacked.conf： 指定ファイルのダウンロードを抑制
- writable.conf: 書き込み制御
- readable.conf: 読込制御
このあたりの詳細についてはPDFのマニュアルにまとまっているので、興味がある方はご覧ください。
SVNから移行した感想
先頭に書いたSVNに対する以下の不満が解消され、基本的にはとても満足しています。
- 大量ファイルのコミット、ダウンロードが遅い
- 実際のファイルサイズの倍のストレージを消費する
- しばしばDBの破損やqueueの状態による問題が発生する
- TAやエンジニアがsqliteを操作して復旧作業を行う必要がある
特に1つ目の項目に関してはSVNサーバーの環境などの要因もあるかもしれませんが、ファイルサイズが小さくても量が多いと非常に低速だったのが、PlasticSCMだとかなり高速に処理されるようになりました。
また、ちょうどUnityアップデートの機会があったので、検証用の専用ブランチを用意して分岐し、その後利用者の一斉アップデートのタイミングで本流にマージするというフローも特に苦労することなく実施することができました。
とはいえいくつか課題に感じる部分もあるので、そちらもご紹介します。 尚、弊社ではSVNの操作にTortoiseSVNを使用していたので、この環境との比較を含みます。
1つ目はGUI上でディレクトリ単位での履歴が確認できない点です。 GUIではファイル単位、または変更セット（SVNでいうリビジョンに相当）単位でしか履歴が確認できないため、たとえばあるキャラクターモデルのFBX、テクスチャ、Materialといった関連ファイルを1つのディレクトリで管理していたとして、このモデルに対していつどのファイルを更新したかという情報を確認する際、ディレクトリ内の各ファイルを個々に確認していく必要があります。
同様にこのディレクトリごとある時点の状態に戻す、ということも出来ないので、なにか問題が発生したとき、これを切り分けていくのに比較的手間がかかる印象です。 コマンドラインクライアントは用意されて いるので、自前で実装すれば解決できる問題ではあるのですが…。
ちなみに指定ディレクトリをある時点の状態に戻すのは以下のいずれかのコマンドで実現できます。
cm revert {path}#cs:{changeset}
cm partial update {path} --changeset={changeset}前者はファイルに変更が入るので、最新にする場合は取り消しをする形になります。後者の場合は向き先が指定チェンジセットに戻るので最新にする場合は更新をするだけでよくいい感じに思えますが、2022年5月ごろに挙動を検証していた際に指定ディレクトリ以外にも影響が出るケースがあったので、個人的には前者を使用しています。
2つ目はWindowsのエクスプローラー拡張が分散型でしか使用できない点です。 PlasticSCMにはshell extensionという形でTortoiseSVNライクに標準エクスプローラーから右クリックで操作できる機能がオプションでインストールできるのですが、こちらが分散型前提になっているようで、更新を試みると分散型への切り替えを促すダイアログが表示され、更新が実行できません。
PlasticSCMにおける更新などの一部コマンドは集中モードで使用する場合 partial という引数を与えてやる必要があり、これが必要な操作がサポート対象外になっているものと思われます。
（したがって履歴を見るくらいは集中モードでも実行可能ではあります）
あと特に不満というわけではありませんが、SVNはhttpプロトコルでアクセスできるため、やろうと思えば社 内のWebベースのドキュメントに直接画像URLを埋め込むことで直接参照するといったこともできましたが、PlasticSCMは権限管理の都合上そういったことはできないので、そういった使い方をしているプロジェクトは別の方法の検討が必要になります。
とはいえPlasticSCMにはWebUIが用意されているので、リポジトリをダウンロードせずともブラウザでファイルを確認することはできます。
おわりに
PlasticSCMの導入により、アセット管理の改善を実現することができました。
課題の中でコマンドラインクライアントを使用することで改善できるものに関してはツールの作成を進めていますが、Unity社にも日々フィードバックをお送りしているので、標準機能も改善されることを期待しつつ、引き続き活用していきます。 まだ国内の事例が少ないので、また何か知見が溜まったら共有できればと思います。
本稿がPlasticSCMを検討する方の参考になれば幸いです。