Continuous Integration с Unity

[Antares19]

Как вам живется с большим проектом на bitbucket, учитывая количество бинарных ассетов? Нет проблем с размерами репозитория?

[fischer]

Уже были:) Пока вырезали из истории удаленные ассеты, больше определенного размера. Пока прорабатываем другие варианты.

[Antares19]

Вот… да. Я пока толкового решения не нашел: как организовать простой контроль версий для Unity — без оверхеда с настройками, процессами и поднятием своего сервера.

В итоге, в маленьких-быстрых проеках, обмениваемся ассетами через… яндекс диск. Оказалось проще всего. Но, конечно, контроля версий не хватает.

Для крупного использовали TFS\SVN на своём сервере.

И то и другое — изрядный компромисс. Хочется простого и красивого решения.

[ostapbender]

Largefiles в Mercurial?

[Antares19]

Вопрос2: Правильно я понимаю, что UCB дает возможность разрабатывать iOS версии ПО без мака?

ps: Спасибо за интересную, развернутую статью! :)

[fischer]

Скорее, UCB дает возможность собирать приложения под iOS без мака. Разрабатывать под iOS без мака позволяет Unity)
Единственное, для чего может понадобиться мак, это для генерации ключей для сертификатов, для подписки билда.

[Antares19]

А, да, точно. Билд же подписывать всё-равно. Спасибо, расклад ясен.
Но в любом случае здорово… отдельный мак только для сборки держать — перебор :)

[Azy]

Как Asset Server в сравнении с git-ом?
Пока в голову лезет по-максимуму все держать в коде, включая подключение и навешивание абсолютно всего.

[fischer]

Я сначала использовал svn для проектов на Unity. Потом в какой-то момент перешел на git, в нем мне понравилось удобство работы с ветками и возможность локально работать с репозиторием, ну и git-flow (хотя сама парадигма не относится именно к git, ее можно применять и в других VCS). Но когда познакомился с Asset Sever, был шокирован отсутствием веток и методом разрешения конфликтов. Фактически, он ничем не отличается от Dropbox-подобных систем, только работает конкретно с самим Unity-проектом. Есть возможность посмотреть версии отдельного ассета, все цепочку коммитов, но на этом полезные свойства заканчиваются. И нужно поднимать свой сервер.

[Azy]

Вот именно этого я и опасаюсь — dropbox-like системы

[ese]

Разрешать конфликты на Asset Sever можно. Для тестовых файлов есть merge. Если конфликт произошел c ассетами, то есть выбор какой ассет использовать свой или чужой (merge тут конечно нет).

[ese]

Вообще сейчас мы начали практиковать такой подход: в настройках редактора включаем текстовую сериализацию ассетов и льем весь проект в Git.

[fischer]

Да, мы так же. Есть еще UniMerge и GitMerge для Unity.

[aGosh]

Спасибо конечно за то, что посветили в то, что есть cloud build. Но не проще ли (как минимум быстрее) сделать локальный гит-сервер. И написать скрипты на каком-нибудь питоне для автоматизации процессов.
Да и потом есть такая вещь как дженкинс…

[fischer]

Выбирать вам. 5 минут на настройку в UCB, или день на настройку всего локально. А потом поддержка…

[aGosh]

Это да.

[i4niac]

Зависит от ваших требований к CI. У автора была задача «CI за день» и UCB с ней справился.

Если компания достаточно крупная и имеет желание и средства настроить свой CI/CD тогда Jenkins, Bamboo, TeamCity и т.д.
Мне приходилось раньше работать с Bamboo, сейчас с Jenkins, только специфика — мобильные приложения.

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

[aGosh]

Да, да, конечно согласен.
А что из них (Jenkins, Bamboo, TeamCity) Вам больше понравилось?

[i4niac]

С Bamboo работал долгое время, больше года. Теперь имею дело с Jenkins. С TeamCity опыта нет.

Пока мне нравится Jenkins по одной причине — Jenkins Job DSL плагин. Как для разработчика, для меня это была настоящая находка. Я могу генерировать билд планы (проекты?) автоматически с помощью Groovy скрипта. Причем этот скрипт может быть сколь угодно гибким и я получаю возможность использовать Java код, классы, наследование и все эти ООП прелести, плюс кучу библиотек и т.д. и т.д. В Job DSL добавлена поддержка для большинства популярных плагинов и сообщество активно добавляет новые фичи. Можно также генерировать новые View (вкладки), группировать проекты по папкам и многое другое. Короче, легче было бы перечислить что этот плагин не умеет.

Один из минусов — порог вхождения, но по большому счету выучить Groovy на базовом уровне будет достаточно для начала.

У Bamboo ничего подобного и близко нет. Насчет TeamCity не знаю.

[thunderspb]

Хм, спасибо за плагин, интересно выглядит.
У нас юнити билдится своим собственным скриптом по образу и подобию примеров типа PerformBuild.cs, далее уже xcode из Shell steps, там все просто и прозрачно…