はじめに
VR開発は Unity や Unreal Engine 4 (以下UE4) などのゲームエンジンを使って開発するのが主流となっています。
ゲームエンジンのプロジェクトは、プログラムのソースコードだけでなく、3Dのシーンの情報や3Dオブジェクトの情報など、多くのバイナリファイルで構成されています。Unityにおける .unity .prefab、UE4における .umap .uasset などがこれにあたります。
バイナリファイルを含んだプロジェクトを構成管理する際に特に問題になるのは、変更の差分を可視化しても人力では分かりづらいことです。
本記事では、この変更の差分が分かりづらいという問題に対して、どのようにアプローチして構成管理してきたかを書いていきます。
まだまだノウハウが少なく拙い内容ですが、参考になれば幸いです。
どのように構成管理をしてきたか
機能ごとのブランチは切らない
基本的に Git-flow におけるfeatureブランチのような、機能ごとのブランチは切りませんでした。
なぜなら、必要がないからです。
バイナリファイルは変更の差分が分からないので、githubにおいてpullreqしてから差分を確認してマージするという一連の流れにメリットがありません。
また、バイナリファイルはコンフリクトの解消が非常に困難です。複数の機能を並行して開発していると、どのブランチでどのファイルを変更したのか確認するのが難しくなり、コンフリクトの危険性が高まってきます。
以上の理由から、機能ごとのブランチは切りません。
master一本か、もしくはmasterとdevelopのみを使用します。
ブランチを絞るだけでは、コンフリクトの危険性が解消されるわけではありません。そこで次以降に記載するアプローチを組み合わせて、さらにコンフリクトの危険性を抑えていきます。
できるだけ担当箇所を開発メンバーごとに分ける
同時に同じファイルを変更してコンフリクトをするのを避けるために、できるだけ開発メンバーごとに担当箇所を分けていました。
機能ごとに担当を分けたこともありましたし、スマートではありませんが開発者の名前のフォルダを作成して分けたこともありました。
UE4のサブレベルを使う
UE4において、サブレベルで担当を分けるのが非常に有効でした。
ただし、カレントレベルを切り替えたときなど、意図しないタイミングでUE4によりパーシスタントレベルに変更が入ってしまうことがあります。その場合は git checkout -- PersistantLevel.umap としてパーシスタントレベルの変更を捨てて問題ありませんでした。
共通で触る可能性のあるファイルを触る場合は宣言する
開発メンバーで作業箇所を分けていても、シーンのファイルなど共通で触る可能性のあるファイルは出てきます。
そのようなファイルについては、変更する際に開発メンバーにその旨を伝えるようにしていました。
上で挙げた作業分担と合わせて、コンフリクトの危険性を抑えることができていたと思います。
レビューは動くものをベースに行う
バイナリファイルは差分が分からないので、ファイルの差分を見てソースレビューするという手法が取れません。
なのでソースレビューの代わりに、開発したものを実際に動かして確認していました。
VR体験として成立しているか、例外処理はされているかなどの機能的な観点だけでなく、パフォーマンスや酔いなどの非機能的な観点でも確認を行っていました。
なぜこの構成管理でプロジェクトが回ったか
開発メンバーが少ない
私がこれまで関わったVR開発プロジェクトは開発メンバー2名での体制だったので、お互いにどこを触っているかの把握が容易でした。
またコミュニケーションのコストも低く、「このファイルを触ります」といった宣言も合意をとるのが容易でした。
これがもし4、5名とかになってくると、あるメンバーが「このファイル触ります」と宣言した際にメンバー全員から合意を取るのが大変になるなど、開発効率が下がってしまうと考えられます。
課題
開発メンバーが多くなった場合にどうする？
上に書いたように、開発メンバーが増えると開発効率が下がると考えられます。
Unityではバイナリファイルをテキストで管理するように設定できる
Unityにおいては、シーンの情報をバイナリからテキストでの管理に変えることができるので、それによりコンフリクトの解消がいくらか容易になると考えられます。
なので、テキストでの管理にしてコンフリクトを許容し、作業ブランチを切るようにする、という方法を取るのが良いかも知れません。
やっぱりソースレビューがしたい
UnityのC#や、UE4のC++のようなソースコードはもちろん、UE4のブループリントのようなビジュアルスクリプトについてもレビューをするようにしたいと思っています。
ソースコードのみ差分のレビューをする
C#やC++に限って、差分をレビューするようにするというアプローチが考えられそうです。
その際に、レビューの対象を明確にしておくべきだと思います。外部からインポートしたアセットに含まれたソースコードは、レビューの必要がないですからね。
UE4のブループリントについては、UE4に入っている差分を見るためのツールを利用することでレビューができると考えられます。
コミットログがより重要になる
バイナリファイルはソースをベースに変更を追うのが難しいので、コミットログを手がかりに変更を追うことが多くなります。
そのため、テキストベースのファイル以上に、コミットの単位やコミットログの文言に気を配る必要があると考えられます。
おわりに
本記事では自身がどのように構成管理してきたかを書いてきましたが、この方法が最適だとは考えていません。
継続的に改善していく必要があると思っていますし、プロジェクトに合わせて構成管理の方法を変える必要があるとも考えています。
うちではこんなことをやっているなど、何かアイデアがあればコメントを残していただけると嬉しいです。