Comments 15
Выбор VCS для UE4 должен зависеть от размера команды и сложности проекта, а не от предпочтений отдельно взятых разработчиков. Для больших проектов, с большим количеством художников (да и разработчиков, если те злоупотребляют блупринтами) и с большим количеством ассетов, просто необходим Perforce. P4 работает с репозиториями любых размеров и отслеживает чекауты взятых в работу файлов. Уже хотя бы этих двух ключевых моментов достаточно, чтобы перестать насиловать команду с Git LFS или SVN, а кое-где сразу в связке (реальный кейс одной из компаний). А возможностей по автоматизации через P4 море. Ну и недаром сами Epic Games даже казалось бы, только с кодом движка, работают через Perforce (а в Git выгружают только для Community и пулл реквестов).
Полностью согласен с этим моментом, unreal game sync для perforce чего только стоит. Но perforce дорогое удовольствие, особенно для инди команд, и тут уже приходят на помощь другие контроли версий.
Для большого проекта настроить дженкинс в связке с P4, и все это оплатить, я бы сказал тривиальная задача)
Ну кстати не обязательно Jenkins. От него мы как раз отказались в сторону BuildBot и большей свободы действий.
Что касается платности Perforce, то тут есть один неизвестный многим момент относительно Free версии. Perforce Server доступен для скачивания любым желающим и позволяет создать до 5ти бесплатных пользователей. А пользователи в свою очередь могут создавать себе отдельные ворксейспейсы (всего 20 воркспейсов во Free версии). Таким образом инди команды могут создавать пользователей с именами отделов (art, programming, design, sound, common) и раздавать этих пользователей соответствующим членам команды. Те в свою очередь на своих рабочих машинах будут заводить под общими юзерами именные воркспейсы. В конечном счёте от такого подхода команда практические ничем не пожертвует и это позволит одновременно трудиться на проекте 20 членам команды, что для многих инди команд весьма солидный размер.
Для больших проектов конечно потребуется таки купить юзеров, но на то они и большие - у них должно быть должное финансирование и VCS тут явно не повод для экономии.
это позволит одновременно трудиться на проекте 20 членам команды
Вы уверены что EULA перфорса такое разрешает?
Описание ограничений free версии доступно на сайте. Утверждений, что физическое число пользователей должно равняться чисто пользователей выделенных для free версии (5) - нет. Надо понимать, что при нормальном подходе один пользователь может создавать себе воркспейсы на разных машинах: рабочий стационарный, мобильный ноут, ещё один рабочий ПК в N-ом офисе и т.д. и т.п. Также всякие интеграции могут потребовать пользователя и воркспейс. В Perforce это прекрасно понимают. Маленькие проекты им неинтересны, а если проекты разрастаются - они сами осознают необходимость в покупке лицензии и приходят в Perforce.
У вас очень сложный способ ответить "нет".
Из EULA:
2.1 Subject to the terms and conditions of this EULA, Perforce grants to Licensee, and Licensee hereby accepts, a limited, non-sublicensable, non-exclusive, and non-transferable license for the Software, for the number of authorized users, and for the term as specified on the Perforce price quote or Perforce invoice, for Licensee's users to: (a) install and use the Software...
Чекаут взятых в работу файлов - вещь конечно чрезвычайно удобная для подобных проектов. Вот только работает через ж...у... После того как из-за глюков этой "фичи" два раза потеряли работу нескольких разработчиков - примерно 3 дня работы в общей сложности, Perforce был послан нафиг. Нельзя в работе использовать инструмент к которому нет доверия. Ну и Jenkins, конечно, то еще гуано...
Когда перешли на git и gitlab, после Perforce и Jenkins, стало работать намного комфортнее. Команда у нас не большая, да.
За мой 8 летний опыт работы с Perforce на разных проектах, с разными по размеру командами и до 100 человек и больше - никто не терял данные на чекауте. Скорее звучит так, что кто-то не делал чекауты (а настроенный в UE4 плагин делает это автоматом), файлы выводил из состояния read-only, работал с ними, а потом обновлялся, да ещё и в настройках воркспейса поставил галочку clobber writable files. Тут не VCS менять нужно, а человека увольнять.
Есть локальный воркспейс. Есть read only файлы. Художник/разработчик делает чекаут - заявляет серверу о своём праве работать с этим файлом за этим воркспейсом. Файл локально становится writable. Всё что происходит на сервере - в депоте файл помечается занятым и это отображается в других клиентах. Всё. Как это может привести к потере работы, я не понимаю. К любой гранате приложена инструкция.
На моём опыте, несчастные художники, куда больше бедокурили с Git и ещё больше с Git LFS. И это я пишу при всей своей любви к Git и Git Flow. Но увы не для UE4. Даже небольшой проект может разрастись в размерах и количестве бинарных файлов. Без LFS работа превратится в ад. А с LFS - появятся иные проблемы и скорость всё равно будет несопоставима с Perforce. Особенно если использовать клауд.
У нас глюки как раз происходили из-за того, что чекаут файла не распространялся. Т. е. получалось двоим сотрудникам зачекаутить один и тот же файл. Естественно, мы пользовались плагином UE для этих целей, а не клиентом перфорса. Перфорс от этого впадал в ступор и единственный вариант, который нашли - восстановить файл до всех изменений. А это потеря работы двух сотрудников...
Была и другая проблема - чекаут залипал, когда все освободили файл, откатили правки, а файл все равно заблокирован на уровне перфорса. Это собственно и стало последней каплей. Пол дня просидели в поисках решения проблемы и пришли к выводу, что проблема - это сам перфорс и надо с него уходить.
И это все накладывалось на отсутствие в команде действительно хорошего спеца по перфорсу (сотрудника, который его ставил и настраивал, к тому времени был уже уволен, хотя первый факап еще при нем случился и он его не разрешил без потерь). А разобраться с перфорсом за короткое время... ну, я бы мягко сказал, не очень просто.
Конечно гит в принципе не решает проблему одновременного изменения бинарного файла, но т. к. нет ложной уверенности, что система контроля версий сама это отследит и предотвратит, проблем это не вызывает. Сотрудники просто договариваются, если работают над одной задачей, кто что трогает и меняет.
Если бы у Perforce реально были бы такие проблемы, то ни одна из уважающих себя больших компаний (Ea, Epic Games, Ubisoft и другие), не работала бы с ним. Я много раз ставил P4. И на Linux, и на Win сервера. Самое просто конечно на Windows. Запустил инсталлер и всё. Далее можно только юзеров создавать и работать. Ваши кейсы звучат будто бы у вас локальная сеть была 512kbit и сплошные потери пакетов. Хотя даже Win Firewall иногда в это может вмешиваться, но и это легко заметить на этапе сетапе и тут же поправить. P4V - обязателен всегда к установке и всегда показывает ошибки соединения не создавая ложных иллюзий. А вот к плагину UE4 в этом плане много вопросов. Но если сеть стабильна, даже он показывает актуальный статус.
Кроссчекаут в перфорсе по умолчанию кстати не запрещён, но плагин анрила его как раз запрещает. Ну и на уровне конфига сервера это отключается также за 5 минут.
Я не говорю, что перфорс в принципе не работает, а только рассказываю свои кейсы. Сеть гигабитная была и все пользователи и сервер перфорса были на одном свиче. Если бы смог тогда решить проблему, этих всех комментариев и не было бы или хотя бы я смог вам назвать причину их возникновения.
Собственно когда нам предложили перфорс, мы на него согласились перейти как раз про той причине, что его рекомендует Epic Games. Но к перфорсу должен прилагаться хороший специалист по его настройке, а найти такого человека не просто. Да и брать в небольшую команду чисто админа перфорса - это перебор. А разобраться с ним самостоятельно за 1-2 дня не реально.
Я согласен с тем, что мы и в частности я сам, что-то не так делали, вот только понять что именно и как делать правильно не удалось. Даже гугл тогда не помог. Вывод, лучший инструмент - это такой инструмент, которым умеешь пользоваться. Т. к. вы знаете как правильно готовить перфорс у вас подобные проблемы не возникают, а если и возникает что-то, вы знаете как их решить - вам перфорс подходит. Нам, как не специалистам - увы, нет.
Да, если вдруг когда-нибудь мы еще раз попробуем перфорс и столкнемся с проблемами, теперь я знаю к кому обратиться :)))
А подскажите как в Perforce с precommit тестами? Что используете для CI/CD?
Выше правильно сказали, выбор должен зависеть от размера команды и сложности проекта.
Мы для себя идеальным решением нашли связку Plastic+Teamcity. Да, пластик может быть дорого, но во-первых - эксклюзивные чекауты, что для бинарников UE4 вещь незаменимая, во-вторых, нормальная интеграция с самим движком, в третьих, пластик отлично себя показал на репозиториях 60+гб.
Ваш пайплайн дрянь. Как только раннеров станет больше 1, никто не гарантирует, что все джобы будут выполняться на одном и том же раннере, в результате всё развалится, т.к. у последующих джобов нет результата выполнения предыдущих.
Проблема со Steam Guard прекрасно решается. На локальном компе авторизуемся в стиме, вводим код. Дальше выковыриваем из файлов стима файл ssnf_* и даём его раннеру. И вообще, по моей информации вообще невозможно при отключенном Steam Guard выдать пользователю права на аплоад в стим. Информация получена от саппорта стима.
На дворе 2021 год, а вы предлагаете руками на каждый раннер ставить Unreal Engine? Лучше б рассказали про ue4-docker.
CI/CD для UnrealEngine в связке с Gitlab