30.09.2021 22:21
FAZIC 15 2700 Источник

Попробовав разные Source Control в связке с UE (Gitlab,SVN,Perforce) на текущий момент, для инди проекта я выбрал наиболее удобное решение, хотя и не самое простое в установке:

Gitlab - Для использования на своем сервере, нужно иметь машину с линуксом(использую mint), некоторое время и терпение на установку сервера и все, мы счастливые обладатели бесплатного сервера гитлаб. Дальше настраиваем подключение через SourceTree и используем;

Еще одной прелестью Gitlab, я бы назвал встроенный инструмент для CI/CD, который весьма легко настраивается и позволяет по одному нажатию кнопки: Билдить свет, паковать игру, заливать ее в стим, отправлять сообщение в дискорд и т.д, всего лишь нужен сервер с установленным UE. О настройке CI под Windows, я и расскажу.

Пропустим момент, когда устанавливать Gitlab/Source tree, создавать в нем новый проект и прочие пункты. Предположим что все это уже есть и необходимо настроить runner вместе с CI.

Установка Gitlab-Runner

Создадим папку под него, к примеру: C:\Gitlab-Runner, скачем бинарник: 64-bit или 32-bit, закинем в папку созданную ранее и сменим название на: gitlab-runner.exe (подробнее). Главное убедитесь что папка имеет доступ к записи и можно запускать из нее файлы. Запускаем cmd, для регистрации и установки Gitlab-runner.

Первым делом устанавливаем и стартуем runner, ниже пример с учетом случаев, когда для старта Windows service, нужен логин и пароль.

cd C:\Gitlab-Runner
.\gitlab-runner.exe install --user ENTER-YOUR-USERNAME --password ENTER-YOUR-PASSWORD
.\gitlab-runner.exe start

Регистрация нового Gitlab-runner.

Заходим через веб-браузер на сервер Gitlab, переходим на наш новые проект. Далее Settings → CI/CD → Runners и разворачиваем закладку, в которой будут указаны настройки для нового сервера.

Открываем командную строку на сервере с установленным Gitlab-runner и прописываем для регистрации нового runner и заполняем требования по пунктам, указав URL сервера, уникальный токен (его можно перегенерировать в случае необходимости), имя и теги, как идентификаторы сервера. Важной деталью является при помощи какого executor будем обрабатывать yml файл (я использую shell) подробнее.

cd c:\Gitlab-runner
.\Gitlab-runner.exe register

Все, новый Runner зарегистрирован, обновив страницу мы сможем увидеть все доступные сервера. Важным моментом, для дальнейшей работы является перейти в настройки сервера и установить, без этой галочки, CI зависает в режиме pending:

Так же добавлю, что в "General pipelines" можно сменить timeout (по дефолту 2 часа) на большое значение (у меня 16h), по истечению этого времени CI процесс отключается.

Таким весьма нехитрым способом мы подготовили наш сервер к работе, как билд машину для CI/CD.

Настройка yml и первый запуск

Для CI/CD, необходимо создать файл (.gitlab-ci.yml) в корне проекта и залить его в репозиторий, тем самым дав инструкции для работы. Gitlab проверит данный скрипт и если что-то пойдет не так, то выдаст ошибку (yaml invalid error) в CI/CD. Для того, что бы, не пушить десятки сломанных файлов, прямо на сайте в закладке CI/CD → Pipelines есть инструмент: "CI Lint", при помощи которого можно проверить скрипт на правильность.

Так как, мы ранее указали что используем Shell executor, то yml файл создается по принципу powershell (для других executor он может отличатся). Ниже я привел пример, сборки клиента в двух видах (дев\шип) и сервера, а так же заливка на Steam решений. Бонусом отправка в дискорд сообщения об успешной сборке.

Пример скрипта для .gitlab-ci.yml
# last update 10.04.2019 12:58PM
# BUILD_CONFIG - Shipping / Development / DebugGame / Debug

variables:
    GIT_STRATEGY: none        # we disable fetch, clone or checkout for every job.
    GIT_CHECKOUT: "false"     # as we only want to checkout and fetch in the preperation stage.
    CI_DEBUG_TRACE: "false" 
    CLIENT_BUILD_CONFIG: Shipping
    DEV_CLIENT_BUILD_CONFIG: Development
    CLIENT_PLATFORM: Win64
    SERVER_BUILD_CONFIG: Development
    SERVER_PLATFORM: Win64
    BUILD_DIR: D:\Soulhaim\Builds
    CLIENT_DIR: D:\Soulhaim\Builds\client\ez-client    
    CLIENT_STEAM_PATH: $CLIENT_DIR\WindowsNoEditor\*
    CLIENT_ARCH_NAME: $CLIENT_BUILD_CONFIG-$CI_COMMIT_SHA
    DEV_CLIENT_DIR: $BUILD_DIR\dev_client\ez-client
    DEV_CLIENT_STEAM_PATH: $BUILD_DIR\dev_client\ez-client\WindowsNoEditor\*
    DEV_CLIENT_ARCH_NAME: $DEV_CLIENT_BUILD_CONFIG-$CI_COMMIT_SHA
    SERVER_DIR: $BUILD_DIR\server\ez-server
    SERVER_ARCH_NAME: $SERVER_BUILD_CONFIG-$CI_COMMIT_SHA
    LOCAL_ARCH_PATH: D:\BuildsArchives
    STEAM_PATH: D:\steamworks_sdk_148a\sdk\tools\ContentBuilder
    UE4_ROOT: D:\UnrealEngine
    
stages:
    - preperations
    - build_path
    - build_reflection
    - build_light
    - build_client    
    - load_to_steam
    - upload_to_steam
    - pack_client
    - upload_client
    - clean_steam_client
    - dev_build_client
    - dev_load_to_steam
    - dev_upload_to_steam
    - dev_pack_client
    - dev_upload_client    
    - dev_clean_client
    - build_server
    - pack_server
    - upload_server   
    - clean_server
    - clean
                 
job_preperations:
    stage: preperations
    variables:
        GIT_STRATEGY: fetch
        GIT_CHECKOUT: "true"  
    script:
        - echo "$CLIENT_STEAM_PATH"
        - echo "$STEAM_PATH\content\Soulhaim"
        - (Remove-Item -Path $BUILD_DIR -Force -Recurse -ErrorAction Ignore)
        - echo "Hello"
        - echo "$UE4_ROOT"    
        - echo "$UE4_ROOT\Engine\Build\BatchFiles\RunUAT.bat"
        - echo "$CLIENT_DIR"
        - echo "$CLIENT_BUILD_CONFIG"
        - echo "$CLIENT_ARCH_NAME"
        - echo "$DEV_CLIENT_DIR"
        - echo "$DEV_CLIENT_BUILD_CONFIG"
        - echo "$DEV_CLIENT_ARCH_NAME"
        - echo "$SERVER_DIR"
        - echo "$SERVER_ARCH_NAME"
    only:
        - web
        
job_build_path:
    stage: build_path
    script:
        - Start-Process -NoNewWindow -Wait "D:\Soulhaim_build_path.bat"
    only:
        - web     

job_build_reflection:
    stage: build_reflection
    script:
        - Start-Process -NoNewWindow -Wait "D:\Soulhaim_build_Reflection.bat"
    only:
        - web  
        
job_build_light:
    stage: build_light
    script:
        - Start-Process -NoNewWindow -Wait "D:\Soulhaim_build_light.bat" 
    only:
        - web
        
job_build_client:
    stage: build_client
    script:
    #-ForceDebugInfo -CrashReporter - for debug files
    - Start-Process "$UE4_ROOT\Engine\Build\BatchFiles\RunUAT.bat" -NoNewWindow -Wait -ArgumentList "BuildCookRun", "-project=$CI_PROJECT_DIR\Soulhaim.uproject", "-nop4", "-build", "-cook", "-compressed", "-stage", "-ForceDebugInfo", "-allowcommandletrendering", "-platform=$CLIENT_PLATFORM", "-clientconfig=$CLIENT_BUILD_CONFIG", "-pak", "-archive", "-archivedirectory=$CLIENT_DIR", "-utf8output"
    only:
        - web

job_Load_To_Steam:
    stage: load_to_steam
    script:
        cp -r "$CLIENT_STEAM_PATH" "$STEAM_PATH\content\Soulhaim"
    only:
        - web

job_Upload_To_Steam:
    stage: upload_to_steam
    script:
        - Start-Process "D:\steamworks_sdk_148a\sdk\tools\ContentBuilder\run_build.bat" -NoNewWindow -Wait
    only:
        - web

job1_pack_client:
    stage: pack_client
    script:
        - Start-Process -NoNewWindow -Wait "C:\Program Files\7-Zip\7z.exe" -ArgumentList "a", "$CLIENT_DIR.zip", "$CLIENT_DIR"
    only:
        - web
        
job2_copy_to_local_client:
    stage: upload_client
    script:
        - cp "$CLIENT_DIR.zip" "$LOCAL_ARCH_PATH\client-$CLIENT_ARCH_NAME.zip"
    only:
        - web  

job3_clean_Steam_Folder:
    stage: clean_steam_client
    script:
        (Remove-Item -Path "$STEAM_PATH\content\Soulhaim\*" -Force -Recurse -ErrorAction Ignore)   
    only:
        - web

dev_job_build_client:
    stage: dev_build_client
    script:
    #-ForceDebugInfo -CrashReporter - for debug files
        - Start-Process "$UE4_ROOT\Engine\Build\BatchFiles\RunUAT.bat" -NoNewWindow -Wait -ArgumentList "BuildCookRun", "-project=$CI_PROJECT_DIR\Soulhaim.uproject", "-nop4", "-build", "-cook", "-compressed", "-stage", "-ForceDebugInfo", "-CrashReporter", "-debug", "-allowcommandletrendering", "-platform=$CLIENT_PLATFORM", "-clientconfig=$DEV_CLIENT_BUILD_CONFIG", "-pak", "-archive", "-archivedirectory=$DEV_CLIENT_DIR", "-utf8output"
    only:
        - web

job_dev_Load_To_Steam:
    stage: dev_load_to_steam
    script:
        cp -r "$DEV_CLIENT_STEAM_PATH" "$STEAM_PATH\content\Soulhaim"
    only:
        - web

job_dev_Upload_To_Steam:
    stage: dev_upload_to_steam
    script:
        - Start-Process "D:\steamworks_sdk_148a\sdk\tools\ContentBuilder\run_build.bat" -NoNewWindow -Wait
    only:
        - web

job1_dev_pack_client:
    stage: dev_pack_client
    script:
        - Start-Process -NoNewWindow -Wait "C:\Program Files\7-Zip\7z.exe" -ArgumentList "a", "$DEV_CLIENT_DIR.zip", "$DEV_CLIENT_DIR"
    only:
        - web
        
job2_dev_copy_to_local_client:
    stage: dev_upload_client
    script:
        - cp "$DEV_CLIENT_DIR.zip" "$LOCAL_ARCH_PATH\client-$DEV_CLIENT_ARCH_NAME.zip"
    only:
        - web  

job_clean_client:       
    stage: dev_clean_client
    script:
       (Remove-Item -Path $BUILD_DIR -Force -Recurse -ErrorAction Ignore)
    only:
        - web    
        
job_build_server:
    stage: build_server
    script:
        - Start-Process "$UE4_ROOT\Engine\Build\BatchFiles\RunUAT.bat" -NoNewWindow -Wait -ArgumentList "BuildCookRun", "-nocompileeditor", "-project=$CI_PROJECT_DIR\Soulhaim.uproject", "-nop4", "-build", "-cook", "-compressed", "-stage", "-noclient", "-server", "-serverplatform=$SERVER_PLATFORM", "-serverconfig=$SERVER_BUILD_CONFIG", "-pak", "-archive", "-archivedirectory=$SERVER_DIR", "-utf8output"
    only:
        - web               
        
job1_pack_server:
    stage: pack_server
    script:
        - Start-Process -NoNewWindow -Wait "C:\Program Files\7-Zip\7z.exe" -ArgumentList "a", "$SERVER_DIR.zip", "$SERVER_DIR"
    only:
        - web
        
job2_copy_to_local_server:
    stage: upload_server
    script:
        - cp "$SERVER_DIR.zip" "$LOCAL_ARCH_PATH\server-$SERVER_ARCH_NAME.zip"
    only:
        - web
     
job3_unpack_local_server:
    stage: upload_server
    script:
        - Start-Process -NoNewWindow -Wait "C:\Program Files\7-Zip\7z.exe" -ArgumentList "x", "$LOCAL_ARCH_PATH\server-$SERVER_ARCH_NAME.zip", "-oD:\"
    only:
        - web
        
job4_send_notify_server_to_slack:
    stage: upload_server
    script:
        - Start-Process "D:\Soulhaim_Message_Discord.bat" "New Awesome build is ready" -NoNewWindow -Wait
    only:
        - web
    
job_clean_server:
    stage: clean_server
    script:
        (Remove-Item -Path $BUILD_DIR -Force -Recurse -ErrorAction Ignore)        
    only:
        - web
        
job_clean:
    stage: clean
    script:
        (Remove-Item -Path "$STEAM_PATH\content\Soulhaim\*" -Force -Recurse -ErrorAction Ignore)   
    only:
        - web

Первым этапом (preperation), очищаем папку от старого билда, а также забираем с репозитория все последние изменения. Желательно, первым запуском сделать только этот этап, так как следующие шаги связаны с проектом и нам нужен путь к нему.

Следующими этапами просчитываем navmesh\light\reflection, скрипты которых расположены в обычных *.bat файлах. Пример для просчета света на двух картах: Через "+" можно указывать список карт.

Отдельно необходимо добавить, что если вы работаете с бинарной версией, то просчет navmesh\light\reflection желательно делать так же на бинарной версии, в противном случае на версии из исходников, движок будет требовать сделать ребилд решения, и в процесс застрянет (возможно есть решение, но я к сожалению его не нашел).

"C:\Program Files\Epic Games\UE_4.26\Engine\Binaries\Win64\UE4Editor-Cmd.exe" "D:\GitLab-Runner\builds\ComtV2y9\0\Soulhaim\Soulhaim\Soulhaim.uproject" -nop4 -run=resavepackages -buildlighting -quality=Preview -allowcommandletrendering -map=LobbyMap+GameMap

Далее шаг за шагом, произойдет сборка Shipping client → Steam, Development client → Steam, Server архививируем все это и помещаем в отдельную папку в виде client/server-Dev/ship-hash.zip, если же билдов очень много, то время от времени нужно будет чистить папку с архивами, или просто убрать эти шаги из CI.

Важный момент, так как процесс автоматический, под Steam нужно создать отдельного пользователя с правами на заливку билда, и без какой либо двухфакторной защиты, иначе процесс будет висеть в ожидании кода подтверждения, который некуда будет вбивать.

Запуск

Запуск происходит крайне просто, переходим на Ci/CD → Pipelines и жмем большую зеленую кнопку RunPipeline, выбираем с какой ветки хотим собрать и запускаем процесс. Дальше, если все хорошо, остается откинутся в удобном кресле с чаем и ожидать когда процесс дойдет до конца (или зафейлится). Любой этап можно открыть и изучить проблемы, если такие возникнут.

Бонус отправки в дискорд сообщения

Сперва заходим в настройки канала дискорда → интеграция → Вебхуки, создаете новый и копируете его URL, а дальше просто в bat вставляете сообщение и ссылку:

curl -d "content=Build is ready: Soulhaim" -X POST https://вебхук вашего канала в дискорде

Заключение

Вот собственно и весь процесс настройки CI\CD в Gitlab, подробнее можно почитать на официальном сайте в документации, но я постарался подробно описать процесс с примерами. Надеюсь статья будет вам полезной, и я ничего важного не забыл в ней указать.

Всем спасибо за внимание и да прибудет с вами сила знаний.

Комментарии (15)


  1. AndyRoss
    30.09.2021 22:35
    #23540984

    Выбор VCS для UE4 должен зависеть от размера команды и сложности проекта, а не от предпочтений отдельно взятых разработчиков. Для больших проектов, с большим количеством художников (да и разработчиков, если те злоупотребляют блупринтами) и с большим количеством ассетов, просто необходим Perforce. P4 работает с репозиториями любых размеров и отслеживает чекауты взятых в работу файлов. Уже хотя бы этих двух ключевых моментов достаточно, чтобы перестать насиловать команду с Git LFS или SVN, а кое-где сразу в связке (реальный кейс одной из компаний). А возможностей по автоматизации через P4 море. Ну и недаром сами Epic Games даже казалось бы, только с кодом движка, работают через Perforce (а в Git выгружают только для Community и пулл реквестов).


    1. FAZIC Автор
      30.09.2021 22:58
      #23541054
      +1

      Полностью согласен с этим моментом, unreal game sync для perforce чего только стоит. Но perforce дорогое удовольствие, особенно для инди команд, и тут уже приходят на помощь другие контроли версий.
      Для большого проекта настроить дженкинс в связке с P4, и все это оплатить, я бы сказал тривиальная задача)


      1. AndyRoss
        01.10.2021 00:41
        #23541372
        +2

        Ну кстати не обязательно Jenkins. От него мы как раз отказались в сторону BuildBot и большей свободы действий.

        Что касается платности Perforce, то тут есть один неизвестный многим момент относительно Free версии. Perforce Server доступен для скачивания любым желающим и позволяет создать до 5ти бесплатных пользователей. А пользователи в свою очередь могут создавать себе отдельные ворксейспейсы (всего 20 воркспейсов во Free версии). Таким образом инди команды могут создавать пользователей с именами отделов (art, programming, design, sound, common) и раздавать этих пользователей соответствующим членам команды. Те в свою очередь на своих рабочих машинах будут заводить под общими юзерами именные воркспейсы. В конечном счёте от такого подхода команда практические ничем не пожертвует и это позволит одновременно трудиться на проекте 20 членам команды, что для многих инди команд весьма солидный размер.

        Для больших проектов конечно потребуется таки купить юзеров, но на то они и большие - у них должно быть должное финансирование и VCS тут явно не повод для экономии.


        1. slonopotamus
          02.10.2021 20:11
          #23547258

          это позволит одновременно трудиться на проекте 20 членам команды

          Вы уверены что EULA перфорса такое разрешает?


          1. AndyRoss
            03.10.2021 15:09
            #23548866

            Описание ограничений free версии доступно на сайте. Утверждений, что физическое число пользователей должно равняться чисто пользователей выделенных для free версии (5) - нет. Надо понимать, что при нормальном подходе один пользователь может создавать себе воркспейсы на разных машинах: рабочий стационарный, мобильный ноут, ещё один рабочий ПК в N-ом офисе и т.д. и т.п. Также всякие интеграции могут потребовать пользователя и воркспейс. В Perforce это прекрасно понимают. Маленькие проекты им неинтересны, а если проекты разрастаются - они сами осознают необходимость в покупке лицензии и приходят в Perforce.


            1. slonopotamus
              04.10.2021 08:32
              #23550346

              У вас очень сложный способ ответить "нет".

              Из 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...


    1. igamity
      01.10.2021 11:57
      #23542736

      Чекаут взятых в работу файлов - вещь конечно чрезвычайно удобная для подобных проектов. Вот только работает через ж...у... После того как из-за глюков этой "фичи" два раза потеряли работу нескольких разработчиков - примерно 3 дня работы в общей сложности, Perforce был послан нафиг. Нельзя в работе использовать инструмент к которому нет доверия. Ну и Jenkins, конечно, то еще гуано...

      Когда перешли на git и gitlab, после Perforce и Jenkins, стало работать намного комфортнее. Команда у нас не большая, да.


      1. AndyRoss
        01.10.2021 18:55
        #23544584

        За мой 8 летний опыт работы с Perforce на разных проектах, с разными по размеру командами и до 100 человек и больше - никто не терял данные на чекауте. Скорее звучит так, что кто-то не делал чекауты (а настроенный в UE4 плагин делает это автоматом), файлы выводил из состояния read-only, работал с ними, а потом обновлялся, да ещё и в настройках воркспейса поставил галочку clobber writable files. Тут не VCS менять нужно, а человека увольнять.

        Есть локальный воркспейс. Есть read only файлы. Художник/разработчик делает чекаут - заявляет серверу о своём праве работать с этим файлом за этим воркспейсом. Файл локально становится writable. Всё что происходит на сервере - в депоте файл помечается занятым и это отображается в других клиентах. Всё. Как это может привести к потере работы, я не понимаю. К любой гранате приложена инструкция.

        На моём опыте, несчастные художники, куда больше бедокурили с Git и ещё больше с Git LFS. И это я пишу при всей своей любви к Git и Git Flow. Но увы не для UE4. Даже небольшой проект может разрастись в размерах и количестве бинарных файлов. Без LFS работа превратится в ад. А с LFS - появятся иные проблемы и скорость всё равно будет несопоставима с Perforce. Особенно если использовать клауд.


        1. igamity
          01.10.2021 19:18
          #23544650

          У нас глюки как раз происходили из-за того, что чекаут файла не распространялся. Т. е. получалось двоим сотрудникам зачекаутить один и тот же файл. Естественно, мы пользовались плагином UE для этих целей, а не клиентом перфорса. Перфорс от этого впадал в ступор и единственный вариант, который нашли - восстановить файл до всех изменений. А это потеря работы двух сотрудников...

          Была и другая проблема - чекаут залипал, когда все освободили файл, откатили правки, а файл все равно заблокирован на уровне перфорса. Это собственно и стало последней каплей. Пол дня просидели в поисках решения проблемы и пришли к выводу, что проблема - это сам перфорс и надо с него уходить.

          И это все накладывалось на отсутствие в команде действительно хорошего спеца по перфорсу (сотрудника, который его ставил и настраивал, к тому времени был уже уволен, хотя первый факап еще при нем случился и он его не разрешил без потерь). А разобраться с перфорсом за короткое время... ну, я бы мягко сказал, не очень просто.

          Конечно гит в принципе не решает проблему одновременного изменения бинарного файла, но т. к. нет ложной уверенности, что система контроля версий сама это отследит и предотвратит, проблем это не вызывает. Сотрудники просто договариваются, если работают над одной задачей, кто что трогает и меняет.


          1. AndyRoss
            01.10.2021 19:35
            #23544710

            Если бы у Perforce реально были бы такие проблемы, то ни одна из уважающих себя больших компаний (Ea, Epic Games, Ubisoft и другие), не работала бы с ним. Я много раз ставил P4. И на Linux, и на Win сервера. Самое просто конечно на Windows. Запустил инсталлер и всё. Далее можно только юзеров создавать и работать. Ваши кейсы звучат будто бы у вас локальная сеть была 512kbit и сплошные потери пакетов. Хотя даже Win Firewall иногда в это может вмешиваться, но и это легко заметить на этапе сетапе и тут же поправить. P4V - обязателен всегда к установке и всегда показывает ошибки соединения не создавая ложных иллюзий. А вот к плагину UE4 в этом плане много вопросов. Но если сеть стабильна, даже он показывает актуальный статус.

            Кроссчекаут в перфорсе по умолчанию кстати не запрещён, но плагин анрила его как раз запрещает. Ну и на уровне конфига сервера это отключается также за 5 минут.


            1. igamity
              01.10.2021 20:05
              #23544802
              +1

              Я не говорю, что перфорс в принципе не работает, а только рассказываю свои кейсы. Сеть гигабитная была и все пользователи и сервер перфорса были на одном свиче. Если бы смог тогда решить проблему, этих всех комментариев и не было бы или хотя бы я смог вам назвать причину их возникновения.

              Собственно когда нам предложили перфорс, мы на него согласились перейти как раз про той причине, что его рекомендует Epic Games. Но к перфорсу должен прилагаться хороший специалист по его настройке, а найти такого человека не просто. Да и брать в небольшую команду чисто админа перфорса - это перебор. А разобраться с ним самостоятельно за 1-2 дня не реально.

              Я согласен с тем, что мы и в частности я сам, что-то не так делали, вот только понять что именно и как делать правильно не удалось. Даже гугл тогда не помог. Вывод, лучший инструмент - это такой инструмент, которым умеешь пользоваться. Т. к. вы знаете как правильно готовить перфорс у вас подобные проблемы не возникают, а если и возникает что-то, вы знаете как их решить - вам перфорс подходит. Нам, как не специалистам - увы, нет.


            1. igamity
              01.10.2021 20:07
              #23544816
              +1

              Да, если вдруг когда-нибудь мы еще раз попробуем перфорс и столкнемся с проблемами, теперь я знаю к кому обратиться :)))


    1. Stamerlan
      03.10.2021 10:26
      #23548412

      А подскажите как в Perforce с precommit тестами? Что используете для CI/CD?


  1. VaG093
    01.10.2021 09:30
    #23542074
    +1

    Выше правильно сказали, выбор должен зависеть от размера команды и сложности проекта.

    Мы для себя идеальным решением нашли связку Plastic+Teamcity. Да, пластик может быть дорого, но во-первых - эксклюзивные чекауты, что для бинарников UE4 вещь незаменимая, во-вторых, нормальная интеграция с самим движком, в третьих, пластик отлично себя показал на репозиториях 60+гб.


  1. slonopotamus
    02.10.2021 20:03
    #23547250

    1. Ваш пайплайн дрянь. Как только раннеров станет больше 1, никто не гарантирует, что все джобы будут выполняться на одном и том же раннере, в результате всё развалится, т.к. у последующих джобов нет результата выполнения предыдущих.

    2. Проблема со Steam Guard прекрасно решается. На локальном компе авторизуемся в стиме, вводим код. Дальше выковыриваем из файлов стима файл ssnf_* и даём его раннеру. И вообще, по моей информации вообще невозможно при отключенном Steam Guard выдать пользователю права на аплоад в стим. Информация получена от саппорта стима.

    3. На дворе 2021 год, а вы предлагаете руками на каждый раннер ставить Unreal Engine? Лучше б рассказали про ue4-docker.