Comments 20
Как вам живется с большим проектом на bitbucket, учитывая количество бинарных ассетов? Нет проблем с размерами репозитория?
Уже были:) Пока вырезали из истории удаленные ассеты, больше определенного размера. Пока прорабатываем другие варианты.
Вот… да. Я пока толкового решения не нашел: как организовать простой контроль версий для Unity — без оверхеда с настройками, процессами и поднятием своего сервера.
В итоге, в маленьких-быстрых проеках, обмениваемся ассетами через… яндекс диск. Оказалось проще всего. Но, конечно, контроля версий не хватает.
Для крупного использовали TFS\SVN на своём сервере.
И то и другое — изрядный компромисс. Хочется простого и красивого решения.
В итоге, в маленьких-быстрых проеках, обмениваемся ассетами через… яндекс диск. Оказалось проще всего. Но, конечно, контроля версий не хватает.
Для крупного использовали TFS\SVN на своём сервере.
И то и другое — изрядный компромисс. Хочется простого и красивого решения.
Вопрос2: Правильно я понимаю, что UCB дает возможность разрабатывать iOS версии ПО без мака?
ps: Спасибо за интересную, развернутую статью! :)
ps: Спасибо за интересную, развернутую статью! :)
Как Asset Server в сравнении с git-ом?
Пока в голову лезет по-максимуму все держать в коде, включая подключение и навешивание абсолютно всего.
Пока в голову лезет по-максимуму все держать в коде, включая подключение и навешивание абсолютно всего.
Я сначала использовал svn для проектов на Unity. Потом в какой-то момент перешел на git, в нем мне понравилось удобство работы с ветками и возможность локально работать с репозиторием, ну и git-flow (хотя сама парадигма не относится именно к git, ее можно применять и в других VCS). Но когда познакомился с Asset Sever, был шокирован отсутствием веток и методом разрешения конфликтов. Фактически, он ничем не отличается от Dropbox-подобных систем, только работает конкретно с самим Unity-проектом. Есть возможность посмотреть версии отдельного ассета, все цепочку коммитов, но на этом полезные свойства заканчиваются. И нужно поднимать свой сервер.
Вот именно этого я и опасаюсь — dropbox-like системы
Разрешать конфликты на Asset Sever можно. Для тестовых файлов есть merge. Если конфликт произошел c ассетами, то есть выбор какой ассет использовать свой или чужой (merge тут конечно нет).
Вообще сейчас мы начали практиковать такой подход: в настройках редактора включаем текстовую сериализацию ассетов и льем весь проект в Git.
Спасибо конечно за то, что посветили в то, что есть cloud build. Но не проще ли (как минимум быстрее) сделать локальный гит-сервер. И написать скрипты на каком-нибудь питоне для автоматизации процессов.
Да и потом есть такая вещь как дженкинс…
Да и потом есть такая вещь как дженкинс…
Выбирать вам. 5 минут на настройку в UCB, или день на настройку всего локально. А потом поддержка…
Зависит от ваших требований к CI. У автора была задача «CI за день» и UCB с ней справился.
Если компания достаточно крупная и имеет желание и средства настроить свой CI/CD тогда Jenkins, Bamboo, TeamCity и т.д.
Мне приходилось раньше работать с Bamboo, сейчас с Jenkins, только специфика — мобильные приложения.
Конечно преимуществ в своем собственном CI много, только по моему опыту настроить все это дело а потом и поддерживать — задача непростая. Но с другой стороны это очень интересная область и все больше и больше контор, занятых разработкой мобильных приложений, задумываются о серьезном подходе к CI.
Если компания достаточно крупная и имеет желание и средства настроить свой CI/CD тогда Jenkins, Bamboo, TeamCity и т.д.
Мне приходилось раньше работать с Bamboo, сейчас с Jenkins, только специфика — мобильные приложения.
Конечно преимуществ в своем собственном CI много, только по моему опыту настроить все это дело а потом и поддерживать — задача непростая. Но с другой стороны это очень интересная область и все больше и больше контор, занятых разработкой мобильных приложений, задумываются о серьезном подходе к CI.
Да, да, конечно согласен.
А что из них (Jenkins, Bamboo, TeamCity) Вам больше понравилось?
А что из них (Jenkins, Bamboo, TeamCity) Вам больше понравилось?
С Bamboo работал долгое время, больше года. Теперь имею дело с Jenkins. С TeamCity опыта нет.
Пока мне нравится Jenkins по одной причине — Jenkins Job DSL плагин. Как для разработчика, для меня это была настоящая находка. Я могу генерировать билд планы (проекты?) автоматически с помощью Groovy скрипта. Причем этот скрипт может быть сколь угодно гибким и я получаю возможность использовать Java код, классы, наследование и все эти ООП прелести, плюс кучу библиотек и т.д. и т.д. В Job DSL добавлена поддержка для большинства популярных плагинов и сообщество активно добавляет новые фичи. Можно также генерировать новые View (вкладки), группировать проекты по папкам и многое другое. Короче, легче было бы перечислить что этот плагин не умеет.
Один из минусов — порог вхождения, но по большому счету выучить Groovy на базовом уровне будет достаточно для начала.
У Bamboo ничего подобного и близко нет. Насчет TeamCity не знаю.
Пока мне нравится Jenkins по одной причине — Jenkins Job DSL плагин. Как для разработчика, для меня это была настоящая находка. Я могу генерировать билд планы (проекты?) автоматически с помощью Groovy скрипта. Причем этот скрипт может быть сколь угодно гибким и я получаю возможность использовать Java код, классы, наследование и все эти ООП прелести, плюс кучу библиотек и т.д. и т.д. В Job DSL добавлена поддержка для большинства популярных плагинов и сообщество активно добавляет новые фичи. Можно также генерировать новые View (вкладки), группировать проекты по папкам и многое другое. Короче, легче было бы перечислить что этот плагин не умеет.
Один из минусов — порог вхождения, но по большому счету выучить Groovy на базовом уровне будет достаточно для начала.
У Bamboo ничего подобного и близко нет. Насчет TeamCity не знаю.
Sign up to leave a comment.
Continuous Integration с Unity