Comments 8
Судя по тому как вы легко с маков перескочили на винду, вас андроид-сборки интересуют больше, чем айос?
Мы по-прежнему собираем все платформы, в том числе и iOS. Есть дополнительный степ после сборки Unity. XCodeProject мы банально копируем на Mac mini и завершаем там сборку. Так как Mac mini и «Райзены» у нас находятся в общей сети, то скидывание проекта занимает меньше минуты. И поскольку сборка xcode достаточно быстрая (3-7 минут в зависимости от проекта) и многопоточная, то одного Мак мини нам хватило на все наши проекты.
Что делаете с внешними плагинами, которые через баш-скрипты пытаются править xcode-проект в постбилде? Настраиваете окружение для перла и тп штук или у вас таких проблемных ассетов уже нет и все нужные работают через юнити-апи для патчей xcode-проекта? Просто раньше с этим была большая проблема и на винде не все можно было собрать, чтобы потом унести на тот же macmini одной папкой.
А вы смотрели в сторону Unity Build, проводили с ним какие-то сравнения?
Если речь про Cloud Build, то да, смотрели и сравнивали, но он имеет ряд ограничений, которые нам не подходят, ну и еще мы используем разные платформы и специфичное окружение.
Pixonic да, его имел в виду. Сейчас это все под эгидой Unity Teams, так что смешались названия. Было бы интересно как раз про сравнение и ограничения с учетом того, что у них там есть сборка под бол-во платформ и залив же на них для ревью. Особенно было бы интересно про скорость сборки и общее время (скорость загрузки ассетов в облако vs. скорость сборки).
Конкретные цифры сейчас не приведу, но поясню пару моментов.
Наш сервер VCS находится в той же сети, что и сервер TeamCity. Соответственно, овертайм на передачу данных минимален. Ну и у нас достаточно мощный парк машин: есть возможность передачи большого количества кастомных аргументов во время сборки, через которые могут запускаться отдельные процессы со специфичным окружением (например, во время сборки мы интегрируемся с базами данных, запускаем отдельные процессы для собирания атласов и т.д.) либо выбор кэш-сервера для конкретного билда. Существуют зависимые сборки по триггерам запуска сторонних конфигураций, запуски на PullRequest и запуски автотестов на нашем парке девайсов.
Все эти вещи связаны в единую инфраструктуру нашего билд-пайплайна. В частности, по завершению сборки наши билды также попадают в файловое хранилище внутри нашей сети, что обеспечивает быструю и гарантированную доставку на девайсы.
Залив на ревью в маркеты у нас осуществляется в полуавтоматическом режиме по нажатию кнопки на сервере TeamCity, когда все наши внутренние проверки пройдены.
Короче говоря, инфраструктура у нас гораздо более сложная, чем может обеспечить Cloud Build.
Наш сервер VCS находится в той же сети, что и сервер TeamCity. Соответственно, овертайм на передачу данных минимален. Ну и у нас достаточно мощный парк машин: есть возможность передачи большого количества кастомных аргументов во время сборки, через которые могут запускаться отдельные процессы со специфичным окружением (например, во время сборки мы интегрируемся с базами данных, запускаем отдельные процессы для собирания атласов и т.д.) либо выбор кэш-сервера для конкретного билда. Существуют зависимые сборки по триггерам запуска сторонних конфигураций, запуски на PullRequest и запуски автотестов на нашем парке девайсов.
Все эти вещи связаны в единую инфраструктуру нашего билд-пайплайна. В частности, по завершению сборки наши билды также попадают в файловое хранилище внутри нашей сети, что обеспечивает быструю и гарантированную доставку на девайсы.
Залив на ревью в маркеты у нас осуществляется в полуавтоматическом режиме по нажатию кнопки на сервере TeamCity, когда все наши внутренние проверки пройдены.
Короче говоря, инфраструктура у нас гораздо более сложная, чем может обеспечить Cloud Build.
Sign up to leave a comment.
Непрерывная интеграция в Unity: как сократить время сборок и сэкономить ресурсы + пайплайн в подарок