Проблемы скорости сборки, или что делать, если время сборки игрового билда увеличивается в 10 раз
О работе DevOps в геймдеве, или как собирать в Unity в 2,5 раза больше контента за то же время, что и раньше.
О работе DevOps в геймдеве, или как собирать в Unity в 2,5 раза больше контента за то же время, что и раньше.
Но, к сожалению, в данном подходе присутствует человеческий фактор, когда программист должен сам решить, менялся у него контент или нет. Это накладывает существенные ограничения в виде ошибок сборки, когда может отсутствовать или измениться контент.Я чего-то может не понимаю, но почему вы при сборке ассетов не ведёте свой учёт версий? Мы в своё время для обычных Ассет Бандлов (не Addressables) такое делали. Рядом с бандлами у нас было свой json с версиями всех бандлов и по нему смотрели, что меняется.
Мы еще думаем над системой версионности, но, к сожалению, на данный момент она накладывает ограничения.
В нашем случае мы не запускаем вообще никаких просчетов хешей на старте билда — соответственно, нет дополнительного времени просчета. Свой кастомный хеш, например, от ассетов также накладывал бы ограничения: измениться могут не только сами ассеты, изменение в настройках проекта может повлиять и на перерасчет хешей.
Основным плюсом данного функционала для нас является максимальная скорость сборки билда, где контент неважен: например, проверить фикс кода. Кроме того, этот функционал является опциональным: чтобы им воспользоваться нужно поставить флаг в Teamcity при старте сборки.